Как впервые столкнулась с автоматизацией Работала над проектом с кучей механик и огромным регрессом. При этом ещё и с обновлением контента раз в неделю. Решили это дело автоматизировать. Но был нюанс, самописный движок. И подходящих фреймворков для автотестов на рынке тогда не оказалось. Взяли лида автоматизации, чтобы она написала требования к этому фреймворку, а заодно подготовила базу для этого. Помимо фреймворка, проблема была и с тестовой документацией. Там были большие сессионные чек-листы, не привязанные к контенту. То есть было неважно на каком объекте проверять механику, если он походил по типу. Пока разработка пилила фреймворк, лид автоматизации писала кейсы для автоматизации. Далее начались писаться и автотесты, но их было мало. Всё это время, разумеется, регресс продолжали гонять вручную. Через какое-то время пришли к странному сценарию. Команда автотестов выросла, масса автотестов тоже. Но с ручного тестирования нагрузка не снималась. При этом со стороны ручников доверия к автотестам не было. А сама команда автотестирования была оторвана от релизного цикла. Через какое-то время появился Head of QA. Который посчитал ROI и команду автоматизации сократили. Процесс был достаточно эмоциональным. Часть команды оставили. Хотели переделывать фреймворк, но у них в итоге тоже ничего не получилось. Хотелось бы сказать, что исправление одной вещи изменило бы итог этой истории. Но проблем там было много. Главные бы выделила две. Первая, оторванность двух команд тестирования друг от друга. Инструменты разные, но цель одна. Второе, это изначальное планирование. Задача звучала, как нам нужна автоматизация. Она появилась. Но это по сути никак не повлияло на процесс релизов, кроме как тратой ресурсов. Самое забавное — несколько лет на это никто особо не обращал внимания. Релизы надо было выпускать, а не вот это вот всё.🦄