На этот вопрос дать конкретный ответ весьма затруднительно, но существуют различные взгляды и мы рассмотрим самые распространенные из них.
Первый подход заключается в том, чтобы как можно скорее передать выявленную ошибку разработчикам, четко указать, как воспроизвести ошибку, написать отчет и на этом закончить.
Второй подход утверждает, что ценность тестировщика увеличивается, когда он может помочь разработчику найти основную причину бага.
Существует и третий подход, в котором утверждается, что способность исправлять ошибки является вершиной профессионализма тестировщика. Тестировщики знакомы с кодом, могут скомпилировать его и создать сборки. Когда они обнаруживают ошибку, то начинают искать ошибку в коде и предлагают исправление в отчете об ошибках.
Самым оптимальным можно считать второй подход. В первом подходе упускается возможность помочь разработчикам исправить ошибку за короткое время. Хочется верить, что этот подход не является общепринятым в командах, которые стремятся к развитию и получению новых навыков.
Второй подход предполагает, что роль тестировщика заключается не только в обнаружении ошибок, но и в предоставлении информации, которую разработчики могут эффективно обработать в сжатые сроки. Помимо сообщений об ошибках, от тестировщиков ждут, что они найдут самый простой способ воспроизвести ошибку, а также предоставят журналы, скриншоты и любые другие важные данные. Как только эти данные накапливаются и предоставляются разработчику, он может немедленно искать пути исправления и реализовывать их.
Третий подход, хорошо оправдывает наличие путей для развития тестировщика. Это позволяет тестировщикам работать с кодом, глубже осваивать понимание архитектуры и дизайна и, возможно, получать больше удовольствия от работы. Кроме того, тестировщики теснее сотрудничают с разработчиками, и это доказывает то, что они могут выполнять тот самый спектр работ, что и сами разработчики. В следствии чего повышается их ценность на рынке, как специалистов. Это также опровергает представление о том, что тестирование - это просто деструктивная профессия, так как тестировщики имеют дело с фактическим развитием продукта. Третий подход имеет веские положительные стороны, но он по своему не идеален.
Прежде всего, недостатком третьего подхода является то, что тестировщики зацикливаются на развитии. Тестировщики-профессионалы в этом подходе воспринимаются не те, у кого есть умение находить критические ошибки, а те, кто их ещё может и исправить.
Второй недостаток выплывает из первого, разработчики привыкают к тому, что их ошибки может исправить кто-то другой. Следовательно, качество их работы может пострадать, они не чувствуют на себе последствий неправильно написанного кода. Наконец, ещё одна причина неидеальности этого подхода заключается в том, что в то время, пока тестировщик занят работой с кодом, можно было бы запустить другие тесты и проверить продукт более тщательно.
Даже если дополнительные тесты не обнаруживают баги, мы можем получить полную уверенность в качестве продукта, что и является одной из целей тестирования. Каждый из указанных выше нюансов, на наш взгляд, оправдывает отказ тестировщика от работы с кодом. Так же есть ещё несколько нюансов по этой теме. Один из них связан с разработкой автоматизации тестирования. Есть много команд, в которых автоматизация тестирования стоит в приоритете. Это естественный процесс, когда команда решает инвестировать ресурсы в автоматизацию, она становится флагманским проектом менеджеров. Обычно в начале такого процесса прогресс идёт впечатляюще быстро, а те, кто вовлечен в это дело получают быстрый карьерный рост. В определенный момент руководство понимает, что им стоит задействовать некоторых QA исключительно для работы в автоматизации и это немного интереснее, нежели запуск регрессионных тестов. И вскоре складывается ситуация, что любой тестировщик, кто хочет повышения стремится уйти в автоматизацию.
Поскольку навыки, необходимые для автоматизации, ориентированы больше на разработку, а не на тестирование, вы получаете команду тестировщиков, целью которой является улучшение навыков разработки, а не улучшение их навыков как тестировщиков.
Исходя из этого логичным выводом является тот, что второй подход есть наиболее оптимальным и в плане развития тестировщика как специалиста, и так же в плане вкладывания ресурсов в тот или иной проект. Правильно распределив зоны ответственности между тестировщиками и разработчиками, можно избежать многих проблем.
14 июня / 2018
