Прежде чем приступить к автоматизации тестирования, желательно проанализировать приложение. Чем больше приложение готово к автоматизации, тем меньше проблем будет в дальнейшем при разработке автотестов и анализе результатов. Одним из ключевых факторов успеха автоматизации является тестируемость приложения. Благодаря тестируемости автотесты пишутся проще и быстрее. Например, для API это публичные методы, а для UI это HTML страница. Бывает так, что автоматизируют слишком рано, и в итоге потом занимаются переписыванием. Как можно раньше задайтесь вопросами, а готовы ли основные страницы для автоматизации, целесообразно ли брать в работу, не поменяется ли логика или вёрстка на следующий день и т.д. Документация помогает быстрее найти нужную информацию, например, для создания тестовых данных через API. Swagger и Storybook позволяют легко документировать API и UI компоненты соответственно. На основе спецификаций можно генерировать тесты. С использованием Storybook можно узнать нужное состояние компонента и его назначение.  Также, на основе документации можно построить покрытие автотестами, как это рассказано на примере инструмента swagger-coverage. Для уменьшения количества падающих тестов, если фронтенд будет меняться, и для удобного нахождения элементов в DOM, необходимы надёжные локаторы.  Менее подвержены изменениям data-* атрибуты, например, data-test="element". Не так давно на конференции Heisenbug в докладе «Как Testid-strategy победила PageObject и BDD/Cucumber монстров» было рассказано о преимуществе подобного подхода в связке с Allure Report. Можно использовать и другие локаторы, если такие существуют. Приоритетность можно посмотреть в Testing Library. В первую очередь рассматриваем приближённые к пользователю локаторы. Сразу бонус тем, кто следит за accessibility продукта.  При прогоне автотестов часто возникает проблема с анимациями, которые мешают проходить кликам и другим действиям. Хорошей практикой является полное отключение подобных анимаций, если это возможно.  С ростом количества автотестов одним из способов уменьшения времени прогона является параллелизация. Параллелить можно разными способами, например, через потоки или параллельные джобы. Надо быть внимательным при запуске в параллель, нужно убедиться, что приложение не падает и не появилось замедлений или неожиданных ошибок. На архитектурных схемах или другой документации можно найти различные third-party зависимости. Контролировать их сложно, поэтому подстроить под тесты проблематично.  Например, для стороннего API в качестве мок-сервера можно использовать Wiremock или MockWebServer. Таким образом автотесты будут стабильнее. Логи — наши помощники при анализе и разборе результатов автотестов после прогона. Разбираться с причинами падений становится проще. У приложения должны быть понятные и доступные логи, в идеале в одном месте и чтобы их можно было прикрепить к конкретному тесту. Некоторые фреймворки позволяют прикреплять логи из разных источников к автотесту. Такими источниками может служить информация из консоли браузера или информация от сервера.  На глобальном уровне обычно выставляется таймаут для всех ожиданий в тестах. Вычислить его можно опытным путём.  Время ответа не должно превышать заданный таймаут, иначе тесты будут постоянно падать и надо постоянно с ними разбираться.  Оптимальным решением здесь будет обсуждение по поводу улучшения перформанса, возможно есть какие-то проблемы и нужно их решить. Опираясь на вышеперечисленные советы можно облегчить автоматизацию тестирования приложения. QA Automation