4 принципи автоматизованого тестування для більшої надійності автотестів

Вступ

Я працюю в галузі тестування якості майже шість років і вважаю, що найбільша проблема в автоматизованому тестуванні — упевненість у результатах. Тест, що «впав», не дає достатньої впевненості в тому, що ми виявили дефект. Це відбувається тому, що існує безліч можливих причин збоїв, наприклад, проблеми з оточенням або інструментами, валідні зміни у програмному забезпеченні, які сталися внаслідок подальшої розробки, або погану архітектуру тестів.

У рамках опитування, проведеного наприкінці 2021 року, приблизно 59% респондентів заявили, що регулярно стикаються з ненадійними тестами. Тест, що «впав», вимагає уваги людини, а це збільшує час зворотного зв’язку. І виходить, що автоматизовані тести більше не автоматичні. Але як ми можемо покращити цю ситуацію?

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

Принцип 1. Ізоляція

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

У прикладі нижче тести ізольовані за допомогою унікальних тестових даних. Без ізоляції на TEST 1 може вплинути TEST 2.

Принцип 2. Керування станом застосунку

В інженера має бути можливість керувати станом програмного забезпечення через API або взаємодією напряму з базою даних. Усі зовнішні сервіси мають бути замокані. Це забезпечує передбачувану поведінку застосунку. Інженер має бути впевнений у тому, що застосунок готовий до тестування перед початком виконання тестів а не по результату.

Окрім того, цей принцип допомагає створювати маленькі, атомарні тести, які краще читаються й швидше виконуються.

У цьому прикладі створюється спеціальний продукт через API, і ми можемо бути впевнені, що продукт доступний. Продукт видаляється після виконання TEST 3 для підтримки чистоти середовища.

Принцип 3. API краще, ніж UI

Цей принцип тісно пов’язаний із попереднім. Мета — використовувати UI тільки на сторінці, де ми хочемо щось перевірити. Проксі — це інструмент, який допомагає дізнатися, що відбувається під капотом, а потім змоделювати це за допомогою взаємодії з API та базою даних.

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

Принцип 4. Тестування на основі функціональності

Інтерфейс користувача часто зазнає змін на етапі розробки. Я вважаю, що цю проблему можна вирішити, тестуючи тільки основну функціональність. Малоймовірно, що кнопка «купити» зникне на сторінці, призначеній для продажу чогось.

Висновок

Насамкінець хочу зазначити, що всі вищевказані принципи ґрунтуються на особистому досвіді, і це не правила, а рекомендації. Ви можете вирішити, чи дотримуватися хоча б одного з цих принципів, чи не дотримуватися взагалі, — залежно від ситуації.

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