Чому деякі тест-сьюіти стають поганими, або Способи покращення тестової документації

Привіт, мене звати Володимир, я тестувальник компанії DevelopEx, з 2017 року працюю на кросплатформному (десктоп + мобайл) проекті, що розробляється на фреймворці Qt. Типовий стек задач тестувальників на проекті: ручна перевірка фіч, ведення тестової документації, регресійне тестування, автоматизація перевірки тестових сценаріїв.

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

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

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

Щоб було цікавіше, за тестований функціонал візьмемо абстрактну web-форму реєстрації нового користувача. А найбільш стійких в кінці тексту чекає історія з життя. :)

Неактуальні тести

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

Наприклад, розглянемо такий тест-кейс реєстрації нового користувача:

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

Причини виникнення:

• Еволюційне оновлення user stories, котрі непрямо пов’язані з тест-сьюітом.

Способи покращення:

• Під час оновлення тест-сьюіта переглядати його повністю (а не тільки в місцях змін);
• Доручати оновлення складних тестових сценаріїв досвідченим членам команди;
• Менш деталізувати тест-кейси для випадків, прямо не передбачених в прямій user story.

Копіювання документації

Інколи в тест-райтера (тестувальника, який створює тестовий документ) виникає спокуса скопіювати шматок документації в якості тест-кейсу. Оскільки документація може не оперувати конкретними значеннями, підбір значень для тесту і розрахунок результату перекладено на тест-ранера. Звісно, тест-ранер все виконає, але часу буде витрачено набагато більше. Адже: потрібно розібратись в документації, детально ознайомитись з тим, як суміжні фічі впливають на тестовану фічу, і самостійно розрахувати очікуваний результат. Що не завжди швидко.

Наприклад, є такі витяги з документації:

Документ 1:

WHEN Бекенд шифрує дані
THEN Бекенд використовує алгоритм AES-128-ECB з ключем mysupersecretkey

Документ 2:

GIVEN Введені валідні дані в поля форми реєстрації
WHEN Користувач натискає кнопку “Register”
THEN Клієнт пересилає введені дані на сервер
AND Бекенд шифрує пароль та зберігає його в базі даних

Якщо тест-кейс буде приблизно таким:

то добросовісному тест-ранеру не лишатиметься іншого, як самотужки з’ясовувати, чи справді пароль зашифровано правильно.

Щоб регресійне тестування було виконане якісніше і швидше, цей тест-кейс можна переписати так:

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

Причини виникнення:

• Бажання або потреба швидко створити тестовий сценарій;
• Нерозуміння документації.

Способи покращення:

• Не копіювати документацію :)
• Розібратись в документації досконально (або запропонувати бізнес-аналітику уточнити її);
• Виписувати тестовий сценарій паралельно з проходженням тесту.

Відсутність негативних сценаріїв

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

Причини виникнення:

• Загальна (поверхнева) User Story;
• Велика User Story;
• Нестача часу.

Способи покращення:

• Самостійно поглибити свою експертизу в доменній області;
• Розбити один тестовий документ на кілька;
• Ставити себе на місце користувача;
• Писати дуже великий тест-сьюіт. А що поробиш?

Неоднозначна інтерпретація результату

Інколи тест-кейси містять таку послідовність кроків та результатів, з яких неясно, який саме результат має бути в певний момент проходження. Наприклад, маємо такий тест-кейс:

Можливо, результати 1-3 мають бути отримані після проходження всіх кроків. А можливо, що результат (1) має виникати після кроку (1), якщо реалізована динамічна перевірка введеної інформації.

Причини виникнення:

• Бажання візуально зменшити кількість сценаріїв;
• Припущення, що результати очевидні з кроків.

Способи покращення:

• Розбивати складні тестові сценарії на прості;
• Перегляд тест-кейсів іншими членами команди.

Неточні тести

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

Наприклад:

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

Причини виникнення:

• Виписування сценарію «по пам’яті»;
• Неуважність, втомленість;
• Неглибоке знання продукту;
• Неоднозначність документації.

Способи покращення:

• Прогнати тест-кейс самому;
• Рев’ю теста колегою.

Надлишкові перевірки

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

Причини виникнення:

• Бажання перевірити фічу якнайкраще;
• Документування exploratory перевірок «як є»;
• Переоцінювання вартості гіпотетичних багів.

Способи покращення:

• Продумувати послідовність тест-кейсів у тест-сьюіті;
• Оминати детальну перевірку непрямих вимог;
• Застосовувати відомі техніки тест дизайну.

Надмірно деталізоване інтеграційне тестування

Під «інтеграційним тестуванням» тут я маю на увазі перевірку взаємодії двох або більше компонентів (фіч) тестованого ПЗ. Часто дефекти зосереджуються саме в місцях взаємодії фіч. Природне бажання тестувальника — зосередити перевірки на таких взаємодіях.

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

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

Наприклад, замінити тест-кейс:

На тестовий сценарій високого рівня:

• Перевірити, що дані користувача після їх оновлення в «Особистому кабінеті» оновлюються на всіх релевантних сторінках.

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

Причини виникнення:

• Детально прописані інтеграційні перевірки фіч.

Способи покращення:

• Замінювати детальні інструкції тестовими сценаріями високого рівня або чек-лістами.

Резюме

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

1. Актуальні,
2. Унікальні (не copy-paste з документації),
3. З негативними сценаріями (навіть якщо тест-сьюіт вже великий),
4. З однозначними причинно-наслідковими зв’язками (відповідність кроків і їх результатів),
5. Точні (як написано, так і буде зроблено),
6. Оптимальні з точки зору послідовності виконання,
7. Без детальних інтеграційних перевірок.

Вийшло якраз сім критеріїв, прямо містика.

Впевнений, що кожен з читачів може доповнити цей перелік власними характеристиками якості (або не-якості) тестової документації, взятих не з книжок, а з досвіду.

Історія з життя

Колеги, які переглядали цей текст перед передачею його в редакцію Dou, сказали: «Було б непогано додати якихось анекдотів чи історій з життя». Що ж, тримайте одну.

Оскільки продукти в рамках нашого проекту кросплатформні, їх UI та UX дуже близький. Однак є дисбаланс: в команді (і з боку замовника, і з боку розробника) — майже всі користувачі Windows. Відповідно, документацію прописуємо і узгоджуємо, спираючись на UX для Windows (за виключенням моментів, коли macOS використовує явно інші підходи в UX/UI).

Рік тому ми зарелізили продукт для Windows (через сайт замовника) та macOS (через App Store). Як і належить, релізу передувала регресія, баг-фікси, повторні перевірки...

Лише нещодавно було виявлено, що користувачі macOS весь цей час так просто не могли взяти і розшарити створені програмою файли. Тому що в програмі, яку завантажують на App Store, активована т.зв. «пісочниця» — sandbox. Програма зберігає файли, якими оперує користувач, в пісочниці. Яка, в свою чергу, знаходиться в глибинах прихованого каталогу ~/Library.

Під час розробки ми працювали без sandbox. Тому, в контексті збереження файлів, програма на macOS працювала, як і на Windows: з каталогом ~/Documents. Формально багу на macOS не було, фактично ж вийшло некрасиво.

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

Бажаю якісної тестової документації та безбажних продуктів на проді :)

Підписуйтеся на Telegram-канал «DOU #tech», щоб не пропустити нові технічні статті