Стратегія автоматизації тестування для Agile-проектів
Що пишуть у блогах
Баги та діри
• Наочні ілюстрації до можливих сценаріїв із програмним кодом.
Простий масив
Онлайн-тренінги
Очні тренінги
Конференції
Що пишуть у блогах (EN)
Розділи порталу
Про інструменти
Найкращі вакансії
Використання автоматизованого тестування надає величезні можливості та дозволяє суттєво підвищити надійність коду та безпеку програми. Тому розробка великих та складних систем неодмінно вимагають залучення фахівців у галузі автоматизованого тестування. З іншого боку, автоматизоване тестування – процес досить складний як з погляду написання коду, так і з погляду методології та організації процесів у команді. Пропонуємо до вашої уваги переклад статті про побудову автоматизованого тестування на Agile-проектах.
Описана у цій статті стратегія автоматизації тестування передбачає модель постійного постачання з кількома командами, які працюють за методологією Agile.
На цьому прикладі я перелічу ключові моменти, які необхідно враховувати, щоб отримати максимальний ефект від автоматизованих тестів.
Автоматизоване тестування – ключовий процес розробки з використанням методології Agile. При переході до постійного розгортання автоматизація тестування стає ще більш важливою через можливість швидко інформувати розробників про стан програми. Щоб забезпечити постійний потік зворотного зв'язку, автоматичні тести необхідно проводити постійно.швидко, а їх результати мають бути надійними та достовірними.
Щоб забезпечити виконання цих умов, більша частина перевірок має проводитись у рамках розробки нових функціональних можливостей. Інакше кажучи, розробка і тестування мають бути нерозривно пов'язані, а забезпечення якості має бути закладено від початку розробки, щоб нові можливості не порушували роботу існуючого функціоналу.
Це вимагає "інвертування піраміди автоматизації тестування" з відмовою від GUI-тестів, які займають багато часу, на користь тестування на нижчих рівнях, наприклад, API, де автоматичні тести можна запустити відразу після unit-тестів як частину збирання, щоб забезпечити базовий рівень надійності.
Огляд стратегії автоматизації тестування
Запобігання замість виявлення — зрозуміло, необхідно докласти всіх зусиль, щоб запобігти виникненню недоліків, але техніки та методи, які для цього використовуються, не є предметом цієї статті. Тут нас цікавить, як можна виявити баги, як тільки вони з'являються у системі, та оперативно передати інформацію розробникам.
Якість має бути перевищує кількість. У переважній більшості випадків краще випустити в реліз одну фічу, надійну, як скеля, ніж відразу кілька напівсирих можливостей. Мінімальним критерієм для релізу має бути повна відсутність регресійних дефектів, тобто нові можливості не повинні порушувати роботу функціоналу.
Як вже згадувалося, швидке інформування розробників про стан програми має велике значення при безперервному постачанні, отже, треба знайти механізм, який дозволить швидко давати зворотний зв'язок. Один із способів – збільшити кількість unit-тестів,інтеграційних тестів та тестів API. Ці низькорівневі тести формують мережу безпеки, яка допомагає переконатися, що програма працює так, як було задумано, і дозволяє запобігти дефектам, що виникають на інших рівнях тестування. Unit-тести є основою для автоматизації тестування на вищих рівнях.
Друга можливість для покращення роботи - запускати регресійні тести частіше і в паралелі з безперервним постачанням, про це пізніше.Автоматизоване тестування має бути не ізольованим завданням, а безперервним процесом, невід'ємно вписаним у життєвий цикл ПЗ.
Регресійне тестування
Автоматичні регресійні тести – основа стратегії автоматизації тестування.
«Димовий» пакет регресійних тестівпотрібен для перевірки того, що програма завантажується та запускається. До нього також входять кілька ключових сценаріїв, які дозволяють переконатися, що програма ще працює.
Мета цього пакету тестів в тому, щоб відловити найбільш очевидні проблеми, наприклад, те, що програма не завантажується або не запускається основний потік взаємодії користувача з програмою. Тому «димові» тести не повинні тривати більше5 хвилин, їхня мета — повідомити, що не працює щось ключове.
Такі тести запускаються при кожному розгортанні програми і можуть містити як API, так і тести GUI.
Функціональний пакет регресійних тестівпотрібен для більш детальної перевірки роботи програми, ніж це дозволяють димові тести.
Необхідно створити кілька функціональних пакетів для різних цілей. Якщо є кілька команд, що працюють над різними розділами програми, то ідеалі потрібні регресійні пакети, що покривають область роботи кожної команди.
Ціпакети повинні запускатися у різних оточеннях у міру необхідності та перевіряти, що поведінка програми залишається незмінною незалежно від оточення. Такі тести запускаються кілька разів на день і повинні продовжуватись не довше 15-30 хвилин.
Оскільки ці тести більш деталізовані та займають більше часу, важливо виносити більшу частину функціональних тестів на рівень API, де тестування відбувається швидше. Це потрібно для того, щоб не виходити за тимчасові рамки в15-30 хвилин.
Повний пакет регресійних тестівдозволяє протестувати програму як ціле. Мета цього пакету тестів — перевірити, що різні частини програми, які звертаються до різних баз даних та інших програм, працюють коректно.
Цей пакет тестів не призначений для перевірки всіх можливостей програми, оскільки їхня робота вже перевірена функціональними регресійними пакетами. У будь-якому випадку, ці тести більш «легкі» і перевіряють переходи з одного стану до іншого або кілька найбільш популярних сценаріїв або шляхів користувача.
Такі тести переважно проводяться з використанням GUI, оскільки вони перевіряють, як користувач буде взаємодіяти з системою. Час, який на них витрачається, може змінюватись в залежності від програми, але зазвичай такі тести запускаються один раз на день або за ніч.
Стратегія автоматизації тестування для кількох Agile-команд
Автоматизовані unit-тести
Автоматизація тестування починається лише на рівні unit-тестів. Ці тести повинні створюватися для кожної нової можливості, що у розробці. Саме вони лягають в основу ширшої практики автоматизації до системних GUI-тестів. Розробники зобов'язані переконатися у тому, що з кожноїнової функціональної можливості розроблено повний набір надійних unit-тестів, що дозволяють перевірити, що код працює як задумано та відповідає всім вимогам. Unit-тести найбільш вигідні з погляду окупності, оскільки їх недовго написати, легко підтримувати і змінювати (завдяки тому, що немає залежностей), тому якщо код має помилку, то розробник швидко дізнається про неї. Unit-тести мають запускатися як у комп'ютері розробника, і у середовищі безперервної інтеграції.
Автоматична інтеграція / API-тести або сервіс-тести
У той час, як unit-тести засновані на тестуванні функцій усередині класу, інтеграційні тести формують наступний ступінь, спрямований на тестування класів, що утворюють компонент, що входить до складу нового функціоналу. Такі тести запускаються лише після того, як unit-тестування було успішно завершено.
Сервіс-тести зазвичай запускаються на рівні API без залучення GUI-інтерфейсу, отже, тести спрямовані на перевірку функціональності в чистому вигляді, а оскільки тести безпосередньо звертаються до компонентів вони швидко проводяться і можуть бути частиною складання. При необхідності тестування взаємодії із зовнішніми сервісами, якщо зовнішні сервіси не доступні або не можуть гарантувати надання даних, що відповідають умовам тестування, можна використовувати емулятори зовнішніх сервісів, наприклад WireMock. API-тести та/або сервіс-тести можуть запускатися на комп'ютері розробника або бути частиною складання, але якщо вони починають займати тривалий час, краще запускати їх у безперервній інтеграції. Для сервіс-тестів можна використовувати такі інструменти як SoapUI.
Тести програми
На практиці велика програма, наприклад, система для електронної комерції, може бути розбитана кілька програм, що надають різні можливості. Концепція «тестування додатків» у тому, що групи тестів, створені задля можливості одного додатка, об'єднуються і проганяються цього додатка. Цей пакет можна використовувати у випадках, коли команда планує випустити індивідуальну програму і хоче перевірити, чи все працює коректно.
Щоб протестувати додаток загалом, зазвичай потрібен інтерфейс взаємодії між різними його компонентами, отже, тестування краще проводити з допомогою браузера чи GUI. Ціль цих тестів — переконатися в тому, що програма працює коректно. Такі випробування називають «вертикальними», т.к. вони спрямовані на перевірку працездатності конкретної програми або компонента, а не всієї системи цілком. Ці тести відрізняються глибиною опрацювання та великим обсягом.
Для таких тестів у браузері можна використовувати Selenium WebDriver. Цей інструмент є найбільш популярним для автоматизованого тестування в браузерах і надає багаті можливості API для проведення складних перевірок.
Повні сценарні тести
Автоматизовані GUI-тести, які запускаються для всієї системи, використовуються як типові шляхи користувачів або сповнені сценарії взаємодії. Через проблеми з цим типом тестів (описаних нижче) їхню кількість краще скоротити до мінімуму. Повні сценарії включені до нічних регресійних пакетів.
Інвертування піраміди автоматизації тестування
У рамках стратегії автоматизації тестування необхідно мінімізувати кількість автоматизованих тестів на рівні GUI.
Незважаючи на те, що проведення автоматизованого GUI-тестування дає гарні та значущі результати з поглядусимуляції взаємодії користувача з додатком, воно має і ряд своїх недоліків:
- Крихкість —для визначення веб-елементів для взаємодії тести використовують html-локатори, тому щойно змінюється унікальний ID будь-якого елемента інтерфейсу, тести перестають працювати, а це спричиняє значні витрати на підтримку.
- Обмежене тестування —GUI може не дозволити тестувальнику повністю перевірити функціональність, оскільки він не завжди містить усі деталі веб-відповіді, необхідні для верифікації.
- Низька швидкість -оскільки тести проводяться через GUI, час завантаження сторінки істотно збільшує загальний час тестування, і зворотний зв'язок розробникам надходить значно пізніше.
- Найменша окупність —через всі проблеми, перераховані вище, GUI-тести стають найменш доцільними з фінансової точки зору.
Автоматичне тестування у браузері потрібно скорочувати до мінімуму та використовувати для симуляції поведінки користувачів в основних потоках взаємодії та повних сценаріях, де використовується система загалом.