Checklist-based testing: що це, як використовувати та навіщо

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

Вітаю, спільното! Мене звати Діана, і вже понад три роки я працюю QA Engineer. За цей час я мала досвід роботи у різних проєктах та доменах — від фінтеху до маркетингових платформ. У цій статті хочу поділитися з вами своїм досвідом використання Checklist-based testing: що це за техніка, коли вона ефективна та як її використовувати. Сподіваюсь, мій досвід буде корисним тим, хто хоче краще зрозуміти, як це працює.

Що таке checklist-based testing

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

У цьому випадку під «досвідом» мається на увазі не загальний досвід у тестуванні, а гарне орієнтування у ключових функціях конкретного продукту, вміння передбачити вразливі місця та чітке розуміння вимог.

Чим чекліст відрізняється від тест-кейсу

Чекліст — це список перевірок, які необхідно виконати під час тестування.

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

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

Може виникнути цілком логічне питання: чому не замінити тест-кейси чеклістами, якщо це пришвидшує роботу? Відповідь полягає у суті самих артефактів: чеклісти містять узагальнений список перевірок, тому не можуть повноцінно замінити тест-кейси. Чеклісти зручні для швидких перевірок і допомагають структурувати процес тестування. Особливо коли немає формальної документації — бо це все ж краще, ніж нічого.

З чого я розпочала застосування Checklist-based testing

Мій досвід з цією технікою почався, коли проєкт активно зростав і регресія стала займати все більше часу. До того використовували переважно тест-кейси як основну тестову документацію. Обсяг перевірок збільшувався, дедлайни стискалися, а якість треба було зберегти. Тоді увага впала на Checklist-based testing.

Розглянемо, як саме я впроваджувала цю техніку.

Крок 1. Обрала модуль, з якого почати

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

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

Крок 2. Проаналізувала функціонал

На цьому етапі я окреслила основні вимоги щодо модуля, acceptance criteria, очікування бізнесу та кінцевих юзерів, попередні баги та потенційні ризики. Також визначила, на яких платформах та браузерах варто проводити тестування — у моєму випадку це були вебверсії Safari та Chrome. Після цього я поділила перевірки на логічні блоки, щоб структурувати чекліст — функціональні перевірки та GUI.

Ці фактори допомогли створити ефективний документ, зафіксувати важливі перевірки, які надалі допомогли не пропускати критичні баги на прод.

Крок 3. Перейшла до створення чекліста

Після аналізу я перейшла до написання чекліста. Користувалась best practices для будь-якого чекліста: перевірки мають бути чіткими та зрозумілими, адже в подальшому їх можуть виконувати різні QA.

Спочатку я написала перелік позитивних перевірок, щоб перевірити поведінку, коли функціонал використовується «як треба».

Далі перейшла до негативних перевірок, щоб перевірити реакцію системи на помилки та нестандартні кейси у використанні. До списку перевірок я додала колонки з необхідними браузерами/платформами та колонку для статусів тестування (зазвичай використовуються статуси Passed, Failed, Blocked, Not run або Skipped).

Крок 4. Інтегрувала у тестовий процес

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

Крок 5. Регулярно оновлювала перевірки

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

Приклади, у яких ситуаціях чеклісти працюють

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

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

Я використовувала чеклісти для таких типів тестування:

• Функціональне тестування. Можна швидко пройти всі основні кейси: логін, створення, редагування, видалення, перевірка даних тощо.

• Тестування GUI. Чекліст містить список необхідних перевірок елементів інтерфейсу: шрифти, кольори, відступи, кнопки, навігація.
• Юзабіліті тестування. Допомагає не забувати перевірити, наскільки зрозумілий і зручний продукт, чи немає непотрібних кроків або неочевидних кейсів.

Це значно спрощує роботу, коли тестування повторюється або передається іншому QA.

Як приклад — частина мого чекліста для GUI-тестування:

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

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

Приклад: у форму логіну додали опцію логіну через Google, тому крім основної перевірки нам треба протестувати, чи не зламалось нічого в «класичному» сценарії. Чекліст може містити такі перевірки:

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

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

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

Онбординг нових QA. Детальні чеклісти корисні як додатковий інструмент під час онбордингу нових тестувальників у команді. Вони допомагають комплексно ознайомитись із головними функціями продукту.

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

Переваги та недоліки Checklist-based testing

Checklist-based testing, як і будь-які техніки тест-дизайну, має як сильні сторони, так і певні недоліки.

Щодо переваг хочу виділити такі:

1. Швидкість та простота у написанні. Список перевірок створюється швидше, ніж повноцінні тест-кейси.
2. Повторне використання. Зазвичай чекліст можна повторно використовувати для різних кейсів: регресія, smoke тощо.
3. Підвищення послідовності тестування. Чекліст допомагає не пропустити важливі та критичні перевірки, коли зростає обсяг тестів.
4. Систематизація знань про продукт. Ця техніка допомагає систематизувати накопичену інформацію у форматі списку перевірок.
5. Можливість швидко відстежувати, що було протестовано. Якщо щось піде не так (наприклад, виникне баг після релізу), чекліст допомагає швидко прослідкувати, що було протестовано і чи був охоплений проблемний кейс.

Далі поговоримо про недоліки, а саме:

1. Відсутність деталізації. У більшості випадків немає чітких кроків та очікуваного результату, тому перевірки ґрунтуються на досвіді тестувальника.
2. Не виступає повною заміною іншої документації. Чекліст може бути як допоміжний інструмент та своєрідний гайд з тестування. Але на проєктах з чіткими правилами тільки чеклістів може бути недостатньо.
3. Чеклісти можуть втрачати актуальність. Продукт постійно змінюється (додаються нові фічі, розробники перестають робити старі помилки тощо), тому чеклісти також мають оновлюватись для збереження результату.
4. Субʼєктивність і залежність від автора. Чекліст часто створюється однією людиною на основі її досвіду та бачення, через це перевірки можуть бути незрозумілими для інших або трактуватись з іншим сенсом.

Висновки

Отже, Checklist-Based Testing — це техніка, що допомагає покращити та масштабувати процес тестування. Вона вимагає від QA хорошого розуміння продукту, ключового функціоналу, типових багів і потенційних ризиків. Такий підхід допомагає сфокусуватись на важливому, зменшити кількість пропущених перевірок і систематизувати накопичений досвід щодо продукту.

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

Щоб зрозуміти, чи підходить Checklist-based testing саме для вашого проєкту, спробуйте застосувати його на практиці, а потім проаналізуйте результати. Почати можна з одного модуля — як це було у моєму випадку.

Чи був у вас досвід використання цієї техніки тест-дизайну? Буду рада почути ваш фідбек про неї у коментарях.