Усе, що ви хотіли знати про тестування, але боялися спитати

💡 Усі статті, обговорення, новини про тестування — в одному місці. Приєднуйтесь до QA спільноти!

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

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

Види тестування

Є багато видів та варіантів тестування, але ми розглянемо лише ті, з якими я безпосередньо стикався у своїй роботі як розробник, про які чув на мітингах у своїх командах та на які найчастіше ми натрапляємо на проєктах. Це саме ті 80% тестів, які будуть у вас на думці, якщо ви не є QA-інженером.

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

У своїй роботі ви рано чи пізно будете використовувати, писати або чути про такі тести або терміни:

• Unit tests;
• Acceptance tests;
• UAT tests;
• Integration tests;
• Smoke tests;
• Manual tests;
• Automated tests;
• Regression tests;
• E2E tests (UI tests);
• System tests;
• Component tests;
• API tests;
• Functional tests;
• Non-functional tests;
• Performance testing;
• Nightly testing.

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

Упродовж всієї статті ми ще не раз повертатимемося до піраміди. А щоб не бути вже зовсім оригінальним, створімо свою власну піраміду!

Навіщо мені знати щось про тестування

Я розробник і повинен писати код. Для тестування є спеціально найняті працівники — QA, от нехай вони й тестують.

Переваги знання для вас:

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

Поділюсь своїм досвідом з попередньої роботи. Працював я у великій продуктовій компанії Fiverr. Це маркетплейс для фрилансерів. В Україні більш відомий їхній конкурент Upwork, але суть і масштаб схожі й у цій історії не мають загалом значення. Особливістю роботи в цій компанії була повна відсутність QA. Тобто жодного тестувальника на декілька сотень розробників. Унікальний і дуже цінний досвід для мене.

Забезпечення якості продукту (у нас це були окремі сервіси) лягало на команду розробників. Кожна команда відповідала за свою частину платформи. Тому й під час співбесіди, а згодом і під час роботи тестування було основою і критично важливою частиною. Чому так? У компанії впроваджена практика Continuous Deployment — розробник сам ухвалює рішення про доставлення завершеної задачі в production. Після всіх етапів тестування, перевірок, налаштування метрик та моніторингу натискається кнопка Deploy, і зміни доступні всім користувачам.

Середовища тестування

Щоб розуміти, у якому середовищі відбувається кожен варіант тестування, додамо наступні терміни:

• середовище розробки (dev env) — це середовище використовують розробники для написання коду, налагодження та виправлення помилок;
• середовище тестування (stage env) — це середовище, у якому працюють тестувальники для перевірки функціонала;
• препродакшн середовище (preprod env) — це середовище, що максимально наближене до продакшну;
• Продакшн середовище (production env) — це середовище, у якому працюють користувачі.

Ручне та автоматизоване тестування

Перше, і, напевно, найголовніше групування тестів — це розділ на ручні та автоматизовані. Зазвичай говорять manual та automation.

Ручне тестування (Manual testing) — це процес ручної перевірки програмного забезпечення на помилки.

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

Зазвичай цим займається окрема людина (декілька людей) у команді — Manual QA. Цей вид тестування є найдорожчим з точки зору фінансів і часу, адже живі люди повинні кожен раз перевіряти роботу.

Коли в команді нема QA, як було в мене, розробник виконує dev testing. Після деплою на тестовий сервер ми перевіряли, чи все працює, проходили сторінками, компонентами, функціоналом, щоб упевнитись, що все гаразд. Після деплою в production робились аналогічні дії. У випадку виявлення помилок скасовувалося розгортання (deploy rollback).

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

UAT (User acceptance testing, тести користувацької прийнятності) — це конкретний вид тестування, який здійснюють користувачі або представники замовника з метою перевірки того, чи відповідає програмний продукт їхнім потребам та очікуванням. Не всі ж працюють в продуктових компаніях, де розробники можуть бути й замовниками. У сфері outsource або outstaff розробка ведеться на замовлення інших компаній.

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

Автоматизоване тестування (Automation testing) — це процес використання спеціальних програмних інструментів і скриптів для виконання тестів на програмному продукті без прямої участі людини.

Якщо роботу, яка регулярно повторюється, можна автоматизувати, то її потрібно автоматизувати.

Перед тим, як продовжимо, додамо перший варіант нашої піраміди тестування:

Unit-тестування

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

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

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

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

Зазвичай на проєктах налаштовуються процеси безперервної інтеграції та розгортання проєктів, так звані Continuous Integration / Continuous Delivery / Continuous Deployement (цей не завжди). І от аби додати ваш код в головну гілку репозиторію, система автоматично проганяє всі Unit-тести, щоб впевнитися, що код працює коректно, згідно із задумом розробника.

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

Наша піраміда отримує фундамент:

Unit-тестування є засобом виконання і реалізації певних вимог до системи. Будь-яка система, окрім функціональних вимог містить і нефункціональні, які називаються quality атрибутами (атрибути якості). Наприклад, продуктивність або доступність системи. Є ще дві властивості системи, які називаються modifiability i maintainability.

Modifіability відповідає за те, що система може модифікуватися, тобто якщо потрібно внести зміни, то ці зміни можливо внести, причому в певні терміни. Це дає впевненість замовнику, що можна буде додати нову функціональність і витратити на це конкретний час. Якщо замовник дізнається, що зміну потрібно вносити місяцями — то це буде порушенням атрибута modifіability.

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

Дані властивості тестів дають нам та іншим розробникам, які працюватимуть над кодом впевненість, що їхні зміни не зламають усе. Після цих змін будуть запущені тести, і вони покажуть, що код працює, як і очікується, або відразу зʼявиться інформація про помилку та некоректну роботу.

Тема неймовірно важлива, і про неї можна говорити годинами, рекомендую переглянути відео на моєму каналі, присвячене конкретно Unit-тестам.

Тестування End-to-end

Цей вид тестування, напевно, найбільш поширений після unit-тестування. Його полюбляють багато замовників та компанії розробників, адже результати дуже наочні.

End-to-End тестування (E2E тестування) — це вид тестування програмного продукту, спрямований на перевірку і валідацію поведінки та функціональності в реальних умовах від початку до кінця (весь шлях обробки даних або процесу в рамках системи чи застосунку). Його основна мета полягає в тестуванні всіх компонентів системи, щоб впевнитися, що вони працюють правильно разом та відповідають очікуванням користувачів.

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

На всіх проєктах, де я працював, та й загалом написанням цих тестів займаються окремі люди — Automation QA. Робота обʼємна, адже ціллю є перехід від ручного до автоматизованого тестування. Усі сценарії (тест-кейси), що виконувала людина, тепер повинен виконати скрипт. Він же готує звіти та опрацьовує помилки. А нам потрібно отримати та оцінити результат цих тестів.

Я сказав, що цим займаються окремі люди (це вже плюс до вартості проєкту за часом та коштами), але це не завжди так. Є випадки, коли e2e-тести також пишуть розробники. Раніше для створення цих тестів потрібно було використовувати складні інструменти, наприклад Selenium чи Cucumber, тому й шукали спеціалістів. Зараз є простіші рішення, уже згаданий Cypress виконує всю ту ж роботу, а код пишеться на JavaScript зі зручним API. Він настільки зручний, що на попередній роботі команда неодноразово розглядала його як реалізацію e2e на проєкті, і писати мали це безпосередньо розробники, QA ж не було в компанії.

Особливістю цього тестування є момент його початку. Коли продукт активно розробляється і часто змінюється, то й тести потрібно постійно оновлювати. Та чи є в цьому сенс? Якщо зачекати, щоб сторінки вебсайту були більш-менш завершені, вимоги фіналізовані, тоді й менше зусиль на розробку та підтримку таких тестів потрібно.

Запускають e2e-тести в середовищі, максимально наближеному до production. У нашому випадку це має бути preprod або stage.

Враховуючи вартість та час цих тестів, вони займають своє місце практично на вершині піраміди.

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

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

Інтеграційне тестування

Усе пізнається в порівнянні. Unit-тести призначені для перевірки маленьких, ізольованих частин коду, виконання яких не створює жодних побічних ефектів, як-от записів у файли чи бази даних, мережеві запити та інше. End-to-end навпаки — тестує всю систему в готовому вигляді.

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

Інтеграційне тестування (Integration tests) — етап тестування, на якому окремі модулі програмного забезпечення обʼєднуються та тестуються як група.

Основною відмінністю від тих самих Unit-тестів є дозволена наявність побічних ефектів (side effects). Наприклад:

• У нас є React hook, що робить REST-запит. У Unit-тестуванні ми мокаємо запит і тестуємо поведінку хука під час успішного отримання даних, помилкових даних або неуспішному виконанні запиту взагалі. Водночас API call не виконується, лише симуляція на підготовлених даних — жодних побічних ефектів. Під час інтеграційного тестування запит може відправлятися. Головне перевірити інтеграцію нашого хука зі стороннім сервісом. За потреби сам сервіс всередині можна також замокати. Нам не цікаво, як він отримує дані, чи робить кудись запити, чи просто повертає заздалегідь готову відповідь.
• У нас є клас на бекенді (або React Server Component), який робить запит в базу даних. Під час інтеграційного тестування цілком нормально перед початком виконання тесту створити автоматично базу даних, зробити запит і перевірити результат роботи. Після завершення тесту або циклу тестів такі бази даних видаляються.
• У нас є React компонент, що використовує сторонню бібліотеку. У Unit-тестах зазвичай методи даної бібліотеки можуть мокатись, особливо, якщо вони викликають side effects, в інтеграційному — ні. Але памʼятаємо, що тестуємо ми наш компонент і те, як він інтегрується із зовнішньою бібліотекою. Роботу самої бібліотеки тестувати не потрібно, адже ми очікуємо, що розробники цієї бібліотеки вже самі написати тести на неї.

API-тестування

Вид тестування, який на моїй практиці завжди ігнорувався. Найчастіше ми його реалізовували як частину Unit-тестування, коли мокали всі зовнішні дії або виклики. По-хорошому, це має бути підвид інтеграційного тестування, адже тут теж дозволені side effects.

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

Тести API (API tests) — це вид тестів, які призначені для перевірки функціональності та надійності API (Application Programming Interface). API — це набір правил і протоколів, які дозволяють різним програмам чи компонентам взаємодіяти між собою. Ці тести перевіряють, чи API працює правильно, чи надає очікувані результати під час виклику різних його методів чи функцій.

Зверніть увагу, що під терміном API розуміється широке значення програмного інтерфейсу, а не лише RESTful API.

Техніка тестування подібна до Unit-тестування тим, що націлена на рівень коду. А відрізняється тим, що зазвичай це завдання тестувальника, а не розробника. Цей вид тестування актуальний для розробників бібліотек або SDK. Такі продукти використовуються тисячами клієнтів, і потрібно бути впевненим, що за умови зміни версії методи таких бібліотек повертають те, що і раніше.

Component-тестування

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

Компонентні тести (Component tests) — це вид тестів в галузі розробки програмного забезпечення, спрямований на перевірку функціональності окремих компонентів програми або застосунку. У порівнянні з Unit-тестами, які перевіряють ізольовані частини програми, ці тести більше фокусуються на тестуванні компонентів програми, які можуть містити кілька класів, модулів, об’єктів чи послуг.

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

Розібравшись з видами тестів, поглянемо на їхні абстракції. Під час роботи я неодноразово чув такі страшні слова як регресія та Smoke-тестування. Тестувальники кажуть, що днями роблять регресію, а я не можу зрозуміти, то що ж вони таке роблять.

Регресивне тестування

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

Регресивне тестування (Regression testing) — це вид тестування програмного забезпечення, який спрямований на перевірку того, чи вплинули останні зміни в коді (новий код чи виправлення помилок) на функціональність системи, що існує. Основною метою регресивного тестування є виявлення можливих регресійних дефектів, тобто негативних змін в програмі, що виникли внаслідок нових змін.

Оскільки зміни вносяться постійно, то і тестувати потрібно постійно. Щоб не робити це кожного дня, зазвичай обмежуються певними термінами розробки, наприклад спринтами. У кінці кожного спринту (або на початку) QA розпочинає цикл тестів, щоб впевнитись, що останні зміни не створили більше помилок, ніж виправили.

В ідеальному світі регресія — це запуск тестів End-to-end, які проходять усі сценарії, покривають усі happy path (сценарій або послідовність подій, за яких система працює без помилок і відповідає на вхідні дані або дії користувача, як очікувалося).

Оскільки більшість живе не в ідеальному світі, то в регресію додається і ручне тестування, а це вже завжди довше за часом. У кінці повинен бути звіт про виконану роботу і, за потреби, створені задачі (баги) в системі трекінгу задач, наприклад Jira.

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

Виконується це тестування на preprod-середовищі або в іншому, максимально схожому на production. Можна і stage, але точно не production.

Smoke-тестування

Якщо регресію не можна проводити на проді, то як дізнатися, що після релізу все чудово працює? Окрім моніторингу метрик, аналітики та повідомлень про помилки, можна провести Smoke-тестування. З назви можна здогадатися, що тут дивимось, що «підгорає», звідки йде димок.

Smoke тестування (іноді відоме як Smoke Testing або Build Verification Testing) — це вид тестування програмного забезпечення, який використовується для перевірки основних та критичних функцій програми після збірки або оновлення. Головною метою Smoke-тестування є визначення того, чи може програма запуститися без критичних помилок і чи варто продовжувати більш ретельне тестування.

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

Приклад із життя. Розробник завершує задачу, реалізовує новий, наприклад, віджет. Після перевірок на dev-середовищі, проходженні усіх Unit та інтеграційних (за потреби) тестів, мержиться в головну гілку репозиторію і заливається на stage-сервер. Після цього можна зідзвонитися з QA, щоб швидко пройтися вимогами та перевірити, чи все реалізовано коректно. Буває, що під час розробки щось пропустили. Таке спільне (парне) швидке тестування завершеного завдання також можна назвати Smoke-тестом. У будь-якому випадку, після цього, якщо все реалізовано коректно і відповідно до вимог, QA буде тестувати згідно зі своїми підходами та практиками.

Functional- та non-functional-тестування

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

Функціональні вимоги до програмного забезпечення (Functional Requirements, FR) — це частина специфікації вимог, яка описує конкретні функції, операції, дії та функціональність програмного продукту. Функціональні вимоги визначають, як програма повинна поводитися в різних ситуаціях та які функції вона повинна надавати користувачам.

Тобто це те, що замовляє клієнт, коли приходить до вас зі списком вимог — requirements.

Будь-яка система, окрім функціональних вимог, містить і нефункціональні, які називаються quality-атрибути (атрибути якості). Наприклад, продуктивність або доступність системи. Сюди також входять modifiability i maintainability, про які я уже згадував вище.

Нефункціональні вимоги до програмного забезпечення (Non-Functional Requirements, NFRs) — це специфікація вимог, яка описує якості, характеристики та обмеження програмного продукту, які не стосуються конкретних функцій, але впливають на його загальну продуктивність, надійність, безпеку та інші аспекти. Нефункціональні вимоги визначають «як» програмне забезпечення повинно працювати, а не «що» воно повинно робити.

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

Performance тестування (Performance testing) — це вид тестування програмного забезпечення, спрямований на визначення та оцінку продуктивності та швидкодії програми або системи під навантаженням.

Висновок

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

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

Буду радий бачити вас на моєму каналі на YouTube — Maksym Rudnyi, де я ділюсь своїм досвідом в галузі розробки і де можна подивитися у форматі відео цю статтю.