Всім привіт, мене звати Вікторія, і сьогодні я хочу поділитися з вами своїми напрацюваннями за темою тестування критичного шляху.
Я працюю тестувальником у web-агенції трохи понад рік, і якийсь час тому переді мною постало завдання провести тестування критичного шляху у проєкті. Для мене це було вперше, і до моєї базової підготовки такі завдання не входили, треба було робити щось нове для мене. Не скажу, що завдання було виконано відмінно. Були зауваження, коментарі, тому я вирішила заглибитися в цю тему й опрацювати її детальніше. А зараз, власне, я хочу поділитися результатами цього невеликого дослідження і тим, що вдалось в ньому знайти. Можливо це стане в пригоді нашій IT-спільноті.
Для кого цей пост може бути корисним? Найімовірніше, початківцям в IT або QA (тестувальникам/інженерам із якості) із невеликим досвідом, які бажають дізнатися трохи більше в цьому питанні.
Спочатку я розкажу про визначення цього виду тестування та його місце в системі тестування. Потім ми поговоримо про передумови для впровадження тестування критичного шляху, про його особливості та підходи. А потім про те, що власне треба робити, щоб зауважень могло бути менше)
Як казав хтось розумний, спочатку домовимось про терміни.
При дослідженні теми я зустрічалася із кількома визначеннями і назвами цього типу тестування. Як на мене — найбільш вдале визначення описане в книзі Святослава Кулікова «Software Testing. Base Course (3rd edition)»:
«Тестування критичного шляху — це перевірка функціональності, яка використовується типовими користувачами в типовій повсякденній діяльності».
Я сподівалася знайти додаткові визначення у міжнародних стандартах таких як IEEE 829—1998, ISO/IEC/IEEE 29119, щоб порівняти різні погляди на цей тип тестування, але на жаль нічого знайти не вдалося. Під час пошуку зʼясувалося, що в іноземній літературі та самих стандартах тестування критичного шляху має різні назви, найпопулярніші із них: Critical Path Test, Happy Path Testing та Golden Path Testing.
Happy Path Testing / Golden Path Testing — часто визначають як чітко визначені тест-кейси, що використовують відомі вхідні дані, виконуються без винятків та врешті дають очікуваний результат (wikipedia).
В цій публікації я буду опиратися саме на визначення із книги Кулікова С. та саме в тому сенсі, що є у визначенні. Усі перевірки, які будуть у рамках цього типу тестування я оформлювала у список — Чек-Лист. А тестування критичного шляху відбувалося за чек-листом критичного шляху (ЧЛКШ). Тому далі в тексті я буду вживати ЧЛКШ маючи на увазі сукупність перевірок для тестування критичного шляху.
З термінами визначилися, отожбо рушаймо далі.
Щоб зрозуміти типи перевірок та як саме треба тестувати, я розглянула місце та взаємозв’язки цього типу тестування з іншими. Наприклад, якщо це тестування відноситься до тестування чорної скриньки, то це означає що в тест-кейсах не можуть бути перевірки із доступом до коду або БД, а в дійсності тестування критичного шляху не припускає цього, в тест-кейсах мають бути лише перевірки, які відтворюють поведінку типового користувача.
На схемі нижче наведені основні типи тестування ПЗ та вказана позиція, яку займає ЧЛКШ:
Зі схеми стає зрозуміло, що Happy Path Testing належить функціонального та системного тестування.
Крім того, ЧЛКШ часто відносять до позитивного тестування (в більшості випадків, буде розглянуто далі) та підходу тестування чорної скриньки, адже потрібно орієнтуватися на кінцевого користувача, а він зазвичай не бачить код.
Отже, для себе я визначила, що ЧЛКШ — це системне тестування, яке містить в основному позитивні перевірки без будь-якого доступу до коду чи БД.
Важливо! Не потрібно плутати ЧЛКШ з приймальним тестуванням (UAT). В обох випадках перевіряється критичний функціонал, але в ЧЛКШ перевірка відбувається тестувальником протягом усього часу розробки проекту, а приймальне тестування зазвичай проводиться кінцевим користувачем або клієнтом, щоб перевірити/прийняти програмну систему перед розгортанням на production
Наступним стало питання: Коли варто починати підготовку ЧЛКШ?
Коли варто починати підготовку ЧЛКШ
Ознайомившись з інформацією в інтернеті та думкою моїх колег, я дійшла до висновку, що існує 2 основних міркування, коли варто починати підготовку ЧЛКШ і я вважаю, що обидва мають право на існування. Давайте розглянемо їх детальніше:
- Перша думка. Варто починати підготовку ЧЛКШ ще на початку проєкту, як тільки готова проєктна документація. Якщо після ознайомлення із вимогами можливо визначити основний функціонал та залежності між ним, то вже варто починати розробку ЧЛКШ. Цей же варіант описує в своїй книзі Святослав Куліков.
Але не завжди на початку проекту вже є готова вся документація, часто вона допрацьовується вже в процесі розробки. Тому в такому випадку може бути більш доцільним 2 варіант.
АБО
- Друга думка. Підготовку ЧЛКШ варто починати за 2-3 дня перед першим деплоєм на production (Stage і т. д.), як буде реалізовано більш як 60% основного функціонала проєкту, що планується деплоїтися. Цей варіант я зустрічала у своїй практиці.
Так як в другій думці процес розробки вже почався, тому буде легше визначити критичний функціонал та вже будуть відомі особливості даного проекту, що в свою чергу допоможе написати коректніший ЧЛ.
Важливо! Незалежно від варіанту, ЧЛКШ може зазнавати змін та доповнень протягом усього процесу розробки проєкту. Зазвичай оновлення ЧЛКШ потрібно закладати в план підготовки до деплою на production або перед самим проходом ЧЛ.
Із цим питанням розібралися, тому ідемо до наступного, не менш цікавого: скільки часу має займати прохід ЧЛКШ? .
Скільки часу в середньому має займати проходження ЧЛКШ
Якщо подумати логічно, то всі проекти різні за функціональністю, складністю, залежністю від інших сервісів і т. д., також, кожен проект має свої терміни, ресурти, вартість із яких визначається кількість доступних годин для тесту, все дуже індивідуально.
Тому, подивившись інформацію на різних ресурсах, я дійшла до висновку, що немає якоїсь чіткої кількості часу необхідного для проходження ЧЛКШ, але можливо вирахувати приблизну кількість часу, на яку можна було б орієнтуватися.
Для цього варто:
- Розділити проєкт на основні модулі
- Визначити скільки часу в середньому пішло на прохід ЧЛ для кожного модуля (тут потрібно не додавати всі проходи, а визначити середній час 1 проходу)
- Підсумувати середній час для кожного модуля і вирахувати від цієї цифри ~20%. Це і буде приблизний час проходу ЧЛКШ.
Звучить страшно, тому для кращого розуміння давайте розберемо цей кейс на прикладі інтернет-магазину
Важливо! Якщо проєкт складається із декількох частин (наприклад: admin, public, app і т. д.), для кожної із них потрібно писати окремий ЧЛКШ.
Сподіваюсь, ви розібралися із цією логікою, якщо ж ні, пишіть ваші питання в коментах. А ми переходимо до наступного етапу.
Кроки створення ЧЛКШ
Переходимо до одного із найкорисніших пунктів, як на мене.
Зʼясувалося, що на просторах інтернету є велика кількість інформації із рекомендаціями по створенню ЧЛКШ. Ознайомившись із ними, я підготувала кроки якими користуюсь під час підготовки ЧЛКШ. Пропоную спочатку ознайомитися із схемою, а далі із поясненням по кожному пункту:
- Визначення критичного функціонала — на цьому кроці варто визначити основні точки критичного функціоналу на яких далі буде базуватися побудова ЧЛКШ. Рекомендую результати обговорити із людиною, що добре розуміється на проєкті (наприклад ПМ), щоб впевнитись, що нічого не було пропущено.
- Визначення залежностей — наступним кроком буде визначення залежностей між основними точками функціоналу із першого кроку. Це необхідно для того, щоб переконатися, що тестування виконується в правильному порядку.
- Створення структури ЧЛКШ — на цьому етапі варто розбити ЧЛ на блоки. Блоки повинні складатися із логічно обʼєднаних частин функціоналу (наприклад: вхід та реєстрація, розміщення нової статті і т. д.), а не назв сторінок (наприклад: вхід, реєстрація флоу, головна сторінка, сторінка новин і т. д.)
- Оцінка та розподіл часу — тут варто визначити скільки (приблизно) часу буде необхідно для тестування блоків із 3 кроку. Детальніше цю інформацію обговорювали у попередньому розділі. Варто розуміти, що це приблизний час для проходження блоків, тому (*є можливість похибки від часу від наданої раніше оцінки (естімейту)).
- Розробка ЧЛКШ — після успішного виконання всіх попередніх кроків, можна починати підготовку ЧЛКШ.
Якщо проєкт має велику кількість функціональності, для кращого його тестування краще визначити основні моделі поведінки користувача та підготувати кілька ЧЛКШ відповідно цим моделям. Пропоную розібратися, що таке модель поведінки користувача та як її визначити.
Моделі поведінки користувачів, що це таке та як вони впливають на ЧЛКШ
Напевно тут знову варто почати із визначення, для кращого розуміння моделі поведінки користувачів. Ото ж бо:
Модель поведінки користувачів — це спроба зрозуміти та передбачити, як користувачі можуть взаємодіяти із певним ресурсом (сайтом).
Давайте розглянемо можливі моделі поведінки користувачів на вже існуючому проєкті. Для прикладу візьмемо сайт work.ua.
На сайті існує 2 основні моделі поведінки користувачів:
- роботодавці, які розміщують оголошення з метою знайти працівника
- кандидати, які шукають роботу
В цьому випадку для юзера буде важливим функціонал саме розміщення вакансії та перегляд відгуків на оголошення, адже в нього мета це пошук працівників для найму.
У 2 випадку важливим буде перегляд списку вакансій, детальний перегляд кожного оголошення та відгук на вакансії (включає перевірки для профілю юзера). Орієнтуючись цією інформацією, для сайту work.ua (pablic part) варто було б підготувати 2 чек листа критичного шляху.
І тут виникає питання:
Чи можна для декількох моделей користувачів підготувати 1 ЧЛКШ?
Відповідь — так. Якщо сайт має незначну кількість функціоналу і в результаті прохід по ЧЛ не буде займати цілий робочий день. Але для кращого тесту потрібно повторити поведінку користувача із кожної моделі, тому я б рекомендувала все-таки ЧЛи розділяти.
На цьому основна частина моєї статті закінчується, але під час підготовки, у мене зʼявлялися додаткові питання, які я також вирішила винести і пошукати по них інформацію. Тому пропоную вам із ними теж ознайомитися)
Варто знати
1. Що потрібно та не потрібно враховувати під час написання ЧЛКШ
| Потрібно враховувати | Зайве |
| Тестування основних функцій проєкту. Під час проходження ЧЛ не варто тратити велику кількість часу на не критичний функціонал, або який не використовується типовими користувачами. | Тестування UI, UX та верстки (піксель перфект, ресайз вікна). Це необхідно перевіряти на етапі функціонального тестування. |
|
Тестування встановлення (для апп). Для апп буде коректним додатково перевірити:
|
Тестування продуктивності та безпеки. Цей вид тестування також варто проводити окремо від ЧЛКШ |
2. Позитивні та негативні перевірки в ЧЛКШ
ЧЛКШ може бути як позитивним, так і негативним. Давайте детальніше розберемося у їхній відмінності, щоб розуміти який варіант краще використовувати на практиці.
Позитивний ЧЛКШ — це перевірка працездатності функцій програмного продукту, з якими користувач стикається щодня.
Перевірки для позитивного ЧЛКШ:
- Успішна реєстрація / авторизація
- Повідомлення коректно відправляється
- Дані правильно зберігаються та відображаються
Негативний ЧЛКШ — це перевірка різноманітних варіантів нестандартного використання функціоналу, що використовується користувачем щодня.
Перевірки для негативного ЧЛКШ:
- Заглушка Offline виводиться при вимкненні інтернету на будь-якій сторінці в додатку
- Згорнути / розгорнути додаток — помилки відсутні
- Якщо під час телефонного дзвінка був відкритий додаток, вікно не закривається, app продовжує працювати коректно
Важливо! У більшості випадків використовують позитивний ЧЛКШ, але включають в нього важливі негативні перевірки. Наприклад: В калькуляторі не можна ділити на 0
3. В яких проєктах можна не використовувати ЧЛКШ
Існують деякі проєкти в яких використання ЧЛКШ може бути нерелевантним, але зазвичай це питання краще узгоджувати з керівником проєкту (ПМ, лід QA і т. д.).
І так, нерелевантним використання ЧЛКШ може бути у таких випадках:
- При тестуванні простих проєктів. Якщо сайт має просту структуру та простий критичний шлях (лендінг або просто форма), ЧЛКШ можна не використовувати.
- В проєктах лише зі статичними сторінками. Наприклад, проєкт, який складається зі статичних сторінок має малу кількість потенційних проблем, тому в такому випадку використання ЧЛКШ не потрібне.
- В проєктах із сторонніми сервісами. Якщо проєкт взаємодіє зі сторонніми сервісами, які опрацьовуються велику частину функціонала, використання ЧЛКШ може бути менш ефективним.
4. Основні відмінності між ЧЛ Смоук, ЧЛКШ та Розширеним тестуванням
| Ознака | Смоук | ЧЛКШ | Розширене |
| Призначення | Швидка перевірка основного функціонала | Перевірка критичного функціонала | Детальна перевірка всього функціонала згідно з вимогами |
| Задача | Виявити серйозні помилки або проблеми проєкту | Виявити помилки в головному функціоналі | Виявити всі невідповідності вимогам продукту |
| Обсяг | Поверхневий огляд головних функцій системи | Обмежений перелік критичних елементів системи | Весь функціонал системи |
| Метрики | Готовність загального функціонала до подальшого тестування | Коректність роботи критичних елементів згідно з вимогами | Відповідність функціональних вимог |
| Проведення | Після зміни компонента, перед деплоєм та після деплою на prod | Перед деплоєм та після деплою на prod | Впродовж розробки продукту |
| Результати | Виявлення очевидних проблем або некоректностей | Виявлення конкретних проблем з основною функціональністю | Виявлення помилок, некоректностей та відхилень від усього обсягу очікуваної функціональності |
| Залежність від інших ЧЛ | Не залежить | Не залежить | Залежить від інших ЧЛ для перевірки різних функціональних аспектів системи |
Висновки
Якщо ви знали, що з вашим чек листом критичного шляху щось не так, але не могли визначити що саме, то ця стаття буде чудовою відправною точкою. В ній підіймаються такі теми, як: коли варто починати підготовку чек-листа, скільки часу приблизно має займати прохід, кроки створення та інші.
Зрештою, важливо пам’ятати, що чек-лист критичного шляху — це «живий документ», який може і повинен змінюватися відповідно до змін у функціональності проекту. Систематичне оновлення та вдосконалення чек-листа гарантує його актуальність та високу ефективність в процесі тестування.
Будь ласка, в коментарях напишіть ваш досвід у цьому питанні, порекомендуйте літературу або ще щось, що може бути корисним для QA з невеликим досвідом у цьому питанні, та тим, хто цікавитиметься цією темою глибше.