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

Під тест-кейсом розуміють структуру такого вигляду:

Action > Expected Result > Test Result

(Дія > Очікуваний результат > Фактичний результат)

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

1. Номер — унікальний ідентифікатор тест-кейса. Його зручно використовувати для чіткого розуміння, про яку перевірку йдеться (наприклад, дати посилання на цей тест-кейс в описі бага)

2. Назва — короткий опис суті перевірки. Має вміщатися в твіт і бути зрозумілою! Стисло, але ємно. Тут головне не захопитися стислістю: про що йдеться, має бути зрозуміло всім, а не лише вам.

3. Попередні кроки (PreConditions) — опис дій, які необхідно виконати, але які не мають прямого стосунку до перевірки (наприклад, зареєструватися в системі для перевірки створення елемента). Якщо попередніх кроків немає, цей розділ не заповнюється

4. Кроки — опис дій, необхідних для перевірки (наприклад, створення елемента)

5. Пост-кроки (PostConditions) — перелік дій, що повертають систему в початковий стан (стан до проведення тесту — initial state)

6. Очікуваний результат (Expected result) — сама перевірка: що ми очікуємо отримати після виконання кроків ("Елемент створено")

7. Результат тесту (Test Result) — passed/failed/blocked

8. Пріоритет тест-кейса (Test Case Priority) — це важливість тест-кейса. Важливість проставляють у вигляді числа від 1 до N або пріоритетів: minor, major, critical; є ще блокер (blocker), але він рідко застосовується до тест-кейса

PreConditions

Test Case Description

PostConditions

delete this user

PreConditions

Test Case Description

PostConditions

delete this user

У цьому прикладі під час проходження тест-кейса тестувальник не зумів виконати крок А2, і внаслідок цього система не перейшла в стан, придатний для тестування. У такому разі він заводить баг зі статусом "blocker" і проставляє всі подальші статуси як заблоковані — "blocked". Проходження такого тест-кейса відновиться лише після виправлення цієї помилки. Якщо виявлено баг, який не блокує подальші кроки, тест-кейс завжди проходять до кінця.

Перевірка відображення сторінки

Добрий день.

Коротке оновлення статусу тестування фічі backgroundperpage.

Цикл автоматизованого тестування:

Автоматизоване тестування реліз-кандидата 2.983.0 та фічі backgroundperpage — Pass QA.

Проте виникли проблеми з тестами для порівняння скриншотів GUI (впало 116 тестів). Причина падіння тестів — поява горизонтального scroll bar (прокручування). Скрол не з'являється, коли сайт відкривають уручну, тому було зроблено висновок, що баг в автотесті. Посилання на таблицю з результатами аналізу автотестів.

Цикл ручного тестування:

Було знайдено ще один критичний баг — WOH-9557 — Деякі з шаблонів сайтів не відображають фонове зображення.

Плани TODO:

- Запустити автотести з вимкненим експериментом

- Перевірити виправлення знайденої помилки

- Провести вибіркове регресійне тестування після виправлення всіх помилок

Blockers: проблема з появою горизонтального скролу в автотестах

З повагою, Магістр Обі-Ван Кенобі.

Так-так. Попри всю привабливість чек-листів, не поспішайте використовувати їх із самого початку своєї кар'єри. У них таки є свої недоліки:

• Початківці не завжди ефективно проводять тести без достатньо докладної документації
• Чек-листи неможливо використовувати для навчання нових співробітників, оскільки в них недостатньо докладної інформації
• Замовникові або керівництву може бути недостатньо того рівня деталізації, який пропонують чек-листи

Перелік функціональності (user stories) — це докладний список того, що користувач може робити в системі. Уся функціональність майбутнього продукту розбивається на найпростіші можливості у вигляді <хто> <що робить> <з чим>. Кожна з функцій має пріоритет, що визначає її важливість для загального успіху продукту. Крім того, для функції описують критерії приймання — реакцію на дії користувача, за якої вона вважається такою, що працює правильно.

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

Позитивний тест-кейс

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

Test suite

Test suite (тестовий набір) – є контейнером, який містить набір тест-кейсів і допомагає тестувальникам структурувати, виконувати та звітувати про виконання тест-кейсів. Так само як тест-кейсам, тестовим наборам присвоюють статус виконання: Active, Inprogress, Completed.

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

Тест-кейс може бути доданий до кількох тестових наборів і тест-планів. Один набір може містити будь-яку кількість кейсів.

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

Приклад тест-кейса, створеного в баг-трекінговій системі Jira

Як виглядає тім-лід, коли слухає твій тест-репорт

Давай розглянемо два приклади репортів. Це буде повчально.

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

1. Module — логічний розділ у функціоналі проєкту. Аналогічно прикладу тест-кейса №3

2. Scenarios — назва сценарію тесту. Аналогічно елементу чек-листа

3. Sub levels — під-сценарій тесту

4. Complexity — складність тесту

5. Responsible tester — відповідальна за виконання людинка

6. Date — дата виконання тесту

7. Status — pass/fail/locked/not executed (пройдено/не пройдено/заблоковано/не виконано). Далі буде без перекладу, будь ласка, вивчіть статуси!

8. Defect ID and brief description — ідентифікатор дефекту та його короткий опис

9. Severity/Priority — серйозність або пріоритет дефекту

10. Status — статус дефекту

Hello.

Short update about feature status.

In general Automation with 2.983 RC and backgroundperpage open - Pass QA.

But I met a problems with Image compare test (failed 116 tests), because appears scroll on screenshot from site with experiment. This don't reproduces manually.

So I've sent a letter to automation team because don't know how to handle this.

Link to investigation table

Manual QA cycle:

Founded one more critical bug - WOH-9557 - Some templates doesn't show background with experiment turned on

Plans TODO:

- Run image compare test with experiment on

- Check bug fix and perform Sanity cycle after

Blockers: 116 automation test fail due to automation bug. Autotest need be fixed.
Regards

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

Які переваги чек-листів порівняно з тест-кейсами:

• Нівелювання ефекту пестициду в регресійному тестуванні

• Розширення тестового покриття за рахунок відмінностей під час проходження

• Скорочення витрат на утримання та підтримку тестів: не треба писати багато літер!

• Відсутність рутини, яку так не люблять кваліфіковані тестувальники

• Можливість проходити та комбінувати тести по-різному залежно від уподобань співробітників

Use case (Варіанти використання) – описи поведінки системи під час її взаємодії із зовнішнім світом.

Use case описує те, як дійова особа намагається досягти певної мети, використовуючи програму.

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

• Мета
• Дійові особи
• Передумови
• Максимальні та мінімальні гарантії
• Основний сценарій
• Альтернативні сценарії

Складно? А хто казав, що буде легко? Не час здаватися, ідемо далі!

Case: Зареєструватися на сайті

Description: Сайт має надавати користувачеві можливість зареєструватися. Для реєстрації користувач повинен заповнити форму. Після реєстрації сайт має
надіслати на e-mail користувача підтвердження реєстрації

Формула User Story

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

Я, як X, хочу Y, щоб Z.

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

Наприклад, користувацькі історії можуть виглядати так:

Як Падаван Тестування, проходжу курс Galaxy QA Academy, щоб навчитися тестувати.

Як магістр тестування, хочу бачити прогрес студентів і перевіряти їхні роботи, щоб бути впевненим у якості їхніх знань.

Основний сенс User Story для тестувальника — використовувати їх для генерації критеріїв приймання. Критерії приймання (acceptance criteria) — це вимоги від замовника; специфікація, за якою може бути перевірена система/user story. Фактично, критерії приймання — це бізнес-правила, яким підпорядковується історія користувача, що опрацьовується. А вже деталі приймальних тестів, описані в конкретних тестах, сформують приймальні тести, які й дадуть змогу виконати тестування вже готового продукту.

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