Без нудної теорії. Як QA-спеціалісту написати тестову документацію

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

Цей матеріал допоможе вам правильно підійти до створення тестової документації та написати її справді грамотно й швидко.

Тестова документація — що це?

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

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

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

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

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

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

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

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

Я поділяю процес тестування та розробки на дві фази: construction та stabilization. На першій фазі необхідне функціональне тестування. Сам по собі це окремий вид тестування. Але я включаю в це поняття всі типи тестів, необхідних на цьому етапі: нефункціональні, юзабіліті, компатібіліті, інтеграційні.

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

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

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

У будь-якому разі треба врахувати роль команди (аутстаф чи аутсорс) і хто є контактною особою. Якщо Product Owner має лише загальне уявлення про тестування, детальна розповідь про стратегію та документацію недоречна.

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

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

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

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

Що стосується написання документації — розпочинає лід. Далі можна й потрібно розподіляти завдання у команді. Наприклад, я як тест-лід створюю тест-план. Він описує, на яких девайсах ми працюватимемо, які етапи будуть, що на кожному з них робимо, як влаштоване тестування, коли починати працювати зі сторі, а коли — закінчувати. Також я визначаю, який рівень якості ми гарантуємо. Це насамперед вимагає Product Owner, і цей вид документації може створюватися разом із проєктним менеджером. Головна мета — пояснити, що відбуватиметься у QA-команді під час спринтів і релізів та затвердити перелік тасків.

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

Визначаємо обсяг тестової документації

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

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

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

Як описувати тест-кейси

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

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

У тест-кейсах куди важливіше дата-сетап. Саме він дозволяє майже всім пройти необхідні перевірки. Деталізація документа може відрізнятися. Наприклад, якщо артефакт призначений для новачка, тоді документація має бути детальна: тут налаштував, зберіг і перевірив, а тут — натиснув; є такий-то Expected, і якщо він не збігається, то заводь дефект. Фактично це манкі-тестінг, який нерідко зустрічається на великих ентерпрайз-проєктах. До цих кроків я би ще додав посилання на баг у регресійних тестах. Завдяки цьому новий QА зможе швидко ознайомитися з історією проходження тестів і зрозуміти, на що варто звертати увагу.

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

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

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

При написанні баг-репортів пам’ятайте…

Аналогічний підхід діє і під час створення баг-репортів. На проєкті має бути шаблон опису дефекту. Це дозволить уникнути розбіжностей і систематизує роботу команди. 

Не ускладнюйте баг-репорт. Зосередьтесь на якісному саммері. Для розуміння проблеми вашим колегам вистачить текстового опису. Пропишіть виконані вами кроки, інвайромент, Expected та Actual. Також раджу додати скріншот або зробити на екрані відеозахоплення івенту. Інколи картинка вартує тисячі слів.

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

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

Продумайте структуру саммері. Побудуйте план за принципом: що, де і коли. Важливим є саме такий порядок.

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

Чек-листи потрібні не завжди

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

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

Коли чек-листи обов’язкові?

Наприклад, коли вони допоможуть контролювати роботу тестувальника з боку Product Owner’а. Документ підтвердить, що саме цей порядок дій коректний. Припутимо, тестувальник розібрав із лідом сторі і хоче переконатися, що нічого не забув. Особливо це важливо на великих проєктах, де чек-лист виступає додатковим елементом звітності. В інших ситуаціях досвідченим QA достатньо тест-кейсів і шаблону баг-репорту, який заповнюється в залежності від ситуації.

Написання тест-кейсів складніше за створення чек-листів. Кейси треба продумати, вони можуть мати безліч розгалужень, і кожну з них треба описати. По суті це перетворюється на формування тест-дизайну. Чек-лист же, на мою думку, виглядає як проста Traceability-матриця. З одного боку, є умови, з іншого — перевірки. Сама по собі матриця стає об’ємною, якщо потрібно перевірити безліч варіацій.

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

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

Актуалізуємо тестову документацію

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

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

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

Замало написати гарну тестову документацію. Потрібно підтримувати її

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

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