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

Однако независимо от этих аргументов конечный итог таков: проект разваливается и перестаёт существовать, и тогда тесты уже не нужны, или начинается гонка в попытках наверстать упущенное, покрыть автоматизацией всё непокрытое, но уже с репутационными потерями для продукта.

Репутационные потери, в свою очередь, можно разделить на две большие группы: ⁃ Много багов, из-за которых продукт теряет свою привлекательность. ⁃ Очень долгий процесс доставки из-за ручного тестирования и исправления багов на поздних стадиях разработки. Из-за длительного цикла выпуска продукт перестаёт быть конкурентным, не успевает за рынком. В попытках наверстать упущенное начинают разрабатывать end-to-end-тесты, переворачивая пирамиду тестирования и делая проект ещё более сложным и нестабильным. Теперь к нестабильному продукту добавляются нестабильные тесты. Всё это, как огромный снежный ком, продолжает нарастать, укрепляя уверенность людей в бесполезности тестирования.

Чтобы этого избежать и обеспечить высокий уровень качества продукта, нужно соблюдать несколько основных правил: ⁃ Юнит-тесты должны быть обязательным требованием при разработке. Это должно стать частью культуры продукта. ⁃ Юнит-тестов должно быть очень много, и это нормально. ⁃ Как только API (если архитектура продукта предполагает его наличие) становится общедоступным и выводится в эксплуатацию, должны быть написаны тесты для его проверки. Не должно быть никаких аргументов наподобие: «Мы не знаем, мы не уверены, всё будет переделываться» и тому подобного. Если сервисы, предоставляющие API на проде, и пользователи уже используют их, то таких аргументов быть не может. В противном случае напрашивается вопрос: а зачем эти сервисы создавались — работа ради работы? Не забываем про тесты безопасности, которые очень хорошо интегрируются в API-тесты. ⁃ Как только получаем стабильный пользовательский интерфейс (web, mobile), начинаем писать под него UI-тесты. Таких тестов не должно быть много, они должны проверять базовые с точки зрения UI вещи. Вся логика проверяется на описанных выше уровнях тестов. Вообще, если проект не однодневка, то я бы рекомендовал заранее поднять проект автотестов UI. Именно проект, не сами тесты. Однако это требует некоторых усилий по проектированию правильной архитектуры проекта. ⁃ Хотя бы немножко, но думать о нагрузке. Тема нагрузочного тестирования достаточно обширна, и, по-хорошему, нужны специалисты, которые могут правильно настроить окружение, вывести нагрузочный профиль, переходный коэффициент (в случае, если тестовая среда не соответствует производственной), и так далее. Но если таких специалистов или команд нет, то я бы рекомендовал делать простенькие тесты с помощью того же JMeter.

Чтобы следовать этим правилам, необязательно (хотя и желательно) иметь QA automation. Их роль могут выполнять разработчики, но в долгосрочной перспективе этот вариант, увы, не рабочий, и нанять специалиста или специалистов всё равно придётся.