Home

Автор: Кристин Джеквони (Kristin Jackvony)
Оригинал статьи
Перевод: Ольга Алифанова

Новый год – время задуматься, как ваша команда может улучшить качество продукта! Я часто слышу, как тестировщики жалуются, что стали «бутылочным горлом» для своей команды. На них постоянно давят, чтобы они закруглялись с тестированием, и им кажется, что у них не остается времени на качественное исследовательское тестирование или хорошую автоматизацию.

Мой опыт говорит, что тому есть девять основных причин. Читайте дальше, чтобы проверить, применимы ли они к вашей команде!

Первая причина: у команды слишком много технического долга

Когда продукт тонет под техническим долгом, тестирование и исправление багов сильно осложняются. ПО зачастую нужно тщательно настраивать перед прогоном тестов, а автоматизация будет очень нестабильной. Когда разработчики исправляют баги, то ломают что-то другое, и в результате нужно исправлять и перепроверять новые проблемы. Это лечится приоритезацией технического долга, что ускорит и разработку, и тестирование.

Вторая причина: у команды нет адекватных приемочных критериев

Доводилось ли вам работать в проекте с невнятными юзер-стори и приемочными критериями? В результате команда вслепую летит к финалу. Никто не знает, в какой момент прилетит запрос о забытой фиче. Не зная масштаба проекта, нельзя точно оценить, сколько займут работы. Если разработка занимает больше, чем ожидалось, то чудес начинают ждать от тестировщиков – теперь они должны проверять вдвое больше за то же самое время. Наилучшее решение – отказываться от работы, если у проекта нет внятных юзер-стори и приемочных критериев. Если владелец продукта хочет что-то добавить в последний момент, надо менять сроки проекта, чтобы на дополнительную разработку и тестирование хватило времени.

Причина третья: разработчики не полностью кодируют стори

Разработчики иногда так погружаются в решение проблем программирования, что забывают оглянуться назад и проверить приемочные критерии стори, дабы убедиться, что все требования выполнены. Они передают стори тестировщику, который быстро обнаруживает нехватку требований и возвращает все назад. Этот пинг-понг может сильно замедлить жизнь проекта. Разработчик, возможно, уже начал работу над следующей стори, и теперь должен переключиться на другой контекст. Тестировщику приходится искать, над чем поработать, пока стори в разработке, а затем – переключить контекст на стори, когда она будет завершена. Если это реальность вашей команды, сообщите об этом на ретро – возможно, этого будет достаточно, чтобы команда осознала проблему. Она может выработать привычку проверять приемочные критерии перед передачей стори в тестирование.

Причина четвертая: разработчики не устраивают эстафетных встреч с тестировщиками

На эстафетной встрече разработчик, работавший над стори, встречается с тестировщиком, который будет ее тестировать. Они демонстрируют проделанную работу, показывают, как ее можно тестировать, и подчеркивают области, которые нуждаются в регрессионном тестировании. Тестировщик затем может задавать любые вопросы о фиче и том, как ее тестировать. Если команда не внедряет такие встречи, то тестировщик с шансами обнаружит, что фича не доехала до тест-стенда, или что он не понимает, как это тестируется. В результате понадобится задавать кучу вопросов, которые замедлят тестирование.

Причина пятая: нехватка юнит-тестов

Юнит-тесты, которые, как правило, создаются разработчиками – отличный способ быстро выловить проблемы. Когда разработчик пушит код в ветку, создается сборка и прогоняются юнит-тесты. Любая сломанная кодом разработки функциональность будет обнаружена за считанные секунды. Затем проблему можно исправить до передачи фичи в тестирование. Если юнит-тестов, отлавливающих проблемы, недостаточно, проблемы переходят к тестировщику напрямую, и ему придется сообщать о багах. Время, потраченное на баг-репорты – это время, которые тестировщик мог бы провести за исследовательским тестированием и нахождением более сложных багов.

Причина шестая: команда не привязала API-автоматизацию к билдам и деплою

Автоматизированные API-тесты почти так же полезны, как юнит-тесты – они ловят все изменения в коде, которые могли повлиять на поведение API. К примеру, изменение в коде могло случайно изменить код ответа с 401 на 403, что вызовет ошибки интерфейса. Если API-автоматизация запускается при каждом билде и каждом деплое, проблемы обнаруживаются до того, как фича уходит в тестирование, и это, опять-таки, бережет время и силы тестировщика.

Причина седьмая: нет хорошего процесса переиспользования регрессионных тест-планов

Исследовательское тестирование – отличный способ поиска багов, но для уже существующего продукта или фичи важно иметь список того, что нуждается в тестировании в ходе регресса. Без такого списка легко позабыть про менее популярную часть фичи. К примеру, тестируя приложение для электронной коммерции, тестировщик может забыть про удаление товара из корзины, концентрируясь только на оформлении заказа. Если хорошая система создания и сохранения регрессионных тест-планов отсутствует, планы придется создавать заново при каждом релизе. Это отнимает ценное время, которое можно было бы потратить на тестирование. Набор регрессионных тест-планов, которые можно использовать снова и снова, сбережет достаточно времени на исследовательское предрелизное тестирование.

Причина восьмая: разработчики не участвуют в тест-автоматизации

Да, хорошие тестировщики умеют писать хорошую автоматизацию, но разработчики здорово пишут код, и могут прекрасно помочь писать код чисто, создавать переиспользуемые методы и настраивать заглушки для тестирования. Когда в команде всего один тестировщик, самостоятельно занимающийся автоматизацией, этот процесс будет замедлен. Возможно, стоит указать команде, что наличие хороших, надежных автоматизированных тестов пойдет на пользу всем, а не только тестировщику. Разработчики получат быструю обратную связь, что предотвратит времязатратное переключение между контекстами.

Причина девятая: команда слишком сильно полагается на UI-автоматизацию

Безусловно, у UI-автоматизации есть свое место – тут тестируется видимость и функциональность элементов интерфейса. Но основная бизнес-логика приложения может быть проверена при помощи юнит- и API-тестов. Все мы знаем, как медленна и нестабильна UI-автоматизация, даже если тесты отлично написаны. При помощи юнит- и API-тестов команда может быстрее получать точную обратную связь. И эти тесты легче поддерживать – они более стабильны.

Применима ли какая-то из этих причин к вашей команде? А может, применимо большинство? Выберите одну и обсудите ее с командой. Возможно, вам удастся спланировать решение этой проблемы, и «бутылочное горло» испарится!

Обсудить в форуме