- Не надо торопиться
- Автоматизация всего
- Рандомные инструменты
- Медленные тесты
- Невнятные тесты
- Старые тестовые данные, смешанные с новыми
- Плохая структура тестов (вообще нет структуры)
- Селекторы!
- Неправильное время wait-ожиданий
Качество софта определяет успех любой технологической компании. Усилия QA-команды, которая непрерывно тестирует и обновляет продукт, удерживая его в приличном качестве — это важнейший фактор в конкуренции. Автоматизация QA помогает достичь превосходства, но что если тесты падают, а автоматизация не продвигается, несмотря на усилия? Надо применять лучшие практики автоматизации — и отказываться от устаревших.
Автоматизаторы, особенно новички, неизбежно допускают ошибки. Если QA Lead недостаточно опытен, или излишне полагается на популярные AI-based-инструменты с “подсказками”, или привык действовать шаблонно, то автоматизация не только не ускорит процессы как рассчитывает лид, а наоборот может вызвать проблемы.
Не надо торопиться, пропуская первые важнейшие этапы QA
QA-авторитеты советуют не торопиться в начале, тщательнее подходить к составлению списков функций “на автоматизацию” и особенно к выбору инструментов. Затем нелишне позадавать вопросы, “Какие проблемы здесь устранит автоматизация, а может справимся и без нее — слушайте, ручное получится быстрее”. Важно понимать цели и ожидания на каждом этапе автоматизации, не увлекаться. А также проверить, чтобы каждый инструмент автоматизации решал проблемы, а не создавал их (как иногда случается с модными фреймворками). Ускорение тестового процесса автоматизацией надо как-то измерять количественно.
Автоматизация всего на свете
Не нужно автоматизировать неподходящие для автоматизации вещи. Например не нужно стремиться (да и вряд ли получится) автоматизировать все регрессионные тесты. На бесплодные попытки уйдет время. Не нужно тратить кучу времени на сборку фреймворка и написание сопутствующих скриптов. Надо автоматизировать “повторяющиеся” тесты, то есть те которые ручные тестировщики запускают много раз и это их утомляет. Автоматизация тестов производительности — необходима и почти всегда “окупается”. Автоматизация невыгодна и задерживает пайплайн, если тестировщик имеет дело с кодом, который постоянно меняется.
Рандомные инструменты
Выбор инструментов должен быть продуманным, не впопыхах. Не существует одного идеального инструмента “под все задачи”. Выбирать инструменты нужно до того как определены задачи, и вот тут прошлый позитивный опыт бывает нерелевантным. Потратить, скажем, неделю на выбор правильного инструмента — потом сэкономит месяц времени и миллион нервных клеток.
QA-инструменты по умолчанию рассчитаны на разные компетенции тестировщиков. Тестировщики “технические”, или совмещающие должность разработчика (“developer tester”), или тестирующие бизнес-логику — в идеале должны работать с разными инструментами, сообразно задачам, и уровню своих компетенций. (Кстати свежий гайд по инструментам автоматизации здесь).
NB: в целом, качественные специализированные QA-инструменты как правило платные. Если бюджет на QA не позволяет этого, можно пробовать trial-версии, тем более что не всегда QA-инструмент будет нужен надолго.
Медленные тесты
С усложнением продукта, добавлением функций, его тестирование конечно усложняется. Больше кода = больше тестов. Тестировщики устают писать однотипные тесты, начинают халтурить и ошибаться. Бывают и более сложные проблемы, с архитектурой и селекторами. Но есть способы более-менее легкого “обхода” проблем с медленными тестами (здесь, здесь, и здесь советы по ускорению тестов).
Невнятные тесты
Кэп: надо писать тесты, простые для словесного описания на митинге, для чтения и понимания, так чтобы тестировщик хотя бы мог сам разобрать их потом. Соблюдай принцип KISS или, хотя бы!, давай тестам правильные понятные имена. Нечитаемые тесты это проблема. Надо стремиться, чтобы чтение кода тестов занимало не больше времени, чем их написание.
Старые тестовые данные, смешанные с новыми
Надо вносить правки в старые тесты, и делать это регулярно, и не включать в новые тесты устаревшие тестовые данные. Лучше “изолировать”. Применяй API-запросы для генерации тестовых данных, и выполняй их “изолированно”.
Плохая структура тестов (вообще нет структуры)
Нужна правильная структура тестов, “правильная” означает “упорядоченные тесты”, в рамках продуманной стратегии тестирования (здесь) — это обеспечит качественный код автотестов, независимо от выбранного языка.
Каждый тест, по идее, должен начинаться с описания переменных, которые будут тестироваться, затем тестовые задачи, прописанные в логичном порядке.
Селекторы!
Автотесты, основанные на селекторах, которые имеют свойство часто меняться (те же CSS-селекторы) — это может привести к задержкам, и чаще всего приводит. То есть, тест будет падать не из-за бага, а из-за “устаревшего” селектора.
Неправильное время wait-ожиданий
Тесты “падают”, если время выполнения тестов прописано короче, чем время реакции приложения. Слишком большие ожидания делают тест неэффективным и падающим. Wait-время надо подбирать тщательнее.
