Очень интересно наблюдать за командами, которые только перешли на разработку по гибким методологиям. Пока они перестраиваются и, по факту, живут маленькими waterfall’чиками, они задаются следующими вопросами:
- А что, тестировщики (QA), первую половину спринта в гибернации находятся?
- А как по завершению спринта на прод выкатывать, если тестировщики физически не успеют проверить то, что мы накодили в последний день спринта?
- А что, у тестировщиков сдвинутый на неделю относительно разработки спринт?
Давайте попробуем разобраться чем могут заниматься QA инженеры при разработке по agile, ведь действительно что им делать если еще ничего не разработано?
Есть такой анекдот:
Тестер заходит в бар. Заказывает 1 пиво. Заказывает 0 пива. Заказывает 9999999 пив. Заказывает ящерицу. Заказывает -1 пиво. Заказывает 'qwerty'. Заказывает 'drop table'
Первый реальный клиент входя в бар спрашивает “Где тут туалет?”, отчего бар сгорает в огне.
Глубокое понимание продукта и понимание бизнеса - это критически важный скилл и носителями этого скилла выступают QA. Они способны понять, что бар это не только напитки, но еще и место, где есть туалет. Более того, именно QA могут лучше всех оценить то, что проверить кейс, когда клиент сначала спросит “где таулет” значительно важнее, чем проверить заказ ящерицы.
На конференции по тестированию подслушал термин “брейнуальное тестирование” - это как раз о понимании продукта и бизнеса. Именно им стоит заниматься в начале спринта. Подключившись на этапе работы с требованиями экспертиза QA позволяет проверять качество бизнес-процесса, который предстоит автоматизировать. Благодаря особенностям своего мышления, QA сразу обращает внимание команды на всякие граничные случаи, которые, как правило, всплывают, когда какая-то часть закодирована и потом нужно много чего переделывать, чтобы все заработало как надо.
Еще QA могут оказывать влияние на дизайн и архитектуру разрабатываемой системы, улучшать показатель тестируемости продукта (снижать количество усилий, которые нужно приложить для того, чтобы проверить качество), совместно с разработчиками автоматизировать тестирование продукта.
Таким образом при разработке по гибким методологиям QA не занимаются тем, что когда-то потом проверяют все то, что накодили разработчики. Они заняты встраиванием качества в процесс производства программного обеспечения.
В качестве заключения:
Чем больше рутинной работы будет автоматизировано (в том числе тестирование), тем больше времени высвободиться на придумывание и реализацию новых крутых фич.
#agile #agiletesting #qa #programming #programmer #softwaredevelopment #softwaredeveloper