Теорія тестування від А до Я.

19 mins

best

testing

qa

interview

---

Питання на співбесідах Trainee/Junior/Middle Manual QA в середньому на 50% складаються з теорії тестування.

Навігація: 🔗

1. Тестування. Якість ПЗ

2. Валідація vs Веріфікація

3. Цілі тестування

4. Етапи тестування

5. Тест план

6. Тест-дизайн

7. Техніки тест-дизайну

8. Advanced (просунуті) техніки тест-дизайну

9. Бонусні та Авторські Техніки тест-дизайну

10. Exploratory vs Ad-hoc testing (Достідницьке vs Ад-хок тестування)

11. Test Case

12. Check-list (Чек-лист)

13. Bug Report (Баг-репорт)

14. Severity vs Priority (Серйозність vs Пріоритет)

15. Traceability Matrix (Матриця відповідності вимог)

16. Defect / Error / Bug / Failure

17. Рівні тестування (Levels of Testing)

18. Види / Типи тестування (Testing Types)

19. Принципи тестування (Principles of Testing)

20. Статичне та Диманічне тестування (Static and Dynamic testing)

21. Вимоги (Requirements)

22. Життєвий цикл багу

23. Життєвий цикл розробки ПЗ (SDLC)

24. Методології розробки

---

1. Тестування. Якість ПЗ 🔗

Тестування

— перевірка відповідності між реальною та очікуваною поведінкою системи.

Тестування

— це одна з технік контролю якості, що включає активності:

• Test Management (планування робіт)
• Test Design (проектування тестів)
• Test Execution (виконання тестів)
• Test Analysis (аналіз результатів тестування)

Якість ПЗ (Software Quality)

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

2. Валідація vs Верифікація 🔗

Верифікація (verification)

• Оцінка відповідності продукту вимогам (специфікації).

Відповідає на питання: “Чи система працює відповідно до вимог?”

Валідація (validation)

• Оцінка відповідності продукту очікуванням користувачів.

Відповідає на питання: “Чи вимоги задовольняють очікування користувача?”

3. Цілі тестування 🔗

1. Підвищити ймовірність того, що система:
   • відповідатиме всім описаним вимогам.
   • працюватиме правильно за будь-яких обставин.
2. Надання актуальної інформації про стан системи на даний момент.

4. Етапи тестування 🔗

1. Аналіз продукту
2. Робота з вимогами
3. Розробка тест плану
4. Створення тестової документації
5. Тестування
6. Звіт результатів тестування (test report)
7. Стабілізація
8. Експлуатація

5. Тест план 🔗

Test Plan - це документ, що описує весь обсяг робіт з тестування.

Відповідає на запитання:

• Що?
• Коли?
• Критерії початку/закінчення тестування.
• Оточення (environment) dev/staging/production?
• Підходи/техніки/інструменти/види тестування?
• Браузери/версії/OS/розширення екрану?
• Хто? Обов’язки? Ресурси? Навчання?
• Терміни?
• Графік?
• Стратегія тестування.
• Посилання на документацію.
• Посилання на вимоги.

6. Тест дизайн 🔗

Test design — це етап процесу тестування ПЗ, на якому проектуються та створюються тест кейси, відповідно до критеріїв якості та цілей тестування.

• Тест аналітик — визначає «ЩО тестувати?»
• Тест дизайнер — визначає «ЯК тестувати?»
• Реальність — все робить 1 людина :)

7. Техніки тест дизайну 🔗

Еквівалентний Поділ (Equivalence Partitioning)

• Як приклад, у вас є діапазон допустимих значень від 1.00 до 10.00 доларів, ви повинні вибрати одне будь-яке правильне значення всередині інтервалу, скажімо, 5.00, та будь-які невірні значення поза інтервалом, наприклад 0.99 та 11.00.

Аналіз Граничних Значень (Boundary Value Analysis)

– Як приклад, у вас є діапазон допустимих значень від 1.00 до 10.00 доларів.

• Two value (двозначний) BVA: валідні граничні значення 1.00, 10.00, і невалідні значення 0.99 та 10.01.
• Three/Full value (тризначний) BVA: валідні граничні значення 1.00, 1.01, 10.00, 9.99, і невалідні значення 0.99 та 10.01.

Причина / Наслідок (Cause/Effect)

• введення комбінацій умов (причин) для отримання відповіді (наслідку) від системи.
• Наприклад, ви перевіряєте можливість додавати клієнта:

Причина: необхідно заповнити поля “Ім’я”, “Адреса”, “Номер Телефону” і натиснути кнопку “Додати”.

Наслідок: Після натискання на кнопку «Додати» система додає клієнта в базу даних і показує його айді на екрані.

Передбачення помилки (Error Guessing)

• використання знань про систему та здатність до інтерпретації специфікації (вимог) на рахунок того, щоб «передбачити» за яких умов система може видати помилку.

Наприклад, специфікація каже: “користувач повинен ввести код”.

Тестувальник думатиме: «Що, якщо я не введу код?», «Що, якщо я введу неправильний код?»…

8. Просунуті техніки тест дизайну 🔗

Здивуй інтерв'юера. Вааааау...

Попарне тестування (Pairwise Testing)

• Формування таких наборів тестових даних, у яких кожне тестоване значення кожного з параметрів, що перевіряються, хоча б один раз поєднується з кожним тестованим значенням всіх інших параметрів, що перевіряються.

Звучить трохи складно, але на практиці використовувати цю техніку все дуже просто та логічно. Приклад на відео:

• Суть техніки - ми не перевіряємо всі поєднання всіх значень, але перевіряємо ВСІ ПАРИ значень.

Таблиця прийняття рішень (Decision table)

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

Діаграма (граф) станів-переходів (State Transition diagram)

• Діаграма для опису поведінки системи.
• Система має кінцеву кількість станів та переходів між станами.
• Діаграма може бути переведена в Таблицю станів-переходів (або таблицю прийняття рішень).

Use case (користувацький сценарій)

    Це сценарій взаємодії користувача із системою для досягнення певної мети.

Use case містить:

• хто використовує систему (наприклад роль адмін/покупець/продавець).
• що користувач хоче зробити.
• цілі користувача.
• кроки, які виконує користувач.
• опис того, як система реагує на дії користувача.

9. Бонусні та авторські техніки тест дизайну 🔗

Просвіти інтерв'юера. Розплющ йому очі.

Семі-Вичерпне тестування (Semi-Exhaustive Testing)

• перевірка всіх можливих комбінацій вхідних значень. Зазвичай, застосування цього методу на практиці є недоцільним. (див. принцип тестування №2 Вичерпне тестування недосяжне (Exhaustive testing is impossible))

    Іноді на практиці зустрічаються випадки, коли стандартні техніки не дають достатнього рівня впевненості у працездатності системи. Наприклад, в системах, пов’язаних з медициною або авіа сферами, іноді варто застосовувати Semi-Exhaustive Testing.

    Не забуваємо про принцип тестування №6 Тестування залежить від контексту (Testing is context dependent). Думаємо головою, коли застосування цієї техніки є доречним, а коли ні.

Блок-схема (block scheme/diagram)

    Блок-схему можна використовувати як техніку тест-дизайну, складаючи тест-кейси за логікою схеми.

Капелюхи / ролі

    Техніка “Капелюхи / ролі” чимось схожа на техніку складання тест кейсів по Use Case.

    Принцип: одягаємо капелюх певної ролі користувача і уявляємо себе в його ролі.

    Приклад: “одягаємо” капелюх Кастинг Директора і розмірковуємо, як новий функціонал працюватиме для цієї ролі. Представляємо, які можуть бути залежності та особливості системи для Кастинг Директора. Розмірковуємо, які цілі переслідує Кастинг директор в нашій системі та як поведінка системи має відрізнятися від інших ролей. Потім “одягаємо” капелюх Актора, Агента, Адміна….

Техніки тест дизайну, про які поки що ніде не чув: 🔗

Кожен має право придумати свою техніку тест дизайну. Тестування - це не бездумне застосування всім відомих технік. © Іларіон

    Про техніки “Talks-driven” (балачки-driven), “Analytics-driven”, “Bug-driven” я поки що ніде не чув.

    ⚠️ Інтерв’юери можуть бути відмінниками, які обмежуються лише книжковими поняттями та не виходять за рамки (thinking out of the box). Тому будьте обережні з озвучуванням цих технік інтерв’юеру, особливо, якщо у вас проблеми з поясненням та прикладами)) Не обмежуйте себе існуючими техніками, думайте, фантазуйте.

Балачки-driven (talks-driven)

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

    Якщо фантазія не працює, то задаємо Wh-питання:

what, when, where, who, whom, which, whose, why and how - що, коли, де, хто, кому, який, чий, чому, як

    Для просунутих: спочатку збираємо всіх по одному, а потім по кілька людей. Не випускаємо, поки не отримаємо всі відповіді та не вирішимо які тести проектувати.

Аналітика-driven (analytics-driven)

    Якщо на проекті використовується аналітика, наприклад при натисканні на кнопки або при відкритті сторінки відправляються події (events) в систему для аналітики, то дані аналітики можна використовувати для складання тест кейсів.

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

Баг-дрівен (bug-driven)

    Принцип тестування №4 Скупчення дефектів (Defects clustering) свідчить, що “більшість дефектів міститься у невеликій кількості модулів”.

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

    Додатково можна посидіти над знайденими багами та подумати “А може аналогічний баг бути в іншій частині системи?”.

10. Exploratory vs Ad-hoc testing 🔗

Дослідницьке тестування (exploratory testing)

• це одночасне вивчення системи, проектування тестів (тест дизайн) та безпосередньо тестування.
• Ця техніка базується на досвіді тестувальника (experience based).
• Приклад: приходить тестувальник на новий проект і починає одночасно вивчати сайт, писати чек-лист та проходити цей чек-лист (тестувати).

Ad-hoc тестування

• Переклад від автора статті – “тестування від балди”.
• Вид тестування, що виконується без підготовки до тестів, без визначення очікуваних результатів, без проектування тестових сценаріїв.
• неформальне, імпровізаційне тестування.

11. Test Case 🔗

Test Case

• це тестовий артефакт/документ, що описує сукупність кроків, конкретних умов і параметрів, необхідних для перевірки функції, що тестується.

Test Case

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

Test Case

• це опис перевірки системи на відповідність вимогам.

Тест кейс складається з:

• ID (ідентифікатор)
• Title (назва)
• Type (тип)
• Priority (пріоритет)
• Preconditions (передумови)
• Steps (кроки)
• Expected Result (очікуваний результат)
• Post conditions (пост умови) - наприклад, очищення даних або повернення системи в початковий стан.

Тест кейси поділяються на позитивні та негативні:

• Позитивний тест кейс використовує тільки коректні дані і перевіряє, що програма правильно виконала функцію, що викликається.
• Негативний тест кейс оперує як коректними, так і некоректними даними (мінімум 1 некоректний параметр) і ставить за мету перевірку виняткових ситуацій (спрацювання валідаторів), а також перевіряє, що функція, що викликається системою, не виконується при спрацьовуванні валідатора.

Приклади та найкращі практики створення тест кейсів -

12. Check-list (Чек-лист) 🔗

Check list

— це документ, який описує, що має бути протестовано.

• Чек-лист може бути абсолютно різного рівня деталізації.
• Як правило, чек-лист містить тільки дії (кроки) без очікуваного результату.
• Чек-лист менш формалізований ніж тест кейс.
• Чек-лист набагато легше підтримувати, ніж тест кейси.
• Пункти чек-листа відповідають на питання “що тестувати?”, а конкретні кроки та деталі “як тестувати?” описують в тест кейсах.

Приклади та найкращі практики створення чек-листів -

13. Bug report (баг репорт) 🔗

Bug Report

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

Основні складові Bug report:

• ID (ідентифікатор)
• Назва (Title)
• Короткий опис (Summary)
• Проект (Project)
• Компонент програми (Component)
• Номер версії (Version)
• Серйозність (Severity)
• Пріоритет (Priority)
• Статус (Status)
• Автор (Author)
• Виконавець (Assignee)
• Оточення (Environment: dev/test/staging/prod/etc.)
• App/build version (версія білда/додатку)
• Кроки відтворення (Steps to Reproduce)
• Фактичний Результат (Actual Result)
• Очікуваний результат (Expected Result)

Додаткові складові Bug report:

• Screenshots (скріншоти)
• Video (відео)
• Credentials (login + password)
• Browser console errors (логи з браузера)
• Mobile app logs (логи з мобілки)

• Server logs (логи з сервера)

• API Requests (АПІ запити)
• Analytics events (івенти з аналітики)
• Database data (дані з бази даних)

• Database queries (запити до бази)

• Date and time (дата та час)
• Comments/Notes (коментарі/нотатки)

• Link tasks/bugs (підв’язка інших задач/багів до поточного)

• HAR archive - архів з усіма запитами в Network

14. Severity vs Priority 🔗

Серйозність (Severity)

• Це атрибут, що характеризує вплив дефекту на працездатність програми.

В теорії Severity виставляється тестувальником.

Градація Severity:

• S1 Блокер (Blocker)
• S2 Критична (Critical)
• S3 Значна (Major)
• S4 Незначна (Minor)
• S5 Тривіальна (Trivial)

Пріоритет (Priority)

• це атрибут, що вказує на черговість виконання завдання чи усунення дефекту.

Чим вище пріоритет, тим швидше потрібно виправити дефект.

В теорії Priority виставляється менеджером, тимлідом чи замовником.

Градація Priority:

• P1 Високий (High)
• P2 Середній (Medium)
• P3 Низький (Low)

Реальність: на всіх проектах, де я працював, був лише priority :)

Реальність: на різних проектах різні градації.

Приклад питання на співбесіді про Severity / Priority -

15. Traceability matrix (Матриця відповідності вимог) 🔗

    Traceability matrix - це двовимірна таблиця, що містить відповідність функціональних вимог та тест кейсів.

У заголовках колонок таблиці розташовані вимоги, а в заголовках рядків – ID тест кейсів.

На перетині — позначка, що означає, що вимога поточної колонки покрита тестовим сценарієм поточного рядка.

16. Defect / Error / Bug / Failure 🔗

Дефект (він же баг)

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

Bug (defect)

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

Наприклад, коли ніяк не контролюються дані введені користувачем, в результаті невірні дані викликають краші (crash) або інші “приколи” в роботі програми. Або програма розроблена так, що вона не відповідає тому, що від неї очікується.

Error (Помилка)

• дія, яка призвела до неправильного результату.

Приклад 1 - вводить літери в поля, де потрібно вводити цифри (вік, кількість товару тощо). Error: “поле має містити лише цифри”.

Приклад 2 - реєструється зі вже існуючим в системі емейлом. Error: “цей емейл вже використовується”.

Failure

• збій (причому необов’язково апаратний) у роботі компонента, всієї програми чи системи.

Існують такі дефекти, які призводять до збоїв. І існують такі, що не призводять. Наприклад UI-дефекти. Але апаратний збій, що ніяк не пов’язаний із software, теж є failure.

17. Рівні тестування (Levels of testing) 🔗

1. Модульне тестування (Unit Testing)

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

2. Інтеграційне тестування (Integration Testing)

Тестування взаємодії між кількома класами, функціями, модулями. Наприклад, тестування API через Postman.

3. Системне тестування (System Testing)

Перевірка як функціональних, так і нефункціональних вимог системи.

4. Приймальне тестування (Acceptance Testing)

Перевірка відповідності системи вимогам та проводиться з метою:

• визначення чи задовольняє система приймальним (acceptance) критеріям;
• винесення рішення замовником/менеджером приймається програма чи ні.

18. Види / Типи тестування (Testing types) 🔗

18.1. Функціональні види тестування

• Функціональне тестування (Functional testing)
• Тестування графічного інтерфейсу користувача (GUI Testing)
• Тестування безпеки (Security and Access Control Testing)
• Тестування взаємодії (Interoperability Testing)

18.2. Нефункціональні види тестування

• Усі види тестування продуктивності (Performance):
  • Навантажувальне тестування (Load Testing) – багато користувачів.
  • Стресове тестування (Stress Testing) - дуже багато даних та/або користувачів (пікові значення).
  • Об’ємне тестування (Volume Testing) - багато даних.
  • Тестування стабільності або надійності (Stability / Reliability Testing)
• Тестування встановлення (Installation testing)
• Тестування зручності користування (Usability Testing)
• Тестування на відмову та відновлення (Failover and Recovery Testing)
• Конфігураційне тестування (Configuration Testing)

18.3. Пов’язані зі змінами види тестування

• Димове тестування (Smoke Testing)
• Регресійне тестування (Regression Testing)
• Повторне тестування (Re-testing)
• Тестування збірки (Build Verification Test)
• Санітарне тестування або перевірка узгодженості/справності (Sanity Testing)

19. Принципи тестування (Principles of testing) 🔗

1. Тестування демонструє наявність дефектів (Testing shows presence of defects)

Тестування може показати, що дефекти в системі є, але не може довести, що їх немає.

2. Вичерпне тестування недосяжне (Exhaustive testing is impossible)

Повне тестування всіх комбінацій вводів і передумов фізично нездійсненно, крім виняткових випадків.

3. Раннє тестування (Early testing)

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

4. Скупчення дефектів (Defects clustering)

Як правило, більшість дефектів, виявлених при тестуванні, міститься в невеликій кількості модулів.

5. Парадокс пестициду (Pesticide paradox)

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

6. Тестування залежить від контексту (Testing is context dependent)

Тестування виконується по-різному, залежно від контексту.

7. Омана про відсутність помилок (Absence-of-errors fallacy)

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

20. Статичне та динамічне тестування 🔗

Статичне (static) тестування

Здійснюється БЕЗ запуску коду програми.

Приклади: тестування вимог/документації, код ревью, статичні аналізатори коду.

Динамічне (dynamic) тестування

Здійснюється З запуском коду програми.

21. Вимоги (requirements) 🔗

    Вимоги - це специфікація (опис) того, що має бути реалізовано.

Вимоги описують те, що необхідно реалізувати, без деталізації технічного боку рішення. “Що”, а не “як”.

Вимоги до вимог:

1. коректність
2. недвозначність
3. повнота
4. несуперечність
5. упорядкованість за важливістю та стабільністю
6. перевірюваність (тестопридатність)
7. модифікованість
8. трасування
9. зрозумілість

22. Життєвий цикл багу 🔗

23. Життєвий цикл розробки ПЗ 🔗

Software Development Life Cycle (SDLC):

1. Ідея (Idea)
2. Збір та аналіз вимог (Planning and Requirement Analysis)
3. Документування вимог (Defining Requirements)
4. Дизайн (Design Architecture)
5. Розробка (Developing)
6. Тестування (Testing)
7. Впровадження/розгортання (Deployment)
8. Підтримка (Maintenance)
9. Смерть (Death)

24. Методології розробки 🔗

Waterfall

V-model

Spiral

Kanban

Scrum

Scrum-ban

Пропозиції та побажання 🔗

    Завжди радий отримувати конструктивну критику щодо контенту лекцій та цієї статті. Не соромтеся 🤗 ☀️

Джерела: стаття на доу https://dou.ua/forums/topic/13389 www.protesting.ru, bugscatcher.net, qalight.com.ua, thinkingintests.wordpress.com, книга ISTQB, www.quizful.net, bugsclock.blogspot.com, www.zeelabs.com, devopswiki.net, hvorostovoz.blogspot.com.

Share this article:

facebook twitter reddit linkedin email