Нужно ли вам больше Тестеров? Упражнение в рамках контекстного подхода.

Перевод вот этой вот статьи Майкла Болтона (от 29 Апреля 2007-го года)

Эта дискуссия о лучших практиках в отрасли началась недавно на comp.software.testing:

Сколько тестировщиков на разработчика считается лучшей практикой
при создании сложных веб-приложений с нуля? Я слышал о полутора тестировщиках на каждого разработчика. Что вы думаете по этому поводу?

Мой (слегка отредактированный для этого блога) ответ был...

• Если вы собираетесь найти все баги, то 100 тестеров на программиста будет куда лучше чем полтора. Ваши клиенты могут счесть это впечатляющим (если они захотят за это платить), но ваш финансовый директор взбесится. И все еще не будет никакой гарантии, что вы найдете все баги.
• Если вы хотите сэкономить, то 0 тестировщиков будет куда лучше, чем полтора на программиста. Это даже может сработать, но будет ли вы уверенны в том, что все важные вопросы о вашем продукте были заданы, а ответы на них были получены?
• Если уж вы собрались действительно сэкономить, то 0 тестеров на 0 программистов будет самым лучшим решением.

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

С моей точки зрения, на этот вопрос невозможно ответить, не обладая большей информацией о контексте - опыт работы в компании, с командой разработчиков, в технических или бизнес-областях? бюджет? график? размещение программистов и тестировщиков? цель тестирования? Другая точка зрения: вне зависимости от ответов на вопросы, озвученные выше, "лучшая практика" - бессмысленный маркетинговый термин, как правило означающий "что-то, что наша большая и дорогая консалтинговая компания продвигает потому, что это сработало для нас (или мы слышали, что для кого-то работает) ноль или более раз". "Лучшие практики в индустрии" еще хуже. Какой индустрии? Если вы разрабатываете биллинговое веб-приложение для медицинской компании вы в "веб"-индустрии, в индустрии "програмного обеспечения", в индустрии "медицинских услуг" или в "финансовой" индустрии? Я писал уже о "лучших практиках" для журнала Better Software; вы можете найти статью тут (http://www.developsense.com/articles/Comparitively%20Speaking.pdf).

Квалифицированные тестировщики могут помочь нам снизить риск незнания чего-то, что мы бы предпочли знать о системе. Так вот, вместо того чтобы смотреть на тестировщиков как на функцию от числа программистов, попробуйте задаться вопросом: "Что бы мы хотели знать из того, что мы не можем обнаружить иначе? Какие задачи могут возникнуть в процессе обнаружения этих вещей? Кого бы мы хотели назначить для выполнения этих задач?". И если вы все еще не понимаете - найдите тестировщика (просто одного квалифицированного тестировщика), чтобы он помог вам задавать правильные вопросы и отвечать на них.

Один из ответов в той дискуссии был таким:

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

Это выгладит вполне разумным. Тем не менее, есть одна вещь которую проделывают последователи контекстного подхода для того, чтобы точить свое ментальное оружие. Мы берем утверждения вроде этого, и применяем к ним Правило (Как Минимум) Трех
 (которое пришло из работ Джерри Вейнберга). "Если вы не смогли придумать по меньшей мере трех альтернатив, то вы, вероятно, не достаточно подумали". Когда мы хотим умеренно потренироваться, мы ищем от (Как Минимум) Трех до (Как Минимум) Десяти.

Итак, выше мы видим один из возможных подходов для уменьшения уровня дефектов в релизе. Можем ли мы придумать по меньшей мере еще девять?

• Вам не нужно больше тестировщиков. Вам нужно меньше тестировщиков, но более квалифицированных, способных разработать более эффективные оракулы и шире охватить продукт.
• Вам не нужно больше тестеров. Вам нужны менеджеры по продуктам, которые не так охотно преуменьшают значение ошибок, откладывая их в долгий ящик.
• Вам не нужно больше тестеров. Вам нужны более квалифицированные программисты.
• Вам не нужно больше тестеров, и вам не нужны более квалифицированные программисты. Вам нужно просто внедрить у себя TDD.
• Вам не нужно больше тестеров. Вам нужно прекратить тратить время на написание подробных инструкций, начать описывать риски и идеи для тестов более сжато, доверять своим тестерам выполнять их собственные тесты, касающиеся актуальных рисков (и позволить им документировать их на лету).
• Вам не нужно больше тестеров, вам нужно чтобы ваши тестеры стали меньше тратить времени на совещания.
• Вам не нежно больше тестеров. Вам нужно выстроить более тесные отношения между тестерами, программистами, менеджментом и пользователями.
• Вам не нужно больше тестеров. Вам нужно сделать программу более тестируемой. Обеспечить ее легко скриптуемыми интерфейсами, хорошим логгированием и легкостью в конфигурировании.
• Вам не нужно больше тестеров. Вам нужны более частые циклы разработки и тестирования, чтобы уменьшить задержку между написанием программы, обнаружением  багов, и их исправлением.

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

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

Количество "пропущенных дефектов" это просто число. Ни одно число не скажет вам того что вам действительно нужно. Числа могут провоцировать вопросы, но мир очень сложное место. Если вы не придумали как минимум трех (или десяти, или семнадцати) возможных вариантов, то могут найтись важные варианты которые вы пропустили.