Я вам расскажу про среднестатистических тестировщиков. Не про талантливых, а про обыкновенных.
Чтобы тестировщик мог выполнять свою функцию - давать информацию о сборке - надо им обьяснить продукт.
Полезно дать общий обзор архитектуры приложения, чтобы они приблизительно понимали на каком слое ошибка находится. Если им это будет слишком сложно надо брать других тестировщиков. Тестировщики без технического понимания и интереса - это не лучшее вложение.
Если тестировщик никак не проявляет инициативы - тоже плохо.
Спрашиваешь тестировщика:
- Чем ты сегодня занимался?
- Тестировал.
- Что тестировал?
- Все тестировал.
яркий пример того, что тестировщик не понимает, что его продукт - информация. Или ему вообще не обьяснили чего от него хотят. Проблема скорее руководителя.
Если тестировщик не производит информации - он бесполезен.
Еще нельзя тестировщиков сажать в отдельное помещение. В изоляции они будут неэффективно работать.
Полезно и необходимо приводить тестировщика на планировочные собрания, где обсуждаются новые функции.
Все изменения продукта, спецификации, необходимо сообщать тестировщику. Не надейтесть что среднестатистический тестировщик будет прибегать к вам с вопросами. Он будет сидеть, а потом говорить "а откуда бы мне это было знать". И будет по-своему прав.
Вобщем, если вы думаете, что посадив х тестировщиков на зарплату в проект вы увеличите качество - нет, этого не произойдет. Придется четко проработать весь процесс как вы будете общаться и прередавать информацию. По возможности вместе с тестировщиками.
Чем чаще вы будете оставлять тестировщика "за бортом" тем менее эффективно он будет работать.
Нужно чтобы тестировщик чувствовал свою отвественность за продукт. Для этого он должен быть частью команды. Чем больше отвестственности вы возложите на тестировщика тем быстрее он вырастет. Будете относиться к нему как к чуваку для мебели - он таким и станет.
Если вы не знаете, что хотите от тестировщика - то он не знает тем более. Разработчик без задания тоже не знает что делать. Нужно поставить тестировщикам задачи. И желательно с письменной отчетностью. Скажу вам сразу это все не так просто, и дополнительная работа для руководителя. Но можно взять тест-менеджера. Он знает как использовать тестировщиков эффективно. Как поставить отчетность и пр.
Еще о предубеждениях.
Часто получается разделение на лагерь разработчиков и тестировщиков - это слышно по лексике употребляемой в общении. Если тестировщик считает, что он должен "сломать продукт", "найти в нем баги", если он думает что он работает "против разработчиков" или если разработчики считают, что работают против тестировщиков - все это нонсенс от которого надо избавляться сразу. Когда клише сложатся - будет поздно. Для этого нужно серьезно относиться к тестировщику и нагрузить его конкретными обязанностями.
Если вы не знаете какие задачи поручить тестировщику - решите этот вопрос в первую очередь.
Например, можно, кроме всего прочего, поручить им замечать, какие сценарии очень трудны в выполнении или выполняются чаще всего, т.е. являются кандидатами на автоматизацию. Если вы начнете вводить автоматизацию, у вас уже будет набор первичных целей.
Подведем итог: чем конкретнее задача поставленная тестировщику - тем (внезапно) больше пользы от его работы.
