Техніки Тест-дизайну На Реальних Прикладах

У наведених вище тест кейсах значення комбінуються випадковим чином, але наші комбінації можуть не збігатися з комбінаціями користувачів, і ми можемо пропустити дефекти. Існує правило не об’єднувати невалідні значення в одному тесті, щоб запобігти ситуації, коли наявність одного невалідного значення може маскувати некоректну обробку іншого невалідного значення. Ця техніка знаходить дефекти, пов’язані з обробкою граничних значень, зміщенням або пропуском границь, помилки з логікою «менше-ніж» і «більше-ніж». Boundary Value Analysis техніка є розширенням Equivalence Partitioning техніки, яка застосовується коли елементи еквівалентних класів впорядковані, тобто коли ми можемо сказати, що один елемент більший або менший за інший. Зверніть увагу, що для параметра Password додатково присутня перевірка порожнього значення, незважаючи на те що воно входить в один клас разом зі значенням 5, значення «0» рекомендують завжди перевіряти окремо.

Кожен з цих сценаріїв представляє різні ситуації взаємодії з програмою та допомагає впевнитися, що програма коректно обробляє всі можливі сценарії використання дати народження. Пам’ятаю, як передивлялась певні відео декілька разів, щоб зрозуміти деякі з технік. Тому я розписала основні з них (часто використовувані), наводячи приклади. UX Tools вирізняється своїм навчальним підходом і фокусом на UX Analysis. Сервіс для тих, хто хоче не просто дизайнити, а й глибше розуміти користувачів.

Exploratory Vs Ad-hoc Testing (достідницьке Vs Ад-хок Тестування)

В результаті процесу розробки тестів створюються незалежні від реалізації тестові приклади, які перевіряють вимоги або користувальницькі історії. Навпаки, тести, що створюються на основі відсутності покриття за обраними критеріями адекватності тестових даних, підтверджують проблеми, що залежать від реалізації; Однак це не дизайн тесту, це створення тесту. Дуже важливо використовувати метод «спочатку тестування» (test-first method), т. Дизайн тестів також дуже ефективний для запобігання дефектам, якщо він застосовується до застосування. Приклад може здатися заплутаним, але в Back-end тестуванні це — звичайний робочий флоу тестування або аналізу роботи фічі.

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

Функциональное И Нефункциональное Тестирование

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

Існує гіпотеза, що часто дефекти виникають при обробці значень, які знаходяться на границях еквівалентних класів, тому рекомендують додатково перевіряти коректність роботи таких значень. В нашому випадку продукт досить великий (близько 5k тест кейсів), тому потрібна більш компактна форма опису системи, для швидкого референсу. Детально про зазначені техніки тест-дизайну та приклади їхнього застосування розглянемо в наступній статті. Розглянемо кроки тест-аналізу фічі на етапі декомпозиції на прикладі Slack-застосунку і такої фічі як створення облікового запису користувача. Тому наступним важливим кроком є аналіз взаємозв’язків, де ми виявляємо зв’язки між об’єктами/епіками, аналізуємо, як вони взаємодіють один з одним.

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

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

• Декомпозиція може проводитися на різних рівнях залежно від контексту продукту та потреб проєкту.
• Організатори мінікурсу залишаються на зв’язку з учасниками впродовж всього навчання.
• Існує правило не об’єднувати невалідні значення в одному тесті, щоб запобігти ситуації, коли наявність одного невалідного значення може маскувати некоректну обробку іншого невалідного значення.
• Наприклад, якщо ми вводимо правильну дату народження, програма обчислить вік.
• Подивимось, як застосувати цю техніку на прикладі такої фічі як Create Account в Slack застосунку.
• Тестовий набір включає крім тестових сценаріїв ще й тестові дані або правила їх генерації.

Используйте Автоматизацию Для Рутинных Проверок

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

Ми також можемо використовувати цю техніку, коли на поведінку системи впливають різні фактори або конфігурації і дефекти можуть виникати через конкретні комбінації. Ви можете помітити, що в наших тест кейсах немає конкретних значень. Техніки тест-дизайну дають нам high-level тести, але нам однаково потрібно підготувати конкретні значення та очікуваний результат до початку тестування. Boundary Value Analysis (BVA) техніка використовується в поєднанні з Equivalence Partitioning.

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

Це відбувається з метою економії, але на якість кінцевого продукту це впливає негативно. Спочатку страждає якість тестів, тестування, а врешті-решт і програмного забезпечення. Повна специфікація не означає безпомилкову специфікацію, тому що під час розробки тесту можна знайти та виправити безліч проблем (запобігання дефектам). Це тільки означає, що у нас є всі необхідні вимоги або в Agile розробці у нас є всі епіки, теми та історії користувача з критеріями прийнятності (acceptance criteria).