Як створити матрицю простежуваності вимог (RTM): Приклад та зразок шаблону

how create requirements traceability matrix

Що таке вимоги до матриці простежуваності (RTM) при тестуванні програмного забезпечення: покрокове керівництво по створенню матриці простежуваності з прикладами та зразком шаблону

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

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

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

Як це загальна практика в STH , ми побачимо аспекти “Що” та “Як” ТМ у цій статті.

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

• Що таке матриця простежуваності вимог?
  • Чому потрібна простежуваність вимог?
  • Типи матриці простежуваності
    • Відстеження вперед
    • Зворотна простежуваність
    • Двонаправлена ​​простежуваність
  • Приклади RTM
• Перевірте охоплення та відстеження вимог
  • Що таке випробування?
  • Типи специфікацій вимог
    • # 1) Вимоги до бізнесу
    • # 2) Документ специфікації вимог до програмного забезпечення (SRS)
    • # 3) Документи, що вимагають проекту (PRD)
    • # 4) Використовуйте документ справи
    • # 5) Документ про перевірку дефектів
    • # 6) Історії користувачів
  • Виклики для збору вимог
  • Як може допомогти відстеження вимог
  • Переваги RTM та випробовування
  • Виклики у висвітленні тестів
• Як створити матрицю простежуваності вимог
  • Важливі зауваження
  • Висновок
  • Рекомендована література

Що таке матриця простежуваності вимог?

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

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

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

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

Чому потрібна простежуваність вимог?

Матриця простежуваності вимог допомагає пов’язати вимоги, Тестові кейси , і дефекти точно. Весь додаток тестується за наявності простежуваності вимог ( Тестування наскрізне програми).

найкраща програма для завантаження mp3 для андроїд

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

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

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

Типи матриці простежуваності

Відстеження вперед

У розділі „Відстеження вперед” Вимоги до тестових випадків. Це гарантує, що проект прогресує у бажаному напрямку і що всі вимоги ретельно перевіряються.

Зворотна простежуваність

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

Двонаправлена ​​простежуваність

(Вперед + назад): Матриця належної простежуваності містить посилання від тестових випадків до вимог і навпаки (вимоги до тестових випадків). Це називається „двонаправленою” відстежуваністю. Це гарантує, що всі тестові випадки можуть бути відстежені до вимог, і кожна із зазначених вимог має точні та дійсні тестові випадки для них.

Приклади RTM

# 1) Вимоги до бізнесу

BR1 : Має бути доступна можливість написання електронних листів.

Сценарій тесту (технічна специфікація) для BR1

TS1 : Надається можливість скласти пошту.

Тестові випадки:

Тестовий випадок 1 (TS1.TC1) : Параметр Скласти пошту ввімкнено і працює успішно.

Тестовий випадок 2 (TS1.TC2) : Параметр Скласти пошту вимкнено.

# 2) Дефекти

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

Наприклад, Якщо TS1.TC1 виходить з ладу, тобто опція «Створити пошту», хоча увімкнена, працює неправильно, тоді дефект можна реєструвати. Припустимо, що автоматично згенерований або вручну присвоєний ідентифікатор дефекту - D01, тоді його можна зіставити з номерами BR1, TS1 та TS1.TC1.

Таким чином, всі Вимоги можуть бути представлені у форматі таблиці.

Перевірте охоплення та відстеження вимог

Що таке випробування?

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

Як досягти охоплення тестом?

Максимального охоплення випробуванням можна досягти, встановивши належну «простежуваність вимог».

• Порівняння всіх внутрішніх дефектів із розробленими тестовими кейсами
• Порівняння всіх повідомлених клієнтом дефектів (CRD) до окремих тестових випадків для майбутнього набору регресійних тестів

Типи специфікацій вимог

# 1) Вимоги до бізнесу

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

Зазвичай його готують «Бізнес-аналітики» або проект «Архітектор» (залежно від організації або структури проекту). Документ 'Специфікації вимог до програмного забезпечення' (SRS) походить від BRS.

# 2) Документ специфікації вимог до програмного забезпечення (SRS)

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

# 3) Документи, що вимагають проекту (PRD)

PRD є довідковим документом для всіх членів команди проекту, щоб точно сказати, що повинен робити продукт. Його можна розділити на такі розділи, як Призначення продукту, Характеристики товару, Критерії випуску та Бюджетування та графік проекту.

# 4) Використовуйте документ справи

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

Наприклад,

Актор: Клієнт

Роль: Завантажити гру

Завантаження гри успішно.

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

# 5) Документ про перевірку дефектів

Він документально містить усі деталі, пов’язані з дефектами. Команда може вести документ «Перевірка дефектів» для виправлення та повторного тестування дефектів. Тестери можуть посилатися на документ «Перевірка дефектів», коли вони хочуть перевірити, чи дефекти виправлені чи ні, повторно протестувати дефекти в різних ОС, пристрої, різній конфігурації системи тощо.

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

# 6) Історії користувачів

Історія користувача в основному використовується в розробці «Agile», щоб описати функцію програмного забезпечення з точки зору кінцевого користувача. Історії користувачів визначають типи користувачів і те, яким чином і чому вони хочуть певної функції. Вимога спрощується шляхом створення історій користувачів.

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

Виклики для збору вимог

# 1) Зібрані вимоги повинні бути детальними, однозначними, точними та чітко визначеними. Але є НЕ відповідна міра для розрахунку цих деталей, однозначність, точність та чітко визначені специфікації, які необхідні для збору вимог.

# два) Інтерпретація 'бізнес-аналітика' або 'власника продукту', хто надає інформацію про вимоги, є критично важливою. Аналогічним чином команда, яка отримує інформацію, повинна підняти відповідні роз'яснення, щоб зрозуміти очікування зацікавлених сторін.

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

# 3) Інформація також повинна отримуватися з точки зору кінцевого користувача.

# 4) Стан зацікавлених сторін в різні часи суперечив або суперечив вимогам.

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

# 6) Розроблено ресурси, відсутність навичок для застосування.

# 7) Часті зміни сфери застосування програми або зміни пріоритетів для модулів.

# 8) Пропущені, неявні або недокументовані вимоги.

# 9) Невідповідні або невизначені вимоги, визначені замовниками.

# 10) Висновок з усіх вищезазначених факторів полягає в тому, що „Успіх” або „Невдача” проекту значно залежить від вимоги.

Як може допомогти відстеження вимог

# 1) Де реалізується Вимога?

Наприклад,

Вимога: Впровадити функцію «Скласти пошту» у поштовій програмі.

Реалізація: Там, де на головній сторінці слід розмістити та отримати доступ до кнопки «Створити пошту».

# 2) Чи потрібна вимога?

Наприклад,

Вимога: Впровадити функцію 'Скласти пошту' у поштовій програмі лише для певних користувачів.

Реалізація: Відповідно до прав доступу користувачів, якщо для вхідних повідомлень електронної пошти встановлено значення 'Лише для читання', у цьому випадку кнопка 'Створити пошту' не потрібна.

# 3) Як інтерпретувати вимогу?

Наприклад,

Вимога: Функція «Скласти пошту» у поштовій програмі зі шрифтами та вкладеннями.

Реалізація: Коли натискається клавіша «Написати пошту», які всі функції мають бути надані?

• Текст тексту, щоб писати електронні листи та редагувати різними типами шрифтів, а також жирним шрифтом, курсивом, підкреслювати їх
• Типи вкладень (зображення, документи, інші електронні листи тощо)
• Розмір вкладень (максимально дозволений розмір)

Таким чином Вимоги розбиваються на підвимоги.

# 4) Які дизайнерські рішення впливають на реалізацію Вимоги?

Наприклад,

Вимога: Усі елементи „Вхідні”, „Надіслані листи”, „Чернетки”, „Спам”, „Кошик” тощо повинні бути чітко видимими.

Реалізація: Елементи, які мають бути видимими, повинні відображатися у форматі «Дерево» або «Табуляція».

# 5) Чи розподілено всі вимоги?

Наприклад,

Вимога: Надається опція 'Кошик'.

Реалізація: Якщо передбачена опція «Кошик» пошти, тоді опція (вимога) «Видалити» електронної пошти повинна бути реалізована спочатку і повинна працювати точно. Якщо параметр «Видалити» пошту працює належним чином, тоді в «Смітник» збиратимуться лише видалені електронні листи, а реалізація опції «Вимагати» пошти (вимога) матиме сенс (буде корисною).

Переваги RTM та випробовування

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

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

Додаткова функція також може стати джерелом дефектів, що може спричинити проблеми для клієнта після встановлення.

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

модульний тест проти прикладу інтеграційного тесту

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

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

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

# 6) У випадку, якщо від клієнта надійшов «Запит на зміну», усі компоненти програми, на які впливає запит на зміну, змінюються, і нічого не пропускається. Це ще більше посилює оцінку впливу, який запит на зміну робить на програмне забезпечення.

# 7) На перший погляд простий запит на зміну може містити зміни, які потрібно внести до кількох частин програми. Краще зробити висновок про те, скільки зусиль буде потрібно, перш ніж погодитись внести зміни.

Виклики у висвітленні тестів

# 1) Хороший канал зв'язку

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

# 2) Важливим є визначення пріоритетів сценаріїв випробувань

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

# 3) Впровадження процесу

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

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

# 4) Наявність ресурсів

Ресурси бувають двох типів, тестери, що спеціалізуються на спеціалізованому домені, та інструменти тестування, що використовуються тестерами. Якщо тестувальники мають належні знання про домен, вони можуть писати та реалізовувати ефективні сценарії тестування та сценарії. Для реалізації цих сценаріїв та сценаріїв тестери повинні бути добре оснащені відповідними «Інструментами тестування».

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

# 5) Ефективне впровадження стратегії тестування

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

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

Як створити матрицю простежуваності вимог

Щоб бути з нами, ми повинні точно знати, що саме потрібно відслідковувати чи відстежувати.

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

Припустимо, наступним є наш Документ про бізнес-вимоги (BRD): ( Завантажте цей зразок BRD у форматі Excel )

(Клацніть будь-яке зображення, щоб збільшити)

Нижче наведено наш Документ про функціональні характеристики (FSD), заснований на інтерпретації Документа про бізнес-вимоги (BRD) та його адаптації до комп’ютерних програм. В ідеалі всі аспекти FSD повинні бути розглянуті в BRD. Але для простоти я використовував лише пункти 1 і 2.

Зразок FSD зверху BRD: ( Завантажте цей зразок FSD у форматі Excel )

Примітка : BRD та FSD не задокументовані групами з контролю якості. Ми - просто споживачі документів разом з іншими командами проекту.

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

Зразки сценаріїв випробувань з вищезазначених BRD та FSD: ( Завантажте цей зразок тестових сценаріїв тестування )

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

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

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

Ось як виглядала б проста матриця простежуваності для нашого прикладу:

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

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

Результат такий:

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

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

Подивимось як.

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

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

Як правило, будь-які порожні місця в Матриці простежуваності є потенційними областями для дослідження. Тож такий розрив може означати одну з двох речей:

• Тестова група якось пропустила розгляд функціональності “Існуючий користувач”.
• Функціонал 'Існуючий користувач' було відкладено для подальшого використання або вилучено з вимог до функціональності програми. У цьому випадку ТМ демонструє невідповідність FSD або BRD - це означає, що слід виконати оновлення документів FSD та / або BRD.

Якщо це сценарій 1, він буде вказувати місця, де тестовій групі потрібно ще трохи попрацювати, щоб забезпечити 100% покриття.

найкраще програмне забезпечення для ремонту ПК для Windows 10

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

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

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

Завантажте шаблон матриці простежуваності вимог:

=> Шаблон матриці простежуваності у форматі Excel

Важливі зауваження

Нижче наведені важливі моменти щодо цієї версії Матриці простежуваності:

# 1) Також відображається стан виконання. Під час виконання він дає консолідований знімок того, як просувається робота.

# 2) Дефекти: Коли цей стовпець використовується для встановлення зворотної простежуваності, ми можемо сказати, що функціональність «Новий користувач» є найбільш недосконалою. Замість того, щоб повідомляти про те, що ті чи інші тестові випадки не вдалися, TM забезпечує прозорість до вимог бізнесу, що має більшість дефектів, демонструючи, таким чином, якість з точки зору бажань клієнта.

# 3) На наступному етапі ви можете кольоровим кодом ідентифікатора дефекту представити їх стан. Наприклад, Ідентифікатор дефекту червоним може означати, що він все ще відкритий, зеленим може означати, що він закритий. Після цього TM працює, коли звіт про перевірку працездатності, що відображає стан дефектів, що відповідають певним функціональним можливостям BRD або FSD, є відкритим або закритим.

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

Підводячи підсумок, RTM допомагає у:

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

Крім того,

• Матриця простежуваності не є спеціальним інструментом для ручного тестування, вона також може використовуватися для проектів автоматизації. Для проекту автоматизації ідентифікатор тестового випадку може вказувати назву сценарію тесту автоматизації.
• Це також не інструмент, який може використовуватися лише органами контролю якості. Команда розробників може використовувати те саме для відображення вимог BRD / FSD до блоків / одиниць / умов коду, створених, щоб переконатися, що всі вимоги розроблені.
• Інструменти управління тестами, такі як HP ALM поставляються з вбудованою функцією відстеження.

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

Висновок

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

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

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

Про автора: Член команди STH Урміла П. є досвідченим спеціалістом з контролю якості висока якість тестування та навички відстеження проблем.

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

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

• Зразок шаблону плану тестування програмного забезпечення з форматом та змістом
• Як написати ефективний підсумковий звіт про тест (Зразок завантаження звіту)
• Зразок шаблону тестового кейсу з прикладами тестового кейсу (Завантажити)
• Зразок шаблону для звіту про прийомні випробування з прикладами
• Як написати документ про стратегію тестування (із зразком шаблону стратегії тестування)
• Як перевірити специфікацію вимог до програмного забезпечення (SRS)?
• Топ 20+ найкращих інструментів управління вимогами (повний список)
• Контрольні списки тестування програмного забезпечення QA (зразки контрольних списків включені)