Бытует противоречивое мнение, что на проекте обязательно должен быть тестировщик. Но многие известные зарубежные проекты не имеют выделенных тестировщиков, особенно для привычных нашему миру задач. Как же так? Кто в этом случае будет отвечать за качество продукта? Кто будет искать и находить дефекты? Да и вообще, возможно ли такое? Если вас заинтересовали ответы на эти вопросы, то добро пожаловать под кат.
А в чем собственно проблема?
Давайте начнем с проблемы, чтобы лучше понять дальнейший ход размышлений. Речь снова пойдет о некотором обмане заказчика (первый обман был описан в статье «Не обманывайте своих заказчиков»). Представим ситуацию обсуждения проекта и состава команды с заказчиком. Происходит вот такой вымышленный диалог:
— Вот, все как вы просили, Иван Федорович! Мы отобрали опытных и очень грамотных специалистов для вашего проекта. Да, стоят они немало, но зато это действительно профессионалы.
— Отлично, спасибо! Я готов платить за качество и уровень членов моей команды. А чем будут заниматься еще несколько человек, которые обозначены в плане как тестировщики?
— Иван Федорович, Иван Федорович… Ну как же? Ведь нужно будет следить, чтобы команда делала именно то, что вы заказывали и при этом не ломала постоянно то, что уже было сделано до этого. Вы же понимаете…
— Но ведь мы только что говорили о профессионалах, за которых я вам собираюсь платить кучу денег! Они что же не могут сразу сделать работу правильно и без проблем?
— Все мы не без греха, Иван Федорович. Сколько проектов делаем, всегда дефекты лезут и лезут, не остановить их… Это IT, тут все не так просто, вы же понимаете…
— Вы знаете, я пожалуй поищу себе другую команду!
Говоря по правде, такой диалог практически никогда не случается на самом деле. Никто никогда открыто не скажет, что его высокооплачиваемые «специалисты» собираются делать некачественную работу и нужен кто-то, чтобы ее контролировать. Обычно тестировщиков продают совершенно под другим «соусом». В ход идут аргументы о независимом контроле качества, интеллектуальной работе по предотвращению дефектов для конечных пользователей, анализе уровня качества и подготовке отчетов на эту тему.
Но что происходит потом на самом деле? Тестировщики тратят свое время на поиск дефектов, проходя одни и те же сценарии руками многократно (или же пытаясь их «автоматизировать»), ругаются с разработчиками за исправления найденных дефектов, «отчитываются» за качество перед менеджерами и т.д. Вся их работа упирается в то, что изначальная работа разработчиков сделана некачественно. Получается, что заказчик платит дважды: один раз за труд высококвалифицированных разработчиков, а потом за труд людей, которые добьются от них качества. Это ли не обман?
Почему так происходит
На мой взгляд, причина такой ситуации на рынке заключается в неверном видении процесса тестирования и роли тестировщика в нем на протяжении долгого времени. Считалось, что ответственность за качество перекладывается с самого разработчика на специалиста по контролю качества. А раз она перекладывается, то сам разработчик особо не переживает и может делать некачественное решение. Поэтому нередки ситуации, когда разработчик почти не проверяет свою работу и этим занимается только тестировщик. Как следствие, большой процент возвратов на исправления и доработки, большие потери времени и отсутствие доверия.
Но в других сферах жизни так не делают. За качество отвечает тот, кто производит товар или услугу, то есть исполнитель. В нашем случае это и есть сам разработчик. Поэтому отвечать за обеспечение качества своей работы он должен самостоятельно. Чем более профессиональным работником он себя выставляет и чем большую плату за свою работу берет, тем более качественное решение должно получаться на выходе. Никто не должен платить дополнительно за те дефекты, которые он сделал и потом исправил. Если мы говорим о профессионалах…
Роль тестировщика на проекте
Так кто же должен выполнять роль тестировщика на проекте? Прежде всего, важно понять что это роль, а не конкретный человек. И эту роль надо распределить по членам команды. Итак, кто за что будет отвечать:
- Заказчик или его «уполномоченный представитель» (в простонародье Product Owner) может взять ответственность за подготовку приемочных критериев, чтобы потом вместе с командой выработать приемочные тесты. В этой статье на примере отдельно взятой команды описан данный процесс.
- Те же лица могут взять на себя приемку готовой работы в конце итерации или другого срока ее выполнения. Это звучит вполне логично — тот, кто заказывал работу, должен ее и принять. Причем, лучше это ни у кого не получится сделать. Тестировщик не может брать на себя такую ответственность.
- Разработчики могут взять на себя обеспечение технологического процесса разработки, в котором минимальна вероятность ошибки. В этом им отлично помогут инженерные практики: Code Review, парное программирование, Continuous Integration, TDD и прочие. Ну и конечно же автоматизированное тестирование на всех уровнях (модульное, интеграционное, функциональное), что у разработчиков получается гораздо лучше.
- Разработчики могут взять на себя обеспечение устойчивости к регрессии, автоматизировав процессы прогона приемочных тестов и сделав их регулярно повторяющимися на каждое изменение в коде продукта.
Получается, что тестировщик в хорошей профессиональной команде не так и нужен? Это не совсем так. Ведь есть действительно важные и интеллектуальные активности для тестировщика, которые надо уметь делать профессионально и многие из которых скучны или неподвластны другим. Вот пара примеров: тестирование методом свободного поиска, помощь в критическом анализе требований, помощь в составлении приемочных тестов с использованием всех техник тест-дизайна, опыт и чутье на известные и популярные типы проблем, тестирование безопасности и производительности…
То есть тестировщик нужен и полезен, но не в классическом его представлении, к которому многие из нас привыкли. Все простые и незамысловатые ответственности тестировщика могут быть распределены между членами команды. Это сделает ее более ответственной за качество, уменьшит ее размер и поможет стать настоящей командой, целью которой является разработка качественного продукта.
Заключение
Задумайтесь над ролью тестировщика в современной разработке. Все больше и больше разработчиков вовлекаются в тестирование для обеспечения качества своей работы. Заказчики все больше интегрируются в процесс разработки, забирая определенную часть работы тестировщиков на себя. Потихоньку роль ручных «дешевых» тестировщиков, выполняющих механическую работу, просто отпадет за ненадобностью. И вы должны быть к этому готовы!
Кому интересны детали организации подобного процесса, вот презентация и видео одного из моих выступлений с докладом на эту тему на конференции. Тут можно найти несколько вариантов разной длительности и формата.
Автор: xpinjection
