Процеси та автоматизація проекту з нуля
Є безліч статей про технології та ті чи інші підходи до автоматизації. Але чомусь немає статей про «зворотний бік» автоматизації. Як взагалі все зароджується на проекті? І як це все організувати? Нижче буде розглянуто приклад компанії Укрсільгоспбанк.
Загальна інформація щодо проекту
Великий проект із командами, які розробляють загальний продукт;
У командах є QA Manual (Ручний тестувальник);
Напрями тестування – Frontend, Backend.
Вивчаємо проект
Розуміємо мету розробки продукту і хто споживач : відповіді на ці питання допомагають зрозуміти, на що наголошувати в автоматизації. Наприклад, якщо працюємо з юридичними особами, то наголошуємо на тестуванні «виконання законодавства» та перекази по платежах тощо. Якщо це фізичні особи, то на основні операції, що виконуються: перекази з картки на картку, оплату послуг тощо. Так само важливо, щоб напрямок автоматизації «дивився» в цілому на продукт, а не на окремі команди.
Знайомимося з учасниками розробки продукту : у разі потрібно бути знайомим з усіма, оскільки необхідно буде взаємодіяти тим чи іншим чином. Виділю ключових людей:
Власники продуктів (Product Owners), вони є замовниками автоматизації в команді;
QA кожної команди. Вони – це клієнти інструменту автоматизації, їхній рівень щастя – це показник успіху;
Лідер ручного тестування. Допомагає в організації процесу та у взаємодії з ручним тестуванням;
Лідер розробки Frontend. Він впливає на стабільність та якість автотестів;
Фахівець із закупівлі. Вирішить питання виділення техніки, переважно із серверним залізом.
Вивчаємо кожну команду : збираємо інформацію про те, яку частину проекту розробляє команда.
Розбираємось у напрямку - Frontend, Backend або все відразу;
Розбираємось з тим, як QA тестують свою частину продукту;
З'ясовуємо, на якому рівні QA manual знайомий із автоматизацією;
Знаходимо болі в тестуванні і пріоритетно закрити автоматизацією.
Формуємо вимоги до автоматизації та замовляємо ресурси
Що ми зібрали?
У нас є 8 команд;
Є 11 QA інженерів;
Є напрямки тестування Frontend, Backend+ «ходитимемо» до Бази даних;
90% QA manual ніколи не займалися автоматизацією.
Виходячи з даних, формуємо вимоги до автоматизації
У нас немає завдання робити якісь інноваційні рішення, тому дотримуємось класики:
Як мову програмування вибираємо Java – так буде простіше знайти спеціалістів;
Потрібно випробувати Frontend. Беремо Selenium;
Потрібно тестувати Backend. Взаємодіємо із ним через REST. Беремо REST-assured;
Потрібно «ходити» до бази даних. Візьмемо стандартні бібліотеки з Java;
Потрібно чи навчити QA manual розробці автотестів, чи найняти армію з N автоматизаторів. Ми думаємо про витрати проекту на тестування, тому вбиваємо 2 зайців відразу. Беремо Cucumber;
Нам потрібна звітність із гарними графіками. Беремо Allure.
Вийшов наступний стек технологій: Java, Selenium, REST-assured, Cucumber.
Оцінюємо сили автоматизаторів
Оскільки їх немає, беремо 1 автоматизатора на 5 команд (більше 5 не потягне).
Автотести потрібно десь запускати
Що нам знадобиться?
Машина для Jenkins. 1 штука. Через нього реалізуємо віддалений запуск;
Машина під Slave Jenkins. Як agent для Jenkins;
Машина під Selenoid. Для паралельного запуску тестів.
Робимо демо нашого інструменту
Наше демо будуть дивитися все: власники продуктів, QA інженери, розробники, аналітики та ін. Отже, орієнтуємося на розуміння для всіх.
Беремо команду як першу «жертву» автоматизації. Діти розробляють Frontend. Нам потрібна наочність.
Робимо 5-10 автотестів. Записуємо на відео;
Обов'язково після прогону показуємо Allure. Гарні графіки люблять усі;
Малюємо «інфраструктуру автотестів». Головне, щоб було просто та зрозуміло;
Позначаємо головну мету автоматизації;
Демонструємо ефект від автоматизації;
Робимо порівняльні випробування. Ручне проходження та автоматизоване;
Показуємо, як створюються сценарії;
Показуємо плани автоматизації (коли з'являться той чи інший функціонал);
Показуємо, як відбуватиметься впровадження автоматизації у команди.
Підготовляємо UI до автоматизації
Для забезпечення надійності, стабільності та якості автотестів необхідно розкидати якорі на UI. Централізовано через лідера Frontend та додатково через власників продукту проставляємо атрибут для UI-елементів “data-test-id“ або з будь-якою іншою назвою. Сенс у тому, щоб з боку UI проставити цей атрибут у всіх елементах типу Таблиця, поле для введення, кнопка і т.д. Якщо коротко, то на всіх елементах, із якими взаємодіємо, це дасть +300% до надійності автотестів. Переїзд елемента в інше місце або зміна його вмісту не вплинуть на перевірку автотестом. Робимо цей момент обов'язковим для всіх нових фіч.
Розробляємо автотести
Ділимо команди між автотестерами;
Розробляємо каркас проекту для автоматизації. Все за шаблоном;
Підготовляємо набір Cucumber кроків для роботи із Frontend, основним напрямком у тестуванні. Виносимо кроки в окремий проект і робимо з нього артефакт, що підключається;
Налаштовуємо Selenoid та Jenkins;
Починаємо підключати команди до автоматизації. При підключенні команди все зводиться до того, щоб створити репозиторій, завантажити каркас, створити Job у Jenkins за шаблоном, навчити QA роботі з Cucumber, роботи з Git та середовищем розробки;
Після навчання QA manual самостійно пишуть автотести. Один раз за спринт автоматизатор приходить до команди і приймає написані автотести, робить правки та вливає в основну гілку. На цьому етапі хлопці хитають рівень написання правильних сценаріїв, а ми отримуємо якісні перевірені сценарії;
Після зустрічі з усіма командами у автоматизатора у спринті залишається ще 5-6 вільних днів. Цей час витрачаємо на розробку Cucumber кроків;
Наприкінці спринту на продуктовому демо показуємо результати по командам і робимо анонси нових фіч в інструменті.
Результати
6 спринтів (60 днів), 8 команд, 2 автотестери та 11 ручних тестувальників - маємо 50% покриття регресу проекту автотестами. Це з урахуванням підключення команд (підключалися поступово) та розробки кроків.
Речі, про які слід пам'ятати при розробці з таким підходом
Ручний тестувальник - це клієнт . QA інженер – прямий споживач інструменту автоматизації. Їхній рівень комфорту, щастя та кількість автотестів – це показник якості нашої роботи. Якщо один із показників падає, значить потрібно щось міняти. Інакше все посипається.
Орієнтація на користь проекту . Потрібно завжди пам'ятати, що зміст розробників, тестувальників, аналітиків та інших фахівців коштує грошей. Зрештою, наша мета їх заощадити. Як ми їх заощаджуємо?
Автотестами: знаходимо дефекти, запускаючи їх щодня.
На кожному етапі тестування скорочуємо час регресу.
Все це призводить до більш швидкого випуску продукту у промислову експлуатацію.
Не працює? Міняй! Не треба боятися помилок. Їх буде дуже багато у розробці, у спілкуванні з командами, у взаємодії з QA інженерами, у демо. Головне побачити, що «щось» не працює і змінюватиме підхід доти, доки всі не будуть у захваті. Все робимо для людей. Не для себе.
Джерела:
Дод. матеріал:
Last updated