Я все глубже погружаюсь в автоматизированное тестирование, и хотя это очень увлекательно, я нахожу некоторые препятствия на своем пути; мне любопытно, как вы справляетесь с трудностями, когда что-то идет не по плану. Когда тесты периодически дают сбои или когда новые функции неожиданно что-то ломают, как вы подходите к устранению неполадок и выяснению первопричины?
А также какие стратегии вы используете, чтобы все было организовано по мере роста количества тестов и фреймворков?
Крайне общий вопрос, поэтому конкретики в ответе тоже не будет.
Логи.
Должны быть максимально детальными. Я б рекомендовал делать как минимум 3 error level’а: debug, info и error и привязать к конфигурации запуска / командной строке. В нормальной ситуации юзаем info, если что-то плохо - переходим на debug и ищем причину.
Если тесты для UI, то рекомендую подсвечивать упавший контрол в скриншоте (как это сделать - можно найти на stackoverfow) - оч помогает сразу понять причину падения в 70% случаев.
Flaky tests. Лечится нахождением причины нестабильности. Может быть:
плохо прописанные waits;
race conditions (если тесты запускаются в многопоточном режиме);
плохой набор тестовых данных (например, тест пытается создать уже существующую entity, user’а, к примеру);
неправильный cleanup (чистит не то / слишком много / слишком мало);
ошибка в логике теста (для обнаружения этой ошибки достаточно 2 раза пройти тест мануально / под дебагом);
зависимые тесты (тест 2 рассчитывает на результаты теста 1, а он упал или не был запущен)
динамические контролы в DOM
Насчёт апдейта тестов по причине изменения функциональности - это нормальный процесс.
Анализируете приходящие в спринт стори, используя технику impact analysis можете предсказать, какие тесты будут затронуты.
Есть несколько подходов, как с этим жить.
Если проект завязан на 100% automation, то, чтоб не тормозить с тестами, просите какие-нить мокапы для UI (когда контролы есть, а логики под них ещё нет, этого достаточно для 90% тестов) / моки для backend (или даже просто хедеры запросов в swagger), пилите тесты, затем, когда подъезжает логика, быстро проверяете, что всё норм. Подход вкусный, но требует прям значительного перерасхода труда разрабов, не всегда на него соглашаются;
Если QA команда большая, можно быстро написать автотесты под новую фичу, если она не слишком большая. Для этого заранее прописываем под неё же мануальные тесты (это можно сделать по требованиям, без фичи), отмечаем те, что пойдут на автоматизацию и, как фича подъезжает, быстренько запиливаем тесты до конца спринта;
Если QA команда небольшая и / или перегружена работой и не успевает работать в таком ритме, делаем по-другому: выводим затронутые тесты из скоупа (например, тегируем их как те, что не нужно запускать в тестовой конфигурации), проходим их руками, создаём таски в джире на апдейт вот этих тестов в следующем спринте и занимаемся этим, пока девы пилят нам новые фичи.
Насчёт не создавать mess при росте тестов:
Никакого зоопарка! Подход типа “вот тут пара тестов на рекордере, вот тут мы сами на selenium’е накатали, а вот тут ещё что-нить прикрутили” - ведёт к тому, что всё это пойдёт на свалку, поскольку не использует общий фреймворк и все апдейты, не относящиеся к самому тесту (ну, например, мы систему логирования решили поменять) придётся делать N раз, притом код не факт, что можно переиспользовать;
Никакого BDD типа cucumber’а без крайне важной причины (например, заказчик или ещё кто-нить не из QA команды пишет тесты и не обладает технической экспертизой для этого). Вот эти степы - они не индексируются IDE, поэтому с ростом их кол-ва неизбежно начнутся проблемы с поиском степа, как идеально стандартизированно ты его не называй и неизбежно начнутся дубликаты, когда 2 степа с разными названиями делают 1 и то же. А где 2, там и 3. Где 3, там и 10. В результате придём к свалке степов, в которых невозможно будет разобраться, после чего всегда будет проще написать 1 more step, чем искать в этой свалке существующий;
Тесты должны быть тегированы по фиче как минимум и по типу (smoke, regression, …). Это позволит быстро запускать избранные наборы тестов, не дожидаясь overnight run. Туда же: оч рекомендую юзать интеграцию с TCMS (TestRail / Zephyr / …), где использовать test to requirements traceablilty (то есть, линковать тесты к стори / эпику и вообще по 10-кам разных критериев, на свой вкус).
Ну вот в целом и всё, наверное, насчёт общих рекомендаций. Если будут конкретные вопросы - смогу сказать точнее.
Если что-то идет не по плану, значит плохой план) Ну а если серьезно, очень часто что-то идет не по плану и надо это принять и закладываться на это. Ты не можешь учесть вообще всего и вся и как @Defender выще логи наше все, ну или почти все. Так что обвешивайся вначале логами по максимум, чтобы потом не ломать голову, где же не работает.
testomat.io управление авто тестами
