Тестування ПЗ: рівні, методи та автоматизація

Знаєте, хто найчастіше скептично ставиться до тестувальників?

Розробники, які ще не стикнулися з серйозними проблемами в продакшені. Вказувати на помилки завжди некомфортно. Особливо коли ти впевнений, що все зробив правильно.

Досвідчені розробники, навпаки, цінують роботу тестувальників. Бо розуміють просту річ: краще знайти баг на етапі тестування, ніж отримати лавину скарг від користувачів після релізу.

Тож давайте розберемося, що таке тестування ПЗ насправді. Без ідеалізації, але й без недооцінки.

Що таке тестування програмного забезпечення?

Тестування ПЗ — це систематичний процес перевірки програмного продукту на відповідність вимогам, виявлення дефектів та оцінка якості до того, як він потрапить до юзера.

Основні цілі тестування — знайти баги до того, як їх знайдуть ваші клієнти (а вони знайдуть, повірте). Але це не єдина мета. Тестування ПЗ також перевіряє:

• Чи працює функціональність так, як задумано.

• Чи витримує система навантаження.

• Чи захищені дані користувачів.

• Чи зручний інтерфейс для звичайних людей.

Основні рівні тестування програмного забезпечення

Тестування програмного забезпечення — це не одна велика перевірка наприкінці розробки. Це ціла драбина, де кожна сходинка має своє призначення.

Модульне тестування (Unit Testing). Тут перевіряємо найдрібніші шматочки коду: окремі функції, методи, класи. Це як тестувати кожну цеглинку перед тим, як будувати будинок.

Зазвичай це робить сам розробник одразу після написання коду. Швидко, ефективно, і дозволяє знайти помилку там, де вона з'явилася (а не через три місяці у продакшені).

Інтеграційне тестування. А тепер уявіть: кожна цеглинка працює ідеально. Але чи будуть вони добре поєднуватися разом?

Інтеграційне тестування перевіряє взаємодію між різними модулями системи. База даних спілкується з бекендом? API коректно передає дані фронтенду? Ось це все.

Системне тестування. Тут ми вже дивимося на всю систему цілком. Перевіряємо весь продукт від початку до кінця, так, ніби ми — справжній користувач.

На цьому етапі часто знаходять найцікавіші баги. Ті, про які ніхто з команди навіть не думав.

Приймальне тестування (Acceptance Testing). Тож, останній рівень тестування ПЗ — що це в себе включає? Тут зазвичай підключається замовник або група реальних користувачів. Вони перевіряють: чи це те, що вони хотіли? Чи вирішує продукт їхні проблеми?

Один клієнт розповів нам історію: вони розробили систему документообігу, все тестували, все працювало. А на приймальному тестуванні виявилося, що менеджери компанії в принципі не розуміють логіку інтерфейсу. Довелося переробляти.

Класифікація методів тестування

Методів тестування існує стільки, що можна заплутатися. Види тестування можна класифікувати за різними критеріями. Давайте систематизуємо це все у зрозумілі категорії.

За рівнем доступу до коду

Black-box testing (тестування «чорної скриньки»). Тут тестувальник не бачить код взагалі. Він просто користується продуктом як звичайний юзер. Вводить дані, натискає кнопки, дивиться, що виходить.

White-box testing (тестування «білої скриньки») — протилежний підхід. Тестувальник знає всю внутрішню структуру коду, аналізує логіку, перевіряє всі можливі шляхи виконання програми.

Gray-box testing можна вважати золотою серединкою. Тестувальник має частковий доступ до коду або документації. Це дозволяє створювати більш розумні тест-кейси, розуміючи, як система працює всередині.

За ступенем автоматизації

Тут все просто.

Ручне тестування — це коли жива людина сідає, відкриває застосунок і методично перевіряє кожну функцію. Повільно, але іноді незамінно (особливо для перевірки UX).

Автоматизоване тестування означає перевірки, зроблені скриптом. Швидко, можна запускати хоч щогодини, не втомлюється.

Але (і це важливо) автоматизація не завжди краща за ручне тестування. Інколи швидше перевірити руками, ніж писати автоматичний тест на годину.

За метою тестування

Функціональне тестування перевіряє, чи працюють функції так, як описано у вимогах. Кнопка «Зберегти» справді зберігає? Калькулятор правильно рахує? Це воно.

Нефункціональне тестування — це про те, як працює система. Швидкість, стабільність, безпека, масштабованість. Ваш додаток може мати всі потрібні функції, але якщо він завантажується 30 секунд — це провал.

Сюди входять:

• тестування продуктивності;

• навантажувальне тестування;

• тестування безпеки;

• юзабіліті-тестування.

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

Етапи тестування ПЗ

Тестування програмного забезпечення — це не хаотичний процес «давайте поклікаємо і подивимося». Це структурований цикл з чіткими етапами.

   1. Аналіз вимог

Перше питання тестувальника: а що взагалі має робити ця система? Звучить банально, але я нам зустрічалися проєкти, де почали тестувати без чітких вимог. Результат? Команда суперечиться про те, чи є помилка помилкою.

На цьому етапі тестувальник вивчає документацію, спілкується з розробниками та замовником, з'ясовує всі нюанси.

   2. Планування тестування

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

Створюємо тест-план — документ, який описує весь процес перевірки. Це як дорожня карта для команди тестування.

   3. Проєктування тестових сценаріїв

Найцікавіша частина. Тестувальник придумує різні ситуації використання системи:

• стандартні сценарії (хеппі-пас);

• нестандартні випадки;

• граничні значення;

• помилкові дані.

    4. Налаштування тестового середовища

Перед тестуванням потрібно підготувати середовище: сервери, бази даних, тестові обліківки, дані. Це має максимально нагадувати реальне продакшн-середовище.

Ось тут часто виникають проблеми: «У мене на локальній машині все працює!» Так, але на сервері з іншими налаштуваннями — ні.

    5. Виконання тестування

Власне процес перевірки. Запускаємо тест-кейси, фіксуємо результати, знаходимо дефекти.

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

   6. Звітність і аналіз результатів

Після тестування складаємо звіт: скільки тест-кейсів пройдено, скільки знайдено дефектів, наскільки критичні ці помилки.

«Якість важливіша за кількість. Один хоум-ран набагато кращий за два дублі» 

© Стів Джобс

   7. Регресійне тестування та завершення циклу

Після виправлення дефектів перевіряємо: чи справді все полагоджено? Чи не з'явилися нові проблеми?

І тільки коли всі критичні та важливі баги виправлені, а продукт стабільно проходить всі тести, даємо «зелене світло» на реліз.

Порівняння методів тестування

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

 Головне правило: не намагайтеся використовувати один метод для всього. Розумне поєднання різних підходів дає найкращі результати.

Висновок

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

Що таке тестування програмного забезпечення у підсумку? Це інвестиція. У якість, репутацію та спокійний сон вашої команди після релізу.

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

FAQ