Как часто, работая в команде, вы сталкиваетесь с ситуацией, когда часть задач по автоматизации тестирования попадает в бэклог и остается в ручном тестировании навсегда? Мы постоянно сталкиваемся с такой проблемой, и причины всегда разные:
Вдохновившись идеей коллег из Avito, в середине мая мы с Yaromudr провели первый Automation Day, цель данного мероприятия — автоматизировать тестирование там, где по вышеуказанным причинам мы еще не сделали этого.
На нём мы собрали всех заинтересованных QA-инженеров, а также заранее подготовили:
Для автоматизации был выбран слой интеграционных тестов на API. Каждая задача в бэклоге содержала:
На старте проекта для автоматизации нами был выбран следующий стэк, именно на нем мы подготовили шаблон проекта, который будем наполнять автотестами:
Примерный шаблон проекта можно посмотреть здесь.
Нужно заметить, что предварительно мы на протяжении длительного времени подготавливали инструмент для автогенерации тестовых данных, без этого делать новый фреймворк совсем не хотелось, поскольку уже был неудачный опыт интеграционных автотестов на статичных тестовых данных, только слоем ниже. Об этой проблеме мы частично рассказывали на нашем митапе QAчественное общение.
Правила для участников Automation Day были максимально простыми. Перед стартом разработки мы продемонстрировали заранее разработанную структуру проекта и провели краткий брифинг. При разработке участникам было необходимо придерживаться заданной структуры проекта.
С 10 до 19, периодически отвлекаясь на обед и ужин, участники пишут тесты на Java + JUnit5. Реализацию логики для тестов на Java организовали в виде вызовов API с использованием библиотеки Unirest.
И вот в нашей уютной игровой собралось двенадцать QA-инженеров и два организатора мероприятия Automation Day.
Стоит сказать, что уровень QA-инженеров был разный, кто-то знал весь стэк, кто-то никогда не применял в своих проектах Spring, кто-то использовал в своих проектах только Rest-assured и никогда не видел Unirest, некоторые еще не автоматизировали тестирование API и тестировали их руками.
Что мы получили за 8 рабочих часов усиленной разработки:
Когда мы сняли метрики по тестам примерно через месяц, получили очень интересные показатели:
Особенно хочется отметить положительное влияние подобных мероприятий на коммуникации внутри команды QA, когда люди сталкиваются с реальными продуктовыми задачами и рядом есть те, кто может помочь и научить, это всегда дает положительный эффект. Простой пример, один из участников ilya_tad предложил использовать Retrofit вместо Unirest, по ряду причин он действительно оказался для нас более удобным инструментом. Совсем недавно этот же участник провел второй Automation Day, на котором все также писали тесты, но уже с использованием Retrofit. К слову, на втором Automation Day мы полностью заменили Unirest на Retrofit, для нас доработки оказались минимальными. Примерный шаблон переработанного проекта можно посмотреть здесь.
Все участники Automation Day получили свеженапечатанные футболки с супергероями. И да, конечно, мы собрали отзывы участников после проведения первого Automation Day. Ответ на вопрос “Что в этом Automation Day было самым ценным и полезным?”:
Мы также собирали пожелания от участников, все перечислять не будем, но самое популярное было — проводить Automation Day на регулярной основе.
Очевидно, мы будем стараться проводить подобные мероприятия на регулярной основе. Будем делать разную тематику, пробовать новые инструменты.
Automation Day позволяет обучать людей на реальных продуктовых задачах, люди начинают делиться опытом, проявлять инициативу, лучше коммуницировать друг с другом. При правильной подготовке и организации данное мероприятие позволяет относительно быстро сформировать целый слой автотестов и подготовить людей для дальнейшего развития этого слоя.
Третий Automation Day планируем посвятить написанию компонентных тестов под iOS с применением инструмента EarlGrey.
- не успели / не хватило времени, а потом забыли;
- недостаточно опыта;
- задача по автоматизации оказалась очень большой, требующей сторонних интеграций.
Вдохновившись идеей коллег из Avito, в середине мая мы с Yaromudr провели первый Automation Day, цель данного мероприятия — автоматизировать тестирование там, где по вышеуказанным причинам мы еще не сделали этого.
На нём мы собрали всех заинтересованных QA-инженеров, а также заранее подготовили:
- бэклог задач;
- правила проведения;
- договорились о стэке технологий;
- подготовили инструментарий;
- заказали нужные доступы.
Для автоматизации был выбран слой интеграционных тестов на API. Каждая задача в бэклоге содержала:
- ссылку на endpoint, а также входные и выходные параметры rest-запроса в формате json;
- суть проверки, как и для чего мы это проверяем.
На старте проекта для автоматизации нами был выбран следующий стэк, именно на нем мы подготовили шаблон проекта, который будем наполнять автотестами:
- Java8
- JUnit5
- Spring
- Unirest
Примерный шаблон проекта можно посмотреть здесь.
Нужно заметить, что предварительно мы на протяжении длительного времени подготавливали инструмент для автогенерации тестовых данных, без этого делать новый фреймворк совсем не хотелось, поскольку уже был неудачный опыт интеграционных автотестов на статичных тестовых данных, только слоем ниже. Об этой проблеме мы частично рассказывали на нашем митапе QAчественное общение.
Правила
Правила для участников Automation Day были максимально простыми. Перед стартом разработки мы продемонстрировали заранее разработанную структуру проекта и провели краткий брифинг. При разработке участникам было необходимо придерживаться заданной структуры проекта.
С 10 до 19, периодически отвлекаясь на обед и ужин, участники пишут тесты на Java + JUnit5. Реализацию логики для тестов на Java организовали в виде вызовов API с использованием библиотеки Unirest.
И вот в нашей уютной игровой собралось двенадцать QA-инженеров и два организатора мероприятия Automation Day.
Стоит сказать, что уровень QA-инженеров был разный, кто-то знал весь стэк, кто-то никогда не применял в своих проектах Spring, кто-то использовал в своих проектах только Rest-assured и никогда не видел Unirest, некоторые еще не автоматизировали тестирование API и тестировали их руками.
Результаты
Что мы получили за 8 рабочих часов усиленной разработки:
- + 12 pull requests;
- 12 закрытых задач из бэклога;
- + 14 интеграционных автотестов;
- > 99% успешно пройденных автотестов на каждый запуск;
- 12 QA-инженеров, которые отлично ориентируются в проекте.
Спустя один месяц
Когда мы сняли метрики по тестам примерно через месяц, получили очень интересные показатели:
- + 30 pull requests;
- 30 закрытых задач из бэклога;
- + 48 интеграционных автотестов;
- заменили Unirest на Retrofit;
- > 97% успешно пройденных автотестов на каждый запуск.
Особенно хочется отметить положительное влияние подобных мероприятий на коммуникации внутри команды QA, когда люди сталкиваются с реальными продуктовыми задачами и рядом есть те, кто может помочь и научить, это всегда дает положительный эффект. Простой пример, один из участников ilya_tad предложил использовать Retrofit вместо Unirest, по ряду причин он действительно оказался для нас более удобным инструментом. Совсем недавно этот же участник провел второй Automation Day, на котором все также писали тесты, но уже с использованием Retrofit. К слову, на втором Automation Day мы полностью заменили Unirest на Retrofit, для нас доработки оказались минимальными. Примерный шаблон переработанного проекта можно посмотреть здесь.
Отзывы
Все участники Automation Day получили свеженапечатанные футболки с супергероями. И да, конечно, мы собрали отзывы участников после проведения первого Automation Day. Ответ на вопрос “Что в этом Automation Day было самым ценным и полезным?”:
- вовлечение всех участников в покрытие еще одного слоя автотестов из пирамиды тестирования (разгружающих самый верхний слой автотестов end-2-end UI);
- возможность сконцентрироваться на задаче, не отвлекаясь ни на что другое, а также бесценный опыт наставничества;
- коллективная работа над конкретными задачами в течение четко оговоренного промежутка времени, сфокусированность на решении определенного узкого круга задач и проблем;
- появилось общее представление о локальном фреймворке.
Мы также собирали пожелания от участников, все перечислять не будем, но самое популярное было — проводить Automation Day на регулярной основе.
Заключение
Очевидно, мы будем стараться проводить подобные мероприятия на регулярной основе. Будем делать разную тематику, пробовать новые инструменты.
Automation Day позволяет обучать людей на реальных продуктовых задачах, люди начинают делиться опытом, проявлять инициативу, лучше коммуницировать друг с другом. При правильной подготовке и организации данное мероприятие позволяет относительно быстро сформировать целый слой автотестов и подготовить людей для дальнейшего развития этого слоя.
Третий Automation Day планируем посвятить написанию компонентных тестов под iOS с применением инструмента EarlGrey.
