Необходимо ли компании выделять компетенции автоматизатора и так ли они уникальны? В статье описано, как внутри компании при действующих командах автоматизации происходил пересмотр компетенций, в результате которых возник парадокс «Команда есть, а компетенций нет». Результом пересмотра стало то, что команд автоматизации больше нет. Рассказать опыт и причины принятия тех или иных решений. Стек: С#, SpecFlow(BddFy), Selenium Тестируемый объект: Системы для автостраховых компаний в Америке. У всех систем есть админки для настройки приложений, rest api, чтобы клиенты могли сами писать порталы, приложение для создания полиса и осуществоения платежей, приложение для генерации отчетов. Все части должны быть покрыты тестами. До определенного момента команда автоматизации была обособленной, практически не взаимодействующей с другими командами. Перед ней стояла цель максимально покрыть регрессионный набор автотестами, чтобы уменьшить срок проведения полного регресса QA. Перед регрессом создавался тест ран, который должен был пройден для выпуска версии релиза. Результаты прогона автотестов мапились в этот ран. В системе было примерно 4000 кейсов, которые запускались на разных environment. Время полного прогона больше двух суток. Порядка 15% имели статус broken(сломаны по вине автотеста).  Появилась необходимость в быстрой верификации качества вмерживаемой фиче-ветки в main branch. Отсюда возникли следующие цели: Верхнеуровневно я решил объединить два пункта, поскольку увеличения скорости прогона можно добиться за счет параллелизации, а это открывает ящик пандоры с флаки тестами. Ведь, если у вас есть некий статический контекст по типу HttpContext, который хранит информацию о залогиненном юзере и его claims, то при параллельном запуске этот логин будет выполняться для всех запущенных тестов. Что, при определенных условиях, приводит к падениям, которые локально будет довольно сложно воспроизвести. Теперь остановимся на каждом из пунктов поподробней. Для увеличения скорости прогонов тестов были реализованы следующие подцели: В рамках параллельного исполнения тестов были реализованы следующие мероприятия: В рамках написания эмулятора: От себя бы хотелось добавить, что эмулятор писать имеет смысл, если в Controller/ View тестируемого объекта не содержится логики и у приложения есть DI контейнер. В противном случае перед тем, как писать эмулятор, лучше всю логику вынести в сервисы/хэндлеры. Эмулятор позволяет без поднятия браузера или обращения по Rest выполнить нужные действия. Тут я не устану повторять: «данные действия не являются тестируемыми, они лишь приводят систему в тестируемое состояние». Если по сравнению с рест или шиной выигрыш по времени не такой большой, то если сравнивать с UI — выигрыш очень существенный. Вынос повторяемых степов в эмулятор позволил сократить время прогона теста до 5 раз. В рамках стабилизации прогона были проведено следующее: Большую часть времени я был уверен, что нестабильные тесты – вина разработчика (автоматизатора), который их написал. Время показало, что исправить все тесты не получается. Нам удалось исправить 99.9 % тестов, но время, потраченное на увеличение порядка стабильных тестов, увеличивалось экспоненциально. И в один момент мы поняли, что 3 падающих теста на 4000 уже не так критично и их можно пройти руками. Да, так не выйдет сделать полностью автоматическую доставку релиза до staging, но пока это не требуется. На самом деле тут цель сделать тесты расширяемыми: требования к автотестам увеличиваются с течением времени и хочется сделать так, чтобы эти требования можно было удовлетворить минимальными изменениями в коде. И желательно даже сделать так, чтобы это было лишь расширение функционала, а не его изменение. Мутации сценариев – лишь один из возможных сценариев расширения функционала.
Я бы выделил несколько пунктов: Для наглядности приведу пример:
Реализация степ биндинга выглядит следующим образом:  Медиатор находит подходящий UserActivityHander и вызывает у него Handle:  Но, поскольку Command Dispatcher расширяемый, следовательно можно: Все это позволяет быть уверенным, что если появятся новые требования (например, формирование популяций для мутаций) систему не придется переписывать, а просто появится новое поведение.  После того, как руководители отделов составили матрицы компетенций, выяснилось что компетенции, которые требовались автоматизаторам, большей частью повторялись с компетенциями разработчиков(CLR, принципы разработки ПО, паттерны, средства мониторинга, DI), а те, что не повторялись(Selenium, Selenoid, Specflow), при условии, что человек умеет читать документацию, становятся некритически важными.  Очевидно, что одними изменениями в автотестах всех целей не добиться. Необходимо менять процессы внутри компании. Мы выделили следующие правила: Если данные правила не выполнены, то команда автоматизации будет постоянно находиться в условиях гонки и у команд разработки не будет доверия автотестам. Описанные подходы внедрены в нескольких проектах компании и успешно функционируют от полугода. Возможно прошедшего времени недостаточно, чтобы делать выводы, но в настоящее время предпосылок менять подход нет.