В отрасли информационных технологий очень широко распространено мнение, что обеспечение качества – задача тестировщиков. На мой взгляд, мнение – довольно спорное, поскольку тестировщик не может напрямую влиять на качество, соответственно – обеспечить его не может.
Я так считаю потому что, в большинстве случаев (беру страны пост-СССР), тестировщик:
- не задействован в коммуникации с заказчиком
Т.е. он не может вносить никаких изменений на уровне полльзовательских историй (например, не может изменить форму пользовательских историй, не участвует в выборе более качественных, не влияет на декомпозицию (разбиение) пользовательских историй, ...)
- не может контролировать объём работ (scope)
Список функциональности к разработке на итерацию в большинстве случаев согласовывается между тремя участиками: заказчик, менеджер и лидером команды разработки (тех. лид)
- не влияет на расписание/планирование
Я имею ввиту то, что при планировании разработки функциональности очень редко учитывается точка зрения тестировщика, который рассматривает скоуп с точки зрения оптимальной последовательности тестирования функциональностей
- не контролирует бюджет
Т.е. не имеет возможности при необходимости привлечь дополнительные человеческие или временные ресурсы (за редким исключением)
- не участвует в наборе/отборе кадров
Тут конечто не совсем всё плачевно, поскольку иногда на собеседование кандидатов приглашают тест лида проекта, однако для рядовых тестировщиков это поле деятельности остаётся вне компетении
- не имеет возможности изменять исходный код
Во-первых, потому что у основной массы тестировщиков на постсоветском пространстве просто не хватает для этого навыков. Во-вторых, потому что даже если навыки есть, доступ к исходному коду не всегда легко/возможно получить кому-то кроме команды разработки
- не влияет на расположение продукта на рынке
Для этого у заказчика есть маркетинговая команда, которая делает всю рабоду по позиционированию продукта
- не может вносить изменения в модель разработки
Тут, я думаю, комментарии излишни
Так как же тестировщик может обеспечить качество при таком раскладе?
На самом деле, тестировщик не может обеспечить качество, ему даже пытаться не стоит. Решения касательно качества и его обеспесения принимаются разработчиками, которые пишут код и менеджерами, которые ведут проект.
С этой точки зрения , когда тестировщик делает работу хорошо, он – предоставляем ценную, своевременную информацию о фактичестком состоянии продукта и проекта. Не тестировщик отвечает за качество, тестировщик лишь помогает людям, ответственным за качество и влияющие на него факторы, принимать грамотные решения.
Резюмируя, фраза «тестирование ПО и обеспечение качества» (Software Testing and Quality Assurance) будет правильнее в виде: «тестирование ПО и содействие в обеспечении качества» (Software Testing and QA Assistance)
Подписаться на:
Комментарии к сообщению (Atom)
Евгений, мне кажется ты слегка вырвал тестировщика из процесса и вставляешь его как "один в поле воин", а так не бывает. Ты прав, тестировщик не может прямо обеспечивать качество, он делает это косвенно. Зато может прямо контролировать это качество и предоставлять необходимые данные о состоянии продукта и дефектах техлиду и менеджеру проекта для совместного обеспечения качества.
ОтветитьУдалитьP.S. Если предоставить тестировщику полный доступ к обеспечению качества, то продукт не выйдет никогда. Тебе только волю дай ;)
В своём посте я, наоборот, хочу сказать, что «один в поле – не воин». Смысл в том, что для наилучшего обеспечения качества роль тестировщика должна быть повышена (собственно у меня часть вышеупомянутых полномочий есть :).
ОтветитьУдалитьЯ согласен с тобой по поводу - «может прямо контролировать это качество».
Тут речь идёт Контроле Качества (QC), где контроль = мониторинг (предоставление статуса проекта, прозрачность результатов тестирования, измерение статуса тестирования, тестового покрытия, проверка соответствия выходным критериям, сбор данных для оценки последующих работ по тестированию... ) + алертинг (уведомление об отставаниях по графику, новых рисках, возникших проблемах...) + реактивные действия (пересмотр вектора тестирования и перенаправление ресурсов в проблемные места, коммуникация с отделом разработки о повышении качества фиксов (например, в случае когда много переоткрытых дефектов), изменение списка рисков продукта...)
Но контролировать качество и обеспечивать его – это разные вещи.
Я это к тому, что: «Не надо обманываться. Никакого качества тестировщики (в большинстве случаев) не обеспечивают».
А вот с постскриптумом я не согласен -полный доступ к обеспечению качеством тестировщику никогда не дадут (ни тестировщику, ни разработчику, ни менеджеру), да он и не нужен. Однако, я считаю, что привлечение тестировщика в ряд мероприятий по обеспечению качества – весьма обоснован и может принести проекту огромную пользу (проект не только выйдет, но и качество его будет гораздо выше).