Жизнь без тестировщиков: миф или реальность?

Бытует противоречивое мнение, что на проекте обязательно должен быть тестировщик. Но многие известные зарубежные проекты не имеют выделенных тестировщиков, особенно для привычных нашему миру задач. Как же так? Кто в этом случае будет отвечать за качество продукта? Кто будет искать и находить дефекты? Да и вообще, возможно ли такое? Если вас заинтересовали ответы на эти вопросы, то добро пожаловать под кат.

А в чем собственно проблема?

Давайте начнем с проблемы, чтобы лучше понять дальнейший ход размышлений. Речь снова пойдет о некотором обмане заказчика (первый обман был описан в статье «Не обманывайте своих заказчиков»). Представим ситуацию обсуждения проекта и состава команды с заказчиком. Происходит вот такой вымышленный диалог:

— Вот, все как вы просили, Иван Федорович! Мы отобрали опытных и очень грамотных специалистов для вашего проекта. Да, стоят они немало, но зато это действительно профессионалы.
— Отлично, спасибо! Я готов платить за качество и уровень членов моей команды. А чем будут заниматься еще несколько человек, которые обозначены в плане как тестировщики?
— Иван Федорович, Иван Федорович… Ну как же? Ведь нужно будет следить, чтобы команда делала именно то, что вы заказывали и при этом не ломала постоянно то, что уже было сделано до этого. Вы же понимаете…
— Но ведь мы только что говорили о профессионалах, за которых я вам собираюсь платить кучу денег! Они что же не могут сразу сделать работу правильно и без проблем?
— Все мы не без греха, Иван Федорович. Сколько проектов делаем, всегда дефекты лезут и лезут, не остановить их… Это IT, тут все не так просто, вы же понимаете…
— Вы знаете, я пожалуй поищу себе другую команду!

Говоря по правде, такой диалог практически никогда не случается на самом деле. Никто никогда открыто не скажет, что его высокооплачиваемые «специалисты» собираются делать некачественную работу и нужен кто-то, чтобы ее контролировать. Обычно тестировщиков продают совершенно под другим «соусом». В ход идут аргументы о независимом контроле качества, интеллектуальной работе по предотвращению дефектов для конечных пользователей, анализе уровня качества и подготовке отчетов на эту тему.

Но что происходит потом на самом деле? Тестировщики тратят свое время на поиск дефектов, проходя одни и те же сценарии руками многократно (или же пытаясь их «автоматизировать»), ругаются с разработчиками за исправления найденных дефектов, «отчитываются» за качество перед менеджерами и т.д. Вся их работа упирается в то, что изначальная работа разработчиков сделана некачественно. Получается, что заказчик платит дважды: один раз за труд высококвалифицированных разработчиков, а потом за труд людей, которые добьются от них качества. Это ли не обман?

Почему так происходит

На мой взгляд, причина такой ситуации на рынке заключается в неверном видении процесса тестирования и роли тестировщика в нем на протяжении долгого времени. Считалось, что ответственность за качество перекладывается с самого разработчика на специалиста по контролю качества. А раз она перекладывается, то сам разработчик особо не переживает и может делать некачественное решение. Поэтому нередки ситуации, когда разработчик почти не проверяет свою работу и этим занимается только тестировщик. Как следствие, большой процент возвратов на исправления и доработки, большие потери времени и отсутствие доверия.

Но в других сферах жизни так не делают. За качество отвечает тот, кто производит товар или услугу, то есть исполнитель. В нашем случае это и есть сам разработчик. Поэтому отвечать за обеспечение качества своей работы он должен самостоятельно. Чем более профессиональным работником он себя выставляет и чем большую плату за свою работу берет, тем более качественное решение должно получаться на выходе. Никто не должен платить дополнительно за те дефекты, которые он сделал и потом исправил. Если мы говорим о профессионалах…

Роль тестировщика на проекте

Так кто же должен выполнять роль тестировщика на проекте? Прежде всего, важно понять что это роль, а не конкретный человек. И эту роль надо распределить по членам команды. Итак, кто за что будет отвечать:

• Заказчик или его «уполномоченный представитель» (в простонародье Product Owner) может взять ответственность за подготовку приемочных критериев, чтобы потом вместе с командой выработать приемочные тесты. В этой статье на примере отдельно взятой команды описан данный процесс.
• Те же лица могут взять на себя приемку готовой работы в конце итерации или другого срока ее выполнения. Это звучит вполне логично — тот, кто заказывал работу, должен ее и принять. Причем, лучше это ни у кого не получится сделать. Тестировщик не может брать на себя такую ответственность.
• Разработчики могут взять на себя обеспечение технологического процесса разработки, в котором минимальна вероятность ошибки. В этом им отлично помогут инженерные практики: Code Review, парное программирование, Continuous Integration, TDD и прочие. Ну и конечно же автоматизированное тестирование на всех уровнях (модульное, интеграционное, функциональное), что у разработчиков получается гораздо лучше.
• Разработчики могут взять на себя обеспечение устойчивости к регрессии, автоматизировав процессы прогона приемочных тестов и сделав их регулярно повторяющимися на каждое изменение в коде продукта.

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

То есть тестировщик нужен и полезен, но не в классическом его представлении, к которому многие из нас привыкли. Все простые и незамысловатые ответственности тестировщика могут быть распределены между членами команды. Это сделает ее более ответственной за качество, уменьшит ее размер и поможет стать настоящей командой, целью которой является разработка качественного продукта.

Заключение

Задумайтесь над ролью тестировщика в современной разработке. Все больше и больше разработчиков вовлекаются в тестирование для обеспечения качества своей работы. Заказчики все больше интегрируются в процесс разработки, забирая определенную часть работы тестировщиков на себя. Потихоньку роль ручных «дешевых» тестировщиков, выполняющих механическую работу, просто отпадет за ненадобностью. И вы должны быть к этому готовы!

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