Навіщо і як QA писати тестову документацію. Структуруємо та робимо її зрозумілою
Усім привіт. Мене звати Дмитро Кравчук, я QA Engineer у продуктовій компанії iDeals. Часто тестування вважають одним із «входів» в IT-професію. Почасти це правда, але цей напрям потребує не менш системного та методичного підходу, ніж, скажімо, розробка.
Тому вирішив зібрати та систематизувати інформацію щодо створення тестової документації та поділитися нею з вами. Це має стати в пригоді як QA-початківцям, так і більш досвідченим колегам, які прагнуть впорядкувати свою роботу чи функціонування команди.
Ілюстрація зроблена за допомогою Awesomic
Що ми можемо зарахувати до тестової документації? Зазвичай називають таке:
- тест-план;
- чек-лист;
- тест-кейс;
- баг-репорт;
- матриця покриття вимог (traceability matrix).
Хоч це і внутрішня документація, її користувачі — теж люди, які прагнуть працювати зі зрозумілою інформацією. Єдиний підхід до оформлення, поєднаний із турботою про потенційного читача, спрощує роботу всієї команди.
Бували ситуації, коли некоректне розуміння тест-кейсів призводило до пропущених багів і, як наслідок, невдоволення клієнтів. Тож розгляньмо, як варто оформлювати кожен із цих документів так, що вони були надійними, структурованими та, що не менш важливо, user-friendly.
Тест-план
Test plan — це документ, що описує весь обсяг робіт з тестування та необхідних для цього ресурсів. Може містити такі елементи:
- вступна частина (інформація щодо проєкту, його цілей тощо);
- підходи до тестування;
- перелік завдань і цілей, що мають бути досягнені;
- фічі, які тестуватимуть (іноді фічі, що не будуть тестувати);
- команда, що тестуватиме;
- оцінка часових витрат команди;
- графік роботи;
- середовище для тестування (перелік браузерів, операційна система);
- визначення критеріїв зробленого (Definition of done);
- оцінення ризиків із варіантами їхнього уникнення;
- посилання на інші документи, тікети тощо.
Зазвичай підготовкою тест-плану займався найдосвідченіший на проєкті QA, який відсилав його на погодження QA-менеджеру. В нас був уже готовий шаблон, який корегували та доповнювали відповідно до нового проєкту. Та з переходом на Scrum потреба в схожому документі — через скорочення паперової роботи — значно знизилася.
Чек-лист
Сhecklist — список сценаріїв для тестування, згрупований за модулями.
Спочатку QA створює чек-лист в TestRail чи Google-таблицях, а потім розширює його до детальних тест-кейсів. Викреслюючи пункти списку, команда (або й один тестувальник) може краще розуміти поточний стан виконаної роботи та якість продукту. Коли працюєте над проєктом за чек-листом, можете значно зменшити потребу повторної перевірки за тими ж кейсам.
Крім того, поліпшується якість тестування, оскільки ризик залишити без уваги якийсь функціонал суттєво знижується. Тому це напрочуд корисний інструмент, особливо для командної роботи.
Чек-лист — досить простий документ. Як його варто оформити?
- Додайте повний перелік модулів, сторінок, секцій чи інших елементів, що мають бути протестовані.
- Пункти можуть мати як лінійну структуру, так і деревоподібну (можете для цього використовувати XMind), мати розділи та підрозділи.
- Формулювати варто лаконічно, але водночас зрозуміло іншим тестувальникам.
- Робіть формулювання однозначними, щоб унеможливити некоректне трактування. Наприклад, «перейти в документи» — звучить неоднозначно, бо може означати як частину програми, так і завантажені файли. Краще писати «перейти в модель «Документи».
- Використовуйте скрізь одну мову.
Тест-кейс
Test Case — це сукупність певних передумов і кроків, необхідних для перевірки реалізації функції, яку тестують, чи її частини. Написанню тест-кейсів бажано виділяти достатньо часу, адже заздалегідь підготовлене тестове покриття — це запорука того, що воно буде максимально повним і всі функціональні ділянки будуть покриті тестами.
Важливим також є те, як написані тест-кейси. Напрацювання спільних правил створення тестової документації у нас забрало чимало часу. Але побудова єдиної системи того варта. Отже, до чого ми дійшли?
Наприклад, визначали, як називати тест-кейси. Ми зупинилися на тому, що назва має складатися з таких блоків:
- Де? (Який модуль продукту перевіряють)
- Що? (Яку дію перевіряють)
- Яке налаштування? (Опціонально, при наявності)
Наприклад: «Users. Invite. With group creation» чи «Documents. Download. Original file». Назва має бути короткою, але водночас максимально інформативною.
За потреби в назві тест-кейсу можна додавати змінні, які варіюються, у квадратних дужках (різні види файлів, типи користувачів тощо).
Наприклад:
- Documents. Download. Original file [docx]
- Documents. Download. Original file [xlsx]
- Documents. Download. Original file [pptx]
Крім того, ми також створили окремі правила для описання кроків тест-кейсів:
- Кожен крок має бути лаконічним і починатися з дієслова в початковій формі (відповідати на питання «що зробити?» — «натиснути», «скопіювати», «перенести»).
- Не треба робити посилання на інші кроки цього тест-кейсу (типу «зберегти зміни й перейти знову до кроку 4»). Адже тест-кейси можна редагувати, копіювати, і потенційно такі посилання ще більше заплутують.
- Окремі елементи інтерфейсу та об’єкти краще писати з великої літери та брати в <> (наприклад, кнопка — ми обрали у своїй команді таке оформлення, щоб краще структурувати текст).
- Кожен крок має описувати одну дію (бажано уникати «вкладеності» кількох кроків в один — надалі це сприяє автоматизації тестів).
- Очікуваний результат обов’язково має бути для останнього кроку та опціонально для попередніх.
Щодо опису передумов тест-кейсу (Preconditions). Це інформація щодо того, що за необхідності потрібно виконати до першого кроку тестування. Це можуть різні додаткові налаштування, запрошені користувачі, додані файли чи папки, увімкнені певні опції, що відрізняються від стандартних.
Інформацію в передумовах тест-кейсу краще подавати у вигляді таблички, візуально це буде краще сприйматися.
Баг-репорт
Bug report — це технічний документ, який містить повний опис багу з інформацією як про саму помилку (короткий опис, серйозність, пріоритет тощо), так і про умови її виникнення. Баг-репорт має містити правильну єдину термінологію, що описує елементи призначеного для користувача інтерфейсу і події, що спричиняють баг.
Складники баг-репорту:
- короткий опис проблеми;
- назва проєкту;
- компонент додатка, в якому виник дефект;
- версія білду, в якому знайдено баг;
- серйозність (градація ступеня впливу на додаток);
- пріоритет (черга виправлення помилки);
- статус (помилки в життєвому циклі);
- автор (хто створив баг-репорт);
- призначення (хто повинен виправити дефект).
Сам опис багу може містити такі частини:
- передумови (опціонально);
- кроки відтворення (опис шляху, який призводить до виникнення дефекту);
- фактичний результат (результат, до якого приходимо, коли виконаємо всі кроки);
- очікуваний результат (результат, який мав бути відповідно до вимог).
Напрочуд корисно додавати до документа скриншоти, тестові файли або інші документи, що допоможуть програмістам розв’язати проблему.
Бажано відразу описувати баг детально, коректно та зрозуміло, щоб розробникам доводилося менше ставити уточнювальних питань чи взагалі ставити тікету статус Can’t reproduce. В Jira є можливість налаштувати потрібні поля та додати певні шаблони, що може трохи полегшити вам створення нових баг-репортів.
Матриця покриття вимог
Traceability matrix — подвійна таблиця, що перевіряє відповідність функціональних вимог продукту (functional requirements) і підготовленим тест-кейсам. На перетині відповідних рядка та стовпця ставиться відмітка, яка позначає, що ця вимога покривається тест-кейсом.
Таким чином цей інструмент дає візуальне зображення таких параметрів:
- наявність у системі ще не покритих тест-кейсами вимог (якщо у вимог немає жодного перетину з тест-кейсами);
- надлишкове тестування — якщо вимога має кілька перетинів з тест-кейсами.
Що має містити матриця покриття вимог? У кожному рядку має бути:
- номер та опис задачі з таск-трекера;
- модуль, до якого належить задача (опціонально);
- приймальний критерій (Acceptance criteria);
- пріоритет;
- номер та опис відповідного тест-кейсу.
Матриця коректно виконує свою роль лише за умови її постійної актуалізації. Інакше вона не тільки стає марною, а й може заплутувати тестувальників.
Висновок
Документація — лише один з інструментів співпраці! Вищеперелічені приклади тестової документації спеціалісти сприймають по-різному. Тому корисно регулярно збиратися командами та випрацьовувати спільне бачення, власні стандарти та підходи. У довгостроковій перспективі це заощадить купу часу та підвищить якість вашої роботи.
Щоби не пропустити нові статті Дмитра Кравчука — підписуйтеся на нього у телеграм-боті Стрічки DOU.
