Тест-документація: як писати, який її необхідний мінімум і що може статися на проєкті без неї

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

Привіт! Мене звати Олеся Пасєка, я працюю Manual QA Engineer у Svitla Systems (і ні, бабусю, я не той інженер, хто полагодить тобі телевізор). У цій статті маю намір поділитись важливістю створення тестової документації та наслідками її нехтування.

«Писаного сокирою не вирубаєш» — ще в давнину наші предки усвідомлювали важливість створення тестової документації. Уявіть: сивий Нестор схилився над своєю «Повістю...» й думає про себе: «Ай, нащо мені про те хрещення Русі згадувати, — інший літописець зробить». З таким підходом наша держава позбулася б кількох століть ключової історії, принісши, м’яко кажучи, немало хаосу в поточний суспільний устрій.

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

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

Використовуючи мову термінів, тестова документація — це набір артефактів, створених або перед початком, або/ і в процесі тестування (ISO/IEC 29119). Це допомагає QA-команді оцінити необхідні зусилля, тест-покриття, відстежити витрачені ресурси (час, обладнання, кількість залучених спеціалістів), прогрес виконання тощо. Документація дозволяє описати усі тест-активності: планування, дизайн, виконання та отримані результати.

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

Найпоширеніші тестові артефакти

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

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

• Виконувана дія (Action) — Очікуваний результат (Expected result).

Крім цього, тест-кейс може містити й додаткову інформацію, реалізовану у вигляді наступних атрибутів:

• Прекондишнс (Preconditions) — передумов: містять важливу інформацію та кроки, необхідні для попередньої підготовки операційної системи, тестового застосунку, мобільного пристрою, браузера тощо. Виконання цих умов завжди передує проходженню тест-кейса. Якщо вимоги, зазначені в передумовах, не виконані, тест-кейс буде неможливо відтворити по зазначених кроках, або ж результати тестування будуть спотворені.
• Дескрипшн (Description) — опису: лаконічно відповідає на питання «Навіщо нам цей кейс, яка його мета?»
• Тест-дати (Test Data) — тестових даних: інпут, що задовольняє вимоги прекондишнс, наприклад: 100 згенерованих записів у базі даних, набір юзерів з різними рівнями доступу до системи, текст, який має понад 300 символів тощо.
• Скриншотів (Screenshots): візуальна репрезентація тестових атрибутів.
• Посткондишнс (Postconditions) — постумов: зміни, які повинні бути внесені в систему після виконання воркфлоу тест-кейса — це може передбачати видалення тестових даних з бази, скидання налаштувань профілю до дефолтних тощо.

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

Scenario #1: Successful Log in to the website
Given user brings up the login pop-up
When user clicks Sign-in
And user enters a valid email and password
And user clicks Sign-in
Then user should be successfully logged into the site

Хорошою практикою вважається створювати тест-кейси паралельно з розробкою, щоб як тільки задача мігрує в ‘Ready For Test’, QA зміг братися до роботи. До того ж розробники заздалегідь можуть бачити тестові випадки, які повинні бути враховані на стадії девелопменту.

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

Взірцевий репорт складається з наступних елементів:

1. Title.
2. Environment.
3. Steps to Reproduce.
4. Actual + Expected Result.
5. Screenshots/Logs.
6. Severity + Priority.

Заголовок баг-репорту повинен бути інформативним або ж, хочеться використати англіцизм, — self-descriptive. Перераховані кроки повинні дозволяти точно відтворити проблему, а фактичний результат вичерпно описувати поточну поведінку функціонала. Також бажано, щоб на скриншоті був не лише UI, а й фрагмент консолі/ нетворку — це відчутно спростить життя дев-команді.

Якщо баг критичний — не забудьте одразу поділитись ним в чаті з припискою «АЛЯЯЯЯРМ!».

Чеклісти — перелік завдань на визначений термін, що потребують відмітки про виконання. Вони організовані дуже просто: складаються з переліку блоків, сторінок, які слід протестувати. Пункти повинні бути максимально короткими, однозначними та водночас зрозумілими тестувальникам, які ще, можливо, не знайомі із застосунком.

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

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

Матриця відповідності вимог — таблиця, що містить відповідність функціональних вимог продукту та підготовлених тестових сценаріїв. Буває трьох типів: Forward, Backward і

Bi-Directional Traceability.

Таблиця має наступну структуру: Business Requirement #, Test Scenario #, Test Case #, Defects #.

Матриця відповідності вимог дозволяє візуалізувати покриття продукту тестами та відшукати «дірки» в нашому test coverage.

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

Таблиця/ діаграма переходу системи (State Transition): показує, до якого стану (станів) перейде система на основі різних комбінацій вхідних даних.

Тестова стратегія — це документ високого рівня, який містить вказівки та принципи, пов’язані з проведенням процесу тестування.

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

За рівнем конкретизації завдань, тест-плани поділяються на

Master Test Plan i Product Acceptance Plan (набір дій, пов’язаних з Acceptance Testing). За посиланням нижче можна ознайомитись зі зразком вищезгаданого документа: Test Plan Template (based on ISO/IEC/IEEE 29119).

В чому полягає різниця між тест-планом і тестовою стратегією?

Який мінімум тестової документації очікується на проєкті

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

Коли ми визначаємо кількість тест-артефактів, необхідних нашому проєкту, потрібно орієнтуватись на наступне:

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

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

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