Как ручному тестировщику подружиться с автотестами и зачем это нужно

Автоматизация затронула все вокруг, и ручным тестировщикам уже сложно, да и непростительно оставаться в стороне. Ускорение рутинных задач, снижение влияния человеческого фактора, повышение качества тестирования — всё это требует вовлечения автотестов. Но можно ли пользоваться ими, не умея писать код и не разбираясь в нюансах разработки автоматических сценариев? На этот вопрос отвечает QA-инженер Test IT Дмитрий Самохвалов: можно и нужно!

В этой статье — проблемы и вызовы, с которыми он столкнулся на проекте, и как автотесты помогли их решить. Запасайтесь попкорном и поехали!

Когда ручного тестирования становится слишком много

Рассмотрим случай из практики: вернувшись из отпуска, я увидел, что в трекере задач меня поджидает сюрприз. В тест поступила новая функциональность — автоматический перезапуск упавших автотестов.

👉 О том, как работают рераны автотестов, мы писали в статье по ссылке

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

Запускается всем знакомый процесс: тест → отправка на доработку → ретест. Этот круг повторился три раза, то есть на этапе фича-тестирования пришлось прогнать 35 х 3 кейсов. 

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

Автотест, упавший на регрессе:

Начинаем выяснять: проблема в баге в новой фиче или в неактуальности автотестов? 

• Если первое, запускается очередной день сурка: «тест → доработка → ретест», и снова 35 кейсов по кругу.

• Если второе, ситуация не легче. Значит, автотесты нужно чинить: AQA спешно дорабатывает N сценариев, и делает это не в спокойной обстановке, а под давлением дедлайнов.

Что делать: ждать чуда или менять подход?

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

Шаг 1. Готовимся заранее: «сдвиг влево»

Нужен «сдвиг влево» в процессе подготовки к тестированию, то есть заранее находить (а если не выходит — выбивать) время на актуализацию ручных и автотестов, которые затронет новая функциональность. Идеально делать это еще до начала разработки: так можно выявить нюансы, упущенные при анализе постановки, и не тащить их потом в код.

Также на этом этапе стоит постучать в дверь отдела AQA/SDET, взять за руку открывшего специалиста и вместе пройтись по библиотеке автотестов. На основе вводных по новой функциональности и его знаний определить, какие автотесты может затронуть изменение в коде.

После пары таких походов стучаться больше не придется: вы и сами сможете собирать автотесты на актуализацию и приносить автоматизаторам готовые задачи на доработку API- и E2E-тестов. (Осторожно, автоматизаторы могут загрустить, что вы больше им не звоните).

Шаг 2. Точечная автоматизация с умом

Чем больше ручных тест-кейсов преобразуются в Е2Е-автотесты, тем меньше времени уходит на выполнение любимого, а порой и бесконечного процесса «тест → доработка → ретест». Также не забываем про регресс: большую часть тестов по функциональности будет проходить машина, а не ручной тестировщик, уязвленный багами на проде и задержкой релиза. 

Но не стоит автоматизировать все подряд. Если сценарий нужен 1–2 раза при фича-тестировании и не участвует в регрессе, то логичнее сэкономить силы и время коллег-автоматизаторов во благо общей цели — качества продукта.

Шаг 3. Учимся запускать и разбирать автотесты

Третий шаг логично вытекает из второго: самостоятельный запуск автотестов в рамках тест-плана при фича-тестировании и разбор возможных падений. Первое время, конечно, придется снова постучаться в уже знакомую дверь AQA/SDET, и там вас встретят с гостинцами: стек-трейсами, логами и скринкастами.

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

Шаг 4. Автотесты против багов с прода

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

Чек-лист по работе с автотестами без кода

• Подключайтесь к обсуждению фич до начала разработки и планируйте актуализацию тестов.

• Взаимодействуйте с AQA/SDET: определяйте, какие автотесты затронет новая фича.

• Отправляйте новые ручные тесты на автоматизацию. Особенно те, что часто используются.

• Запускайте автотесты самостоятельно и учитесь разбирать падения по логам и стек-трейсам.

• Обкладывайте баги с прода тест-кейсами и передавайте их на автоматизацию.

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

Объединяйте работу с ручными и автотестами в едином пространстве с помощью Test IT. Попробуйте возможности платформы на бесплатном тарифе