Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 5
×

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

Усі статті, обговорення, новини про тестування — в одному місці. Підписуйтеся на 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 PlanProduct Acceptance Plan (набір дій, пов’язаних з Acceptance Testing). За посиланням нижче можна ознайомитись зі зразком вищезгаданого документа: Test Plan Template (based on ISO/IEC/IEEE 29119).

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

Атрибут

Тестова стратегія

Тест-план

Ціль

Визначити загальні принципи, яких слід дотримуватися під час процесу тестування.

Визначити, як тестувати, що тестувати, коли і хто тестуватиме.

Мета

План процесу тестування на довгостроковій основі.

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

Повторюваність

Може використовуватись багатьма проєктами.

Використовується лише одним проєктом.

Можливість внесення змін

Статичний документ.

Гнучкий документ.

Компоненти

Обсяг, цілі, формат документації, тестові процеси, репортинг тощо.

ID, перелік того, що тестувати, тест-техніки, Pass/Fail критерії, результати тестування, розклад тощо.

Існування

Може бути частиною тест-плану.

Існує окремо.

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

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

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

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

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

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

👍ПодобаєтьсяСподобалось29
До обраногоВ обраному12
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Дуже непогана стаття. Приємне та корисне чтиво (:

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

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

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

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

Привіт, а чому тестова стратегія не передбачає можливості внесення змін? Ми вносимо :)

Привіт!
Саме в контексті порівняння стратегії й плану — перша менш гнучка, але це, звісно, не виключає можливості її редагування :) Дуже круто, що у вас є тест-стратегія!

Дякую, що читаєте :)

Хорошою практикою вважається створювати тест-кейси паралельно з розробкою

Найн. ДО початку розробки

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

Привіт, певні приклади є у книжечці нижче (або в самому силабусі). Але це все вам мабуть відомо...
А ось щодо підтримки, коли багато змін- «не плач, не псіхуй...»

розділ блек бокс тест технік (4.2.3) «Foundations of Software Testing ISTQB Certification, 4th edition by Dorothy Graham, Erik van Veenendaal, Rex Black».

Дякую за зворотній зв’язок!

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

Дякую, за підсумоване до купи QA буття) не раз приходив на проект де з тестовою документацію повний 0. Тест-план — лише один раз бачив його, і то писав сам, оскільки була така вимога замовника. Тестова стратегія — документ про який питають на співбесідах, але ніхто не бачив його в очі :)) (можливо хтось бачив, відізвіться) Загалом погоджуюсь, що іноді недалекі люди чи замовники не розуміють взагалі для чого тестування і документація. Але це плюс для нас — адже через півроку активної розробки терміново з’являється ПАЛАЮЧА вакансія QA на проекті))

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

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

Тестова стратегія — документ про який питають на співбесідах, але ніхто не бачив його в очі :)) (можливо хтось бачив, відізвіться)

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

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

О да, до сих пор помню как готовила 20 тест комплишен репортов как результат одного регрешен прогона xD

Підписатись на коментарі