Еще один верный шаг на пути к хорошему тестированию

Я согласен с тем, что для того хорошо тестировать программы, тестеровщик должен знать предметную область и владеть техниками тестирования. Причем оба аспекта можно подтянуть по ходу работы, если навыков не хватает.

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

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

Уже сейчас на совещаниях с разработчиками я задаю вопросы не потому что мне не понятно как они собираются решать задачу, а потому чтобы заставить их самих сомневаться в правильности своего решения. Если разработчик продумал все "За" и "Против", а значит оценил все риски в используемом подходе, то здесь можно быть спокойным. Тестировщику в этом случае достаточно просто перенести все что говорит разработчик на бумагу в виде TTL/TSO и ждать когда фича или ее кусочки будут готовы к тестированию.

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

Сегодня когда разработчики сами пишут тесты, роль тестировщика в проекте может сводиться  функции к консультанта по организации тестирования, конечно же не без участия в самом процессе тестирования. Умение задавать "правильные" вопросы является важным элементом в работе тестировщика.