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