Тест-аналіз vs. тест-дизайн. Як зробити тест-аналіз на рівні продукту та на рівні фічі

Всім привіт! Мене звати Емма, я QA Lead в компанії Gearheart.

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

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

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

Тест-аналіз vs. тест-дизайн

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

Тест-аналіз:

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

Тест-дизайн:

  • тест-дизайн — це процес створення тест-кейсів на основі тест-аналізу;
  • ціль тест дизайну полягає в тому, щоб з’ясувати, як буде перевірятися визначений обсяг тестування;
  • активності тест-дизайну містять:
    • вибір відповідних технік тест дизайну;
    • створення тест-кейсів з чітко визначеними pass/fail-критеріями та послідовністю виконання;
    • підготовка тестових даних, зокрема вхідні дані для тесту, і дані, які повинні існувати в системі перед виконанням тесту.

Якщо стисло, тест-аналіз відповідає на питання «Що тестувати?», а тест дизайн відповідає на питання «Як це тестувати?».

Рівні тест-аналізу

Тест-аналіз можна проводити на різних рівнях: на рівні продукту (системи) та на рівні фічі (конкретного функціоналу системи). Різниця полягає в обсязі та спрямованості аналізу.

Тест-аналіз продукту:

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

Тест-аналіз фічі:

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

Тест-аналіз продукту є фундаментом для подальшого аналізу конкретних фіч, тому почнемо саме з нього.

Тест-аналіз продукту

Можна виділити три основні етапи тест-аналізу на рівні продукту:

  1. Декомпозиція.
  2. Пріоритезація.
  3. Аналіз взаємозв’язків.

Етап перший: декомпозиція

Першим етапом є декомпозиція, що означає розбиття системи на частини. Крім того, що декомпозиція допомагає планувати розробку продукту, вона також має такі переваги для тестувальників:

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

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

Досить поширеним підходом є декомпозиція на рівні об’єктів. Об’єкти представляють сутності, які мають різні параметри (властивості) і дії (поведінку).

Для тест-аналізу на рівні продукту ми будемо аналізувати об’єкти та їхні дії, а до параметрів повернемось під час тест-аналізу на рівні фічі.

Розгляньмо кроки тест-аналізу продукту на етапі декомпозиції. Для прикладу будемо використовувати Slack-застосунок.

крок: визначаємо об’єкти в системі

Ось деякі об’єкти, які можна визначити в Slack:

Чи всю функціональність системи можна розбити на об’єкти? Ні, і, як було зазначено вище, ми можемо комбінувати різні рівні декомпозиції. Для опису решти функціоналу системи ми будемо використовувати епіки (велику фічу або сукупність пов’язаних фіч).

крок: визначаємо дії для кожного об’єкта

Наступним кроком є визначення дій, які можуть бути здійснені над об’єктом або самим об’єктом.

крок: визначаємо альтернативні методи дій

У системі можуть бути різні способи виконання однієї і тієї ж дії:

Етап другий: пріоритезація

Не весь функціонал системи однаково важливий для користувачів. Визначення пріоритетів допомагає:

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

Отже наступний крок — це пріоритезація частин системи, які ми отримали на етапі декомпозиції.

крок: визначаємо пріоритети для кожного об’єкта/епіка

Існує більш поглиблений підхід, коли пріоритет визначають для кожної дії об’єкта:

Етап третій: аналіз взаємозв’язків

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

Аналіз взаємозв’язків допомагає:

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

Аналіз взаємозв’язків часто документують у вигляді матриці. Матриця складається з рядків і стовпців, де кожен рядок і стовпець представляє об’єкт/епік (або інший елемент, який використовується для декомпозиції), а колір клітинки вказує чи є залежність між ними.

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

крок: визначаємо залежності між об’єктами/епіками

Продовжуючи приклад зі Slack, матриця взаємозв’язків може виглядати так:

Це однонаправлена (one-directional) матриця, яка використовує лише половину матриці, де зелені клітинки показують наявність зв’язків між елементами. За необхідності можна додати примітки до клітинок з деталями кожної залежності.

Більш просунутим підходом є двонаправлена (two-directional) матриця. Якщо в однонаправленій матриці ми просто фіксуємо взаємодію між елементами, то в двонаправленій матриці ми показуємо напрямок взаємодії, де елементи зверху в стовпцях залежать від елементів зліва в рядках, і, відповідно, елементи в рядках впливають на елементи в стовпцях.

Наприклад, якщо взяти об’єкт Messages, ми бачимо що він залежить від Users, Workspaces, Channels, і впливає на History та Search.

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

Що ж, ми пройшлись тест-аналізом на рівні продукту і тепер маємо хорошу основу для наступного рівня тест аналізу — рівень фічі. Давайте нагадаємо алгоритм тест аналізу на рівні продукту:

Усі ці дії можна виконувати в такій послідовності:

  1. Збираємо інформацію:
    • аналізуємо документацію (вимоги, специфікації, юз-кейси тощо);
    • експлуатуємо продукт (exploratory testing);
    • спілкуємось з аналітиками, розробниками, product owner тощо.
  2. Візуалізуємо інформацію:
    • можна використовувати різні види представлення інформації, такі як таблиці, mind-карти, діаграми тощо.
  3. Проводимо рев’ю:
    • переглядаємо результати нашого тест-аналізу разом із командою та product owner, щоб знайти пропущену або помилкову інформацію та вносимо відповідні виправлення.
  4. Тримаємо документацію в актуальному стані:
    • оскільки продукт розвивається, важливо оновлювати документацію вчасно, інакше вона швидко застаріє і всі зусилля будуть марними.

Тест-аналіз фічі

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

На цьому рівні можна виділити три етапи:

  1. Декомпозиція.
  2. Тест-дизайн.
  3. Аналіз взаємозв’язків.

Етап перший: декомпозиція

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

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

Отже маємо таку послідовність декомпозиції:

Розглянемо кроки тест-аналізу фічі на етапі декомпозиції на прикладі Slack-застосунку і такої фічі як створення облікового запису користувача.

крок: визначаємо об’єкт і дію

  • Object: User.
  • Action: Create Account.

крок: визначаємо параметри дії об’єкта

Для створення аккаунту користувачеві необхідно заповнити форму, яка має такі параметри:

  • Full Name.
  • Password.
  • Email Newsletter.

Кожен параметр має певні вимоги щодо того, які значення він повинен приймати:

  • Full Name:
    • 1 — 50 characters;
    • Required.
  • Password:
    • 6 — 30 characters;
    • Required.
  • Email Newsletter:
    • Yes — by default;
    • No.

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

крок: визначаємо тестові дані для кожного параметра

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

Етап другий: тест-дизайн

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

Для перевірки значень параметрів частіше всього використовують такі техніки:

  • Equivalence Partitioning;
  • Boundary Value Analysis;
  • Pairwise Testing.

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

  • State Transition Testing;
  • Decision Tables.

Детально про зазначені техніки тест-дизайну та приклади їхнього застосування розглянемо в наступній статті.

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

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

Етап третій: аналіз взаємозв’язків

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

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

Проведімо аналіз взаємозв’язків на прикладі такої фічі як надсилання повідомлень в Slack.

крок: знаходимо пов’язані об’єкти

  • Channels
    • ми можемо надсилати повідомлення в канал;
  • Users
    • ми можемо надсилати приватні повідомлення:
      • одному юзеру;
      • групі юзерів.

крок: визначаємо стани пов’язаних об’єктів

  • Channels
    • Active, Archived, Deleted;
  • Users
    • Invited, Active, Deactivated.

крок: визначаємо параметри пов’язаних об’єктів

  • Channels
    • Public, Private;
  • Users
    • Regular User, Guest User, External User.

Тепер ми можемо розширити базові тест-кейси для фічі, зокрема перевірку пов’язаних об’єктів:

  • Надіслати повідомлення в канал:
    • канали в різних станах (Active, Archived, Deleted);
    • канали з різним типом (Public, Private).
  • Надіслати приватне повідомлення:
    • одному юзеру:
      • юзер в різних станах (Invited, Active, Deactivated);
      • юзер з різним типом (Regular User, Guest, External User);
    • групі юзерів:
      • юзери в різних станах (Invited, Active, Deactivated);
      • юзери з різним типом (Regular User, Guest, External User).

Отже згадаймо, як виглядає алгоритм тест-аналізу на рівні фічі:

Висновок

Ми з’ясували, що тест-аналіз може проводитися на різних рівнях:

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

Діаграма, що наведена нижче, ілюструє рівні тест-аналізу та їхні етапи:

Наявність такого всебічного тест-аналізу дає такі переваги:

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

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


Рецензент статті — Геннадій Міщевський.

👍ПодобаєтьсяСподобалось39
До обраногоВ обраному29
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

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

Чудово розклали цей процес по поличкам з крутим прикладом і візуалізацією, дуже дякую за статтю! 👌

Стаття, яка заслуговує збереження в «Закладки» ;)

Підкажіть, які книжки або інші джерела використовували для написання статті?

З книжок, це матеріли для підготовки до ISTQB Test Analyst сертифікації:
— Syllabus istqb-main-web-prod.s3.amazonaws.com/...​AL-TA_Syllabus_v3.1.2.pdf
— The Software Test Engineer’s Handbook www.amazon.com/...​andbook-2nd/dp/1937538443
— Advanced Software Testing www.amazon.com/...​n-Rockynook/dp/1933952199

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

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

Дякую за відгук! Поділюсь своїм досвідом, я якраз працюю на проекті де розробка ведеться безперервно, по два релізи щотижня, постійно додають новий функціонал та змінюють існуючий. Погоджусь, що в такому режимі всі активності тест аналізу в повному обсязі виконувати майже неможливо.

Проте, досить реально (і нам це вдається), робити частину активностей для core функціоналу системи.

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

Після кожного релізу ми переглядаємо список задач і доповнюємо наші списки при необхідності.

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

В нашому випадку продукт досить великий (близько 5k тест кейсів), тому потрібна більш компактна форма опису системи, для швидкого референсу. В цьому нам якраз допомагають таблички такого типу.

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

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

Підписатись на коментарі