Меню

Зразок шаблону для звіту про прийомні випробування з прикладами

sample template acceptance test report with examples

Спробуйте Наш Інструмент Для Усунення Проблем

Огляд звіту про приймальні випробування (частина III):

Попередній підручник | НАСТУПНИЙ підручник

У нашому попередньому підручнику з Приймально-здавальна документація із сценаріями реального часу ”Ми обговорили план приймальних випробувань.

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

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

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

Шаблон тесту приймання

Що ви дізнаєтесь:

Звіт про стан приймальних випробувань

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

Загальний шаблон для звіту про стан перевірки:

Дата :Дата звіту про стан приймальних випробувань

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

  • Кількість пройдених тестів
  • Кількість невдалих тестів
  • Кількість незавершених випробувань

Детальні дані про виконання приймально-здавальних випробувань до дати:

  • Загальна кількість тестів
  • Кількість пройдених тестів
  • Кількість невдалих тестів
  • Кількість незавершених випробувань
  • Кількість тестів, що очікують на розгляд

Деталі дефектів:

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

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

Звіт про прийнятний тест

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

Загальний шаблон для підсумкового звіту про прийомні випробування:

Резюме

Варіації

Варіації

Результати

Звіти

Оцінка

Рекомендація

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

Зусилля

Зусилля

Звіт про вихід

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

Загальний шаблон для звіту про вихід:

Назва продукту, версія випуску, номер збірки

Останній звіт

Переглянуто далі

Переглянуто

Огляд коментарів

Дата виходу

Вихід від

Коментарі до реєстрації

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

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

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

Прийомне тестування в Agile

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

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

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

Приймальні випробування проводяться на двох різних етапах в Agile:

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

Кожна історія користувача тут повинна пройти перевірку прийнятності та повинна бути передана на розгляд. Будь-які збої в тесті приймання повинні розглядатися як високопріоритетні та негайно виправлятися; це, в свою чергу, матиме тест прийому для його виконання.

Очки історії присуджуються кожній історії користувача на основі успішності результатів тесту приймання за кожним із критеріїв прийняття. Тестування на прийняття також визначає завершення на рівні історії користувача, стверджуючи, що критерії прийнятності для історії виконані.

Хто проводить прийомне тестування в Agile?

Зазвичай менеджери з продуктів, експертиза предметних питань (можуть бути замовниками І / АБО бета-тестерами) проводять перевірку прийнятності в гнучкому середовищі. Іноді QA також бере участь у цій діяльності разом зі своїми регулярними завданнями регресії.

Переваги приймального тестування в Agile

Існує кілька переваг перевірки прийнятності в Agile.

Переваги:

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

Недоліки

Хоча є кілька переваг, є й певні недоліки.

До недоліків належать:

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

Розробка керованого тестування (ATDD)

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

Це пояснюється тим, що різні точки зору кожного з членів команди дадуть новий спосіб мислення для кожного з критеріїв прийняття та отримають велику кількість тестів прийняття, що охоплюють більше сценаріїв. Іноді, ATDD також називається Розробка сюжетного тесту (STDD).

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

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

Висновок

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

Коротко:

  • Приймальні випробування пройшли.
  • Дефекти знаходяться на допустимому рівні.
  • Досягнуто охоплення потоком / сценарієм.
  • Продукт та його рішення приймаються.
  • Клієнт досить впевнений у своєму продукті.
  • Усі документи на Продукт оновлюються відповідно до останніх функцій.
  • Результат за зусилля команди.
  • Добре йти вперед із запуском виробництва.

Попередній підручник | НАСТУПНИЙ підручник

Сподіваюся, ви отримали величезні знання з цих підручників з тестування з приймання. Не соромтеся ділитися своїми думками та висувати свої запитання у розділі коментарів нижче.

Рекомендована література

^