Як зрозуміти, що пора автоматизувати тестування

1. Як ми зрозуміли, що потрібно автоматизувати
2. План дій по автоматизації
3. що автоматизувати
4. повна автоматизація
5. чим автоматизувати
6. Разом

Як зрозуміти, що автоматизація тестування принесе користь?
Як зрозуміти, що автоматизувати, а що ні?
Як безболісно для проекту почати автоматизацію?

Якщо ви хоч раз замислювалися над цими питаннями, наша стаття допоможе в них розібратися.

цілі автоматизації

Коли впровадження автоматизації принесе користь:

Якщо хоча б 1 ознака відноситься до вашого проекту, автоматизація принесе поліпшення: тестові дані будуть генеруватися автоматично, часті регреси не забиратимуть час, а проміжок між виявленням дефекту і його виправленням скоротиться.
Якщо поки ваш проект не такий, почекайте, поки розростеться функціонал або команда. Не варто робити Автотест заради Автотест.

Як ми зрозуміли, що потрібно автоматизувати

Ми розробляємо програму для обліку шукачів та співробітників для HR: пошук, прийом на роботу, завдання на випробувальний період, відпустки, поточні завдання та проекти і т.д.

Передумови для автоматизації:
Продукту 3 роки;
У команді 5 розробників;
Релізи зазвичай раз в 3 тижні;
Багато генерації тестових даних
Разом: 4 ознаки з 5. До автоматизації на перевірку всіх тест-кейсів йшло 4 дня.

Рішення
Ми вирішили частково автоматизувати систему, але покрити Автотест не всі 900 тест-кейсів, а тільки зачіпають функціонал, який не змінюється в кожному спринті: авторизація, відновлення пароля, дії з користувачами, нотифікації, створення подій. В результаті написали smoke-Автотест для всіх модулів, які прогоняются в безперервної інтеграції (CI) при кожній збірці. Ми могли б витратити більше часу і автоматизувати інші кейси, але це було б недоцільно: проект розвивається, бізнес-логіка і інтерфейс змінюються занадто часто, щоб писати Автотест. Їх довелося б переписувати в кожному спринті.

результат

В результаті smoke-Автотест запускаються в CI при кожній збірці і сигналізують розробникам про дефекти в реальному часі. Так розробники відразу починають виправляти їх, не перемикаючись на інші завдання, а у QA з'явилося більше часу на ретельне тестування тільки що реалізованого функціоналу замість повторних роботи старого.

Протилежна ситуація склалася на іншому проекті - додатку для створення оцінок і аналітики.

передумови автоматизації
Автоматизувати вирішили в якості експерименту. Це молодий проект, в ньому поки не так багато функціоналу - всього 61 тест-кейс.

Рішення
Проект примітний тим, що на ньому немає жодного ручного тестувальника. Дослідницьке ручне тестування робить Автоматор на етапі написання і налагодження скрипта автотеста, який потім просто проганяється в CI, замінюючи тим самим ручна праця.

результат

На липень 2017 року автоматизовано 46 тест-кейсів на бекенда і 14 на фронтенд, покриття кейсів Автотест близько 96%.
Цей проект - наочний приклад того, що буде, якщо почати автоматизувати з самого старту робіт: часові витрати на тестування за весь час життя проекту менше, ніж якби спочатку ми тестували вручну, а потім запровадили автоматизацію.

План дій по автоматизації

Отже, ви переконалися, що автоматизація тестування принесе користь. Що далі? Розробляємо план дій:

• що автоматизувати;
• як автоматизувати;
• ніж автоматизувати.

що автоматизувати

1. Важкодоступні місця в системі: бекенд процеси, логирование файлів, запис в бази даних;
2. Часто використовуваний функціонал, де високі ризики помилок: системи оплати, реєстрації і т.д. Автоматизація перевірки критичної функціональності гарантує швидке знаходження помилок - 1 тест в середньому йде 2 хвилини. Швидше знайдемо - швидше виправимо;
3. Рутинні операції: перебори даних, форми з великою кількістю введених полів. Автоматизувати заповнення полів даними і їх перевірку після збереження;
4. Валідаційні повідомлення: автоматизувати заповнення полів некоректними даними та перевірку на появу валідації;
5. Довгі end-to-end сценарії. Наприклад, сценарій для ріелторської CRM: реєстрація користувача - заклад заявки від його імені - створення завдання - взяття в роботу - призначення завдань на фахівців - отримання завдань назад в роботу-реєстрація результату;
6. Перевірку даних, що вимагають точних математичних розрахунків: бухгалтерське або аналітичне ПО;
7. Перевірку правильності пошуку даних.

як автоматизувати

Не всі тест-кейси потрібно автоматизувати в першу чергу. Наприклад, якщо у вас 300 тест-кейсів для перевірки модулів, 100 для компонентів, 20 для підсистем і всього 5 призначених для користувача сценаріїв (див. Рис.2), починати автоматизацію краще з тестів, які перевіряють окремі функції, тобто з unit-тестів. Вони виконуються швидко, але їх більше. Коли ці кейси вже покриті Автотест, можна приступати до автоматизації тест-кейсів з перевірки компонентів, далі - підсистем і т.д.

повна автоматизація

Передумови для автоматизації
Приклад повної автоматизації - надбудова над Jira для планування і управління проектами. На проекті порядку 600 тест-кейсів, все покриті Автотест. У разі змін логіки або інтерфейсу, доводиться правити близько 100 скриптів. Це все одно займає менше часу, ніж ручне тестування.

Рішення
На етапі планування автоматизації для визначення кількості автоматизованих тест-кейсів для кожного рівня архітектури ми взяли пропорції з піраміди тестування (рис.). В результаті у нас вийшло більше 300 unit-тестів, 200+ на інтеграцію і API і 38 GUI-тестів, які повторюють сценарії використання продукту кінцевим користувачем.

результат

Вийшло найбільше низькорівневих тестів, здатних відловити баги в окремих функціях і модулях. Вони виконуються швидше високорівневих UI-тестів для користувача сценаріїв. Таке співвідношення оптимально за часом виконання Автотест і величини покриття - інформація про виявлені баги приходить досить швидко, прогін Автотест не займає багато часу і відсоток покриття коду досить великий (можна бути впевненими, що тести виявлять всі критичні і значущі дефекти).

Звідси запитання: навіщо нам така різноманітність складних і довгих тестів з одними сценаріями, якщо можна написати багато невеликих, швидких і легких в підтримці unit-тестів?

Unit-тести тестують код і дають розробнику впевненість, що окремий шматок його коду працює, як задумано, і не ламає логіку роботи коду його колеги. UI-тести тестують систему цілком таким чином, як користувач буде її використовувати. Створення таких тестів займає від кількох днів до кількох тижнів, однак, їх важливо мати на проекті. Вони імітують сценарії використання вашого продукту реальними людьми - від них залежить враження про ваш продукт в цілому.

Загальна рекомендація тут одна: мати всі види Автотест в пропорціях згідно піраміді на кожному з рівнів архітектури системи. Тоді з'являється можливість отримувати ефективну віддачу від таких тестів. Функціональні тести, які тестувальники проводили протягом спринту: негативні, позитивні, комбінаторні і т.п., потрібно поміщати на рівень API-тестів. Так створюється швидкий і стабільний пакет регресійних тестів.
На рівень UI-тестів виносяться приймальні випробування або призначені для користувача сценарії веб та мобільних додатків.
Слідуючи рекомендаціям піраміди, ми отримуємо гарантовано перевірений функціонал і при цьому економимо час команди. Порівняйте: регулярні витрати на багатоденне регресійне тестування 3-4 фахівцями з ручного тестування і 2-3 тижні розробки Автотест одним фахівцем і пара годин на їх підтримку.

чим автоматизувати

Вибір інструмента залежить від специфіки програми та вимог до тестових сценаріїв. Найчастіше вибирається кілька інструментів - окремо для кожного рівня архітектури системи. Наприклад, GUI тестується за допомогою Selenium, API з java + restAssured, а навантаження з jMeter.

На що звернути увагу при виборі

1. Ми не розглядаємо бета-версії і нестабільні збірки інструментів. Це економить час на вирішення проблем, пов'язаних з дефектами самого інструменту. Наприклад, проблеми з кодуванням в RF HTTPLibrary ;
2. Бажано, щоб документація інструменту була російською мовою (як, наприклад, для Selenium );
3. Спеціалізовані форуми по конкретному інструменту допомагають швидше отримати відповіді на питання використання. Наприклад, якщо використовуєте зв'язку java TestNG + Selenium , В інтернеті можна знайти відповідь будь-яке питання. А ось якщо візьметеся за Python based Robot Framework - документація буде тільки англійською і без опису особливостей використання кейвордов, в пошуках яких доводиться аналізувати код бібліотек;
4. Звертаємо увагу на можливість інтеграції інструментів тестування з програмним забезпеченням, яке використовується в компанії;
5. Вартість інструментів тестування: якщо плануєте одноразове тестування, купувати дорогі інструменти недоцільно.

Що для чого підходить
Для автоматизації функціонального тестування важливі підтримка конкретної мови програмування, можливість побудови звітів про тестування для автоматичної реєстрації виявлених дефектів при регулярному прогоні тестів в CI.

Інструментам навантажувального тестування потрібні підтримка протоколу, який використовується додатком, вбудовані засоби моніторингу параметрів серверів під час проходження тесту, гнучка налаштування і запис сценаріїв навантажувального тестування, кошти аналізу результатів і побудови звітів про тестування.

приклади:
jMeter , Яндекс.Танк , Siege , HP LoadRunner .

Ми вважаємо за краще працювати з популярними і надійними засобами тестування: Selenium Webdriver, Java TestNG, jUnit, RestAssured, Allure, jMeter, хоча у нас є досвід використання та інших інструментів (наприклад, Robot Framework).
Практично кожне завдання в межах одного виду тестування можна вирішити за допомогою будь-якого інструменту, проте трудомісткість і вартість рішення будуть відрізнятися. Наприклад, якщо у інструменту немає коштів аналізу результатів і побудови звітів (як у випадку використання, припустимо, testNg + Selenium без Allure), то час на аналіз результатів автоматизованого тестування буде приблизно таким же, як при ручному тестуванні. Вигоди ніякої. Впровадження автоматизації тестування пройде легко і швидко, тільки якщо на самому початку правильно підібрати інструмент під змогу оцінити потреби. Одне лише це вже може стати ключем до успіху.

Разом

Чи не на всіх проектах дійсно потрібна повноцінна автоматизація. Іноді, щоб прискорити роботу команди, досить допоміжних скриптів.

Якщо ви планує розвивати продукт роками великою командою, без автоматизації не обійтися. У нашій практиці були випадки, коли ми впроваджували автоматизацію після 3-4 років роботи над продуктом. І результат був видний і команді, і кінцевим користувачам. У таких випадках автоматизація починається поступово, поки команда звикає до нових інструментів і процесу роботи. Зверніть увагу на інструменти - важливо вибрати ті, які підходять до вже застосовуваних інструментів і бібліотекам.

Автоматизоване тестування покликане допомогти команді робити ті ж завдання швидше і оперативніше випускати нові релізи продукту. Якщо зазвичай на тестування йде 3-4 дні, з автоматизацією цей час скоротитися до декількох годин. Це особливо актуально для великих і постійно розвиваються IT-продуктів.