Тест-кейси: що, як, навіщо

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

Привіт всім! Мене звати Максим Бодня, я Lead QA у компанії Customertimes, маю 6+ років досвіду у Quality Assurance. Працював з маленькими та великими проєктами / компаніями, а також у стартапах, тож радий поділитися досвідом, який отримав на своєму QA-шляху!

Сьогодні я розповім про тест-кейси і те, як з ними працювати. Щиро вірю, що мої поради комусь допоможуть налагодити процес тестування, а комусь — взагалі почати писати тест-кейси. У статті не буде чогось ультрамодного на кшталт історії про те, як «ШІ допоможе нам і врятує світ». Цей текст більше про рутинну роботу та про те, як покращити та оптимізувати її.

Трохи, як то кажуть, бази

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

З чого він складається? Усе просто та складно водночас:

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

Для цього пропоную використовувати спеціальні програми: TestomatIO, TestRail, Zephyr, Xray. І, звісно, я розумію, що вони не є безкоштовними. Тож раджу дізнатись, чи є щось схоже у вашої компанії або замовника, з яким ви працюєте. Якщо ні — то Excel, Confluence або якийсь текстовий редактор нас також влаштує, тож не переймайтесь!

Чому потрібно вести тест-кейси та де їх зберігати

Завжди мріяв це написати: тест-кейси — це правильно. Це надзвичайно важливий крок в роботі з тестовою документацією. А ще вони:

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

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

Якщо ж ви людина-perfect-тайм-менеджмент, або, наприклад, у вас небагато роботи, або ж ваші задачі ще не сформовані — це найкращий момент, щоб привести все до ладу та розробити тест-кейси.

У мене є багато прикладів, як мої знайомі на питання «Чи пишете ви тест-кейси?» відповідали: «Та ні, в нас не вимагають». А потім за іронією долі в їхньому житті наставала ситуація «Тест-кейси потрібні asap! Це горить!» — тож, звісно, тест-кейси розроблялись абияк і в гарячці. Тож я пропоную подбати про це завчасно.

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

А тепер уявіть: проєкту приблизно 10 років, його система дуже комплексна, в ній автоматизовано десь 6000 тест-кейсів (регресія: 1500 тест-кейсів) та багато з них описані тільки назвою.

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

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

З чого почати створення тест-кейсу

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

Назва

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

Звернемось до кількох прикладів:

Опис «Упевнись, що в документа змінюється статус з „У процесі“ на статус „На перевірці“» краще замінити на такий: «Перевірити, що публікація змінює статус „У процесі“ на статус „На перевірці“, коли користувач починає процес перевірки чернетки».

Зауважте, тут ми вказали, який саме документ ми перевіряємо та яку дію виконуємо.

Чи ще приклад:

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

Передумови

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

Так, наприклад:

• у користувача повинні бути права на створення документа. Ще бажано написати, як саме надати ці права, наприклад: Налаштування → Користувачі → Права на створення документа;

• публікація має бути в статусі (в процесі) або ж має бути вказаний весь перелік того, що потрібно зробити. Наприклад: Створити документ з типом «Публікація» → Заповнити поля → Натиснути кнопку «Почати роботу з документом».

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

• непотрібно розписувати багато передумов (скорочує час на написання кейсів);
• кейси йдуть послідовно.

З мінусів:

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

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

Обирати саме вам!

Кроки (мабуть, найскладніше)

Деякі тестувальники описують все, що роблять, окремими кроками. Виходить дуже довго, тож підтримувати такі кейси — та ще робота. А тепер уявіть, що хтось прописує кожний крок та навіть більше. І навіть випадок переведення миші в інший кут — це окремий крок в тест-кейсі. Будь-який продукт — це складний та комплексний світ, тож просто уявіть цей обсяг кроків та наскільки об’ємним виходить такий тест-кейс.

Але є й інші випадки: коли все описується ну ду-у-уже поверхово.

Приклад з мого особистого досвіду:

Хтось з менеджерів сказав, що ми витрачаємо багато часу на написання тест-кейсів. І він нещодавно прочитав статтю про те, що якась компанія (на жаль, не згадаю назву) робить ось такі поверхові кейси та живе собі щасливо! Так-от, запровадивши це, я усвідомив, що так ми ніколи ще не помилялись!

Задумка була така: оптимізувати затрати часу на написання та проходження тест-кейсу. А також писати все в описі. Виходив дуже довгий опис, але водночас нам не потрібно було відкривати тест-кейс. Звісно, на початку це допомогло писати тест-кейси швидше та проходити їх оперативніше. Але колеги з нашої команди були залучені й на інших проєктах, а регресія відбувалася, звісно, не кожен день, отже частина з тих кейсів просто забувалась!

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

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

Звернемось до більш практичних прикладів:

Як не треба робити: Крок 1 — меню, що випадає. Крок 2 — документи. Крок 3 — публікації. Крок 4 — документ.

Краще описати так: Крок 1 — меню, що випадає → Документи → Публікації → Документ 1.

Якщо у вас не фінальний дизайн і може бути багато змін, то спробуйте мінімізувати прив’язку до назв. Наприклад, замість того, щоб написати «Натиснути кнопку „Старт“», напишіть «Натиснути кнопку для початку роботи».

Очікуваний результат

Потрібно чітко описати, чого ви очікуєте, наприклад, наприкінці цього кроку. Поради: Один крок = один результат. Можете додати картинку, анімацію або відео — це допоможе зрозуміти іншим колегам, чого ж їм очікувати, щоб не було, як в тому мемі «сурпрайз-сурпрайз!».

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

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

Крок 1 — Натиснути кнопку «Створення документа».
Крок 2 — Обрати тип документа 1/2/3/4 чи 5.
Крок 3 — Заповнити поля.
Крок 4 — Створити документ.
Крок 5 — Відкрити меню.
Крок 6 — Виконати дію «1, 2, 3, 4, 5» (Наприклад: «Розпочати перевірку»).
Крок 7 — Впевнитись, що статус документа змінився.

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

Або прописати все окремими кейсами. Все залежить від проєкту, правил та домовленості в команді — обирати вам:

Документ 1 статус 1.
Документ 1 статус 2 і так далі.
Документ 2 статус 1 і так далі.

Якщо вже говорити про сам формат, то спочатку в нас був стандартний за формою в TestRail:

Кроки
Крок 1
Крок 2
Крок 3

Очікуваний результат
Результат 1
Результат 2
Результат 3

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

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

Трохи порад. Dos and don’ts

Не робіть звалище кейсів

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

Домовтесь про теги:

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

Звернемось до кількох прикладів:

У нас була задача на додавання нового типу документа та прав користувачам для роботи із цим типом документів. Користувачу можна було дати такі права: створення, редагування, видалення. У чому ж була проблема? Я написав тест-кейси та додав негативних тегів. Потім я спробував редагувати або видалити документ, не надавши права користувачу.

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

Team spirit

Дуже важливо залучати якомога більше людей до процесу розробки тест-кейсів. Раджу зробити певні сесії для обговорення, бо, по-перше, у суперечці народжується істина. А по-друге, це буде для вас своєрідним нестандартним тімбілдингом! Жартую, звісно, але щось у цьому є.

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

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

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

Підтримка кейсів

Тест-кейси потрібно оновлювати та прибирати їх, якщо вони неактуальні, та, звісно, додавати нові. Гарна практика — проводити сесії з перевірки кейсів. Одна сесія проходитиме у форматі написання нових тест-кейсів, в якій команда буде передивлятись створені кейси та додавати ідеї та зауваження. Інша сесія може проходити раз на пів року, і під час неї ви можете передивлятись кейси та формувати список того, що потрібно оновити або взагалі перенести в архів.

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

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

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

Замість висновку

Якщо ви знайшли баг, то одразу за цими кроками створіть тест-кейс та додайте його у ваші списки.

Не забувайте про тест-кейси від початку до кінця (End2End).

У чому їхня користь?

1. Вони стануть у пригоді, коли вам потрібно перевірити білд і чи придатний він для початку тестування.
2. Вони допомагають на демонстрації функціональності.
3. Разом з ними можна автоматизувати продукт та основні функції. А це може скоротити витрати часу на автоматизацію.
4. А якщо їх автоматизувати та запускати перед мануальним тестуванням, то це ще й скорочує час мануального тестування для перевірки білда.

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

На одному з дзвінків я запропонував написати E2E-кейси для автоматизації, вирішили спробувати цю ідею. Я написав кейси на декілька модулів, показав менеджменту та команді автоматизаторів — цей підхід усім сподобався. Потім ми залучили більше тестувальників і всі основні модулі описали E2E-кейсами. Коли їх покрили автотестами, ми додали їх як quality gate для перевірки білда й отримали автоматизовану перевірку та економію часу.

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