Про процесс подбора команды тестеров, СV и интервью

[avatarakali]

Work (W) equals the force (F) applied to an object times the distance (D) that object moves in the direction of the force applied.
Dig that part at the end: in the direction of the force applied. You can wear yourself out pushing on the door marked “pull,” and you haven’t, as far as the scientist is concerned, done any work at all

Comments

[ext_522103]

> Обычно я ищу в техническом плане человека, для которого все эти условности типа БД, юникса и прочие приспособления - это всего лишь инструмент для достижения качества процесса в целом. И которому все равно кого и как тестировать, хоть слона.

А вот меня бы такое отношение как кандидата отпугнуло. "Мы выбираем, нас выбирают". Для меня важно, чтобы мой будущий менеджер учитывал мои предпочтения в тестировании и с вниманием относился к моему опыту.

[avatarakali]

не вижу противоречия:
1) Я специально упомянула, что разговор и вопросы задаются именно с целью определить умения и предпочтения в тестировании
2) При этом в техническом плане владение инструментами на свободном уровне - только плюс. Возможно отсутствие такого свободного умения можно назвать предпочтениями, но это как выбирать не быть профессионалом.
3) Я специально привела пример одной девушки, которая ни разу не работала в юниксе, а работала с документами раньше - и она стала ведущим тестером у нас, ибо легко обучилась . Возможно она просто не цеплялась за свои предпочтения.

[ext_522103]

Объясню, профессиоанальном тестировщику, а не девушке без опыта, совсем не все равно как и что тестировать.
У менеджера просто может не быть того опыта, который есть у тестировщика, чтобы оценить методы-средства-инструменты, которые использует тестировщик в тестировании.
И, к примеру, это даже не профессиоанально, дать вдруг тестировщику линуксового ядра тестировать веб сервисы.
Профессиоанльному тестировщику не все равно, что и как он тестирует.

[avatarakali]

Объясняю - у менеджера может быть задача с вводными данными, под которые человек может подходить или нет. И да, нам нужны люди, умеющие и линуксовское ядро, и веб-сервисы, и интерфейс, и так далее - и именно такой широкий спектр инструментария в руках тестировщика я и называю профессионализмом.

Впрочем, верно было сказано: "мы выбираем, нас выбирают" - отсутствие гибкости мышления и способности перестраиваться под ситуацию в зависимости от поставленной задачи я считаю за минус, и с такими людьми мы если и начинаем работать, то ненадолго - в наших условиях они просто не выдерживают масштаба задач, пытаясь применять только один и тот же метод ко всем приложениям. А их у нас сотни разных.

[ext_522103]

> И да, нам нужны люди, умеющие и линуксовское ядро, и веб-сервисы, и интерфейс

Надя, при всем уважении, но это вызвало у меня улыбку. Это как сказать программисту, что будешь разрабатывать REST API для нашего сервиса и писать драйвера для вон той железки на FPGA, ах да еще и оттюнишь нам линуксовое ядро, чтобы latency для нашего месседжинга была наносекунды.

Больше спорить не хочу, видимо в задачах, которые вы решаете достаточно низкий порог вхождения и такой подход приемлем.

[avatarakali]

у меня тоже при всем уважении вызвало улыбку желание как-то задеть носо-мерянием
Нет, это не как сказать программисту - несопоставимое сравнение: программист создает с нуля из ничего, а тестер тестирует уже созданное при помощи своих знаний и умений. Если знаний не хватает - это минус тестера, а не повод для гордости.

Действительно все зависит от поставленной задачи
И увы, у нас и качество потом соответствующее.
Не NASA, нет, ни разу =)

в компании, где в других отделах даже просто НЕТ тестеров, наши тестеры, которые на все руки получаются - это уже продвинутость.

Я тоже не хочу спорить - мы же не на интервью уже