how create requirements traceability matrix
Какво представлява изискването за проследяване на матрицата (RTM) при тестване на софтуер: Ръководство стъпка по стъпка за създаване на матрица за проследяване с примери и примерен шаблон
Днешният урок е за важен инструмент за контрол на качеството, който е или прекалено опростен (прочетен пренебрегван), или прекалено подчертан - т.е. Матрица за проследимост (TM).
Най-често изготвянето, прегледът или споделянето на матрица за проследяване не е един от основните резултати от процеса на осигуряване на качеството - така че той не е концентриран в голяма степен върху, като по този начин причинява недостатъчен акцент. Напротив, някои клиенти очакват ТМ да разкрие разрушителни аспекти за техния продукт (в процес на изпитване) и са разочаровани.
„Когато се използва правилно, матрица за проследяване може да бъде вашият GPS за вашето QA пътуване“.
Както е общата практика в STH , ще видим аспектите „Какво“ и „Как“ на ТМ в тази статия.
Какво ще научите:
- Каква е матрицата за проследяване на изискванията?
- Тествайте покритието и проследимостта на изискванията
- Как да създам матрица за проследяване на изискванията
Каква е матрицата за проследяване на изискванията?
В матрицата за проследяване на изискванията или RTM ние създадохме процес на документиране на връзките между потребителските изисквания, предложени от клиента към изгражданата система. Накратко, това е документ на високо ниво за картографиране и проследяване на потребителските изисквания с тестови случаи, за да се гарантира, че за всяко едно изискване се постига адекватно ниво на тестване.
Процесът за преглед на всички тестови случаи, дефинирани за дадено изискване, се нарича проследимост. Проследяемостта ни позволява да определим кои изисквания са породили най-много дефекти по време на процеса на тестване.
Фокусът на всяко тестване е и трябва да бъде максимално покритие на теста. Под покритие това просто означава, че трябва да тестваме всичко, което трябва да бъде тествано. Целта на всеки проект за тестване трябва да бъде 100% покритие на теста.
Изисквания Матрица за проследяване установява начин да се уверим, че поставяме проверки на аспекта на покритието. Помага при създаването на моментна снимка, за да се идентифицират пропуските в покритието. Накратко, това може да се нарече и метрика, която определя броя на тестовите случаи Run, Pass, Failed или Blocked и т.н. за всяко изискване.
Защо се изисква проследяване на изискванията?
Матрицата за проследяване на изискванията помага да се свържат изискванията, Тестови случаи , и дефекти точно. Цялото приложение е тествано чрез проследяване на изискванията ( Тестване от край до край на дадено заявление).
как да генерирам произволни числа в c ++ между 0 и 100
Проследяемостта на изискванията осигурява добро „качество“ на приложението, тъй като всички функции са тествани. Контрол на качеството може да бъде постигнато, тъй като софтуерът се тества за непредвидени сценарии с минимални дефекти и всички функционални и нефункционални изисквания са изпълнени.
Матрицата за проследяване на изискванията помага за софтуерно приложение, което се тества в определената продължителност, обхватът на проекта е добре определен и изпълнението му се постига според изискванията и нуждите на клиента, а цената на проекта е добре контролирана.
Дефектните течове са предотвратени, тъй като цялото приложение е тествано за неговите изисквания.
Видове матрица на проследимост
Проследяване напред
В „Проследимост напред“ Изисквания към тестовите случаи. Той гарантира, че проектът напредва в желаната посока и че всяко изискване е добре тествано.
Проследимост назад
Тестовите случаи са картографирани с Изискванията в „Проследимост назад“. Основната му цел е да гарантира, че настоящият продукт, който се разработва, е на прав път. Също така помага да се определи, че не се добавят допълнителни неопределени функционалности и по този начин се засяга обхватът на проекта.
Двупосочна проследимост
(Напред + Назад): Матрицата за добра проследимост има препратки от тестови случаи към изисквания и обратно (изисквания към тестови случаи). Това се нарича „двупосочна“ проследимост. Той гарантира, че всички тестови случаи могат да бъдат проследени до изискванията и всяко едно от посочените изисквания има точни и валидни тестови случаи за тях.
Примери за RTM
# 1) Изисквания за бизнеса
BR1 : Опцията за писане на имейли трябва да е налична.
Тест сценарий (техническа спецификация) за BR1
TS1 : Предоставена е опция за съставяне на поща.
Тестови случаи:
Тест 1 (TS1.TC1) : Опцията за съставяне на поща е активирана и работи успешно.
Тест 2 (TS1.TC2) : Опцията за съставяне на поща е деактивирана.
# 2) Дефекти
След изпълнение на тестовите случаи, ако се открият дефекти, които също могат да бъдат изброени и картографирани с бизнес изискванията, тестовите сценарии и тестовите случаи.
Например, Ако TS1.TC1 се провали, т.е. опцията за съставяне на поща, въпреки че е активирана, не работи правилно, тогава може да се регистрира дефект. Да предположим, че автоматично генерираният или ръчно присвоен номер на дефекта е D01, тогава той може да бъде картографиран с номера BR1, TS1 и TS1.TC1.
По този начин всички Изисквания могат да бъдат представени в табличен формат.
| Бизнес изискване # | Тестов сценарий # | Тестов случай # | Дефекти # |
|---|---|---|---|
| BR1 | TS1 | TS1.TC1 TS1.TC2 | D01 |
| BR2 | TS2 | TS2.TC1 TS2, TC2 TS2.TC3 | D02 D03 |
| BR3 | TS3 | TS1.TC1 TS2.TC1 TS3.TC1 TS3.TC2 | НИЛ |
Тествайте покритието и проследимостта на изискванията
Какво е покритие на теста?
Test Coverage посочва кои изисквания на клиентите трябва да бъдат проверени, когато започне фазата на тестване. Тестовото покритие е термин, който определя дали тестовите случаи са написани и изпълнени, за да се гарантира пълното тестване на софтуерното приложение по такъв начин, че да се отчитат минимални или NIL дефекти.
Как да постигна тестово покритие?
Максималното покритие на теста може да бъде постигнато чрез установяване на добра „проследимост на изискванията“.
- Картографиране на всички вътрешни дефекти към проектираните тестови случаи
- Съпоставяне на всички докладвани от клиента дефекти (CRD) в отделни тестови случаи за бъдещия пакет за регресионно тестване
Видове спецификации на изискванията
# 1) Бизнес изисквания
Действителните изисквания на клиентите са изброени в документ, известен като Документ за бизнес изисквания (BRS) . Този BRS е подробно извлечен списък с изисквания на високо ниво след кратко взаимодействие с клиента.
Обикновено се изготвя от „Бизнес анализатори“ или от проекта „Архитект“ (в зависимост от организацията или структурата на проекта). Документът „Спецификации на софтуерните изисквания“ (SRS) е извлечен от BRS.
# 2) Документ за спецификация на софтуерните изисквания (SRS)
Това е подробен документ, който съдържа всички подробни подробности за всички функционални и нефункционални изисквания. Този SRS е базовата линия за проектиране и разработване на софтуерни приложения.
# 3) Документи за проектни изисквания (PRD)
PRD е референтен документ за всички членове на екипа в даден проект, за да им каже точно какво трябва да направи един продукт. Тя може да бъде разделена на секции като Предназначение на продукта, Характеристики на продукта, Критерии за пускане и Бюджет и график на проекта.
# 4) Използвайте документ за дело
Това е документът, който помага при проектирането и внедряването на софтуера според нуждите на бизнеса. Той картографира взаимодействията между актьор и събитие с роля, която трябва да бъде изпълнена, за да се постигне цел. Това е подробно стъпка по стъпка описание на начина, по който дадена задача трябва да бъде изпълнена.
Например,
Актьор: Клиент
Роля: Изтеглете играта
Изтеглянето на играта е успешно.
Случаите на използване също могат да бъдат част, включена в документа за SRS, съгласно работния процес на организацията.
# 5) Документ за проверка на дефекти
Той е документиран, съдържащ всички подробности, свързани с дефекти. Екипът може да поддържа документ „Проверка на дефекти“ за отстраняване и повторно тестване на дефектите. Тестерите могат да се позоват на документа „Проверка на дефекти“, когато искат да проверят дали дефектите са отстранени или не, да тестват отново дефекти на различна операционна система, устройство, различна конфигурация на системата и т.н.
Документът „Проверка на дефекти“ е удобен и важен, когато има специална фаза за отстраняване и проверка на дефекти.
# 6) Потребителски истории
Потребителската история се използва предимно при разработването на „Agile“, за да опише софтуерна функция от гледна точка на крайния потребител. Потребителските истории определят видовете потребители и по какъв начин и защо те искат определена функция. Изискването се опростява чрез създаване на потребителски истории.
В момента всички софтуерни индустрии се насочват към използването на потребителски истории и гъвкаво развитие и съответните софтуерни инструменти за записване на изискванията.
Предизвикателства пред събирането на изисквания
# 1) Събраните изисквания трябва да бъдат подробни, недвусмислени, точни и добре уточнени. Но те са НЕДЕЙ подходяща мярка за изчисляване на тези подробности, недвусмисленост, точност и добре дефинирани спецификации, които са необходими за събирането на изискванията.
# две) Тълкуването на „Бизнес анализатор“ или „Собственик на продукт“, който предоставя информацията за изискванията, е критично важно. По подобен начин екипът, който получава информацията, трябва да направи подходящи разяснения, за да разбере очакванията на заинтересованите страни.
Разбирането трябва да е в синхрон както с бизнес нуждите, така и с действителните усилия, необходими за изпълнението на приложението.
# 3) Информацията също трябва да бъде получена от гледната точка на крайния потребител.
# 4) Държавите на заинтересованите страни противоречат или противоречат на изискванията по различно време.
# 5) Гледната точка на крайния потребител не се разглежда поради множество причини и други заинтересовани страни смятат, че „напълно“ разбират какво се изисква за даден продукт, което обикновено не е така.
# 6) Разработени ресурси с липса на умения за кандидатстване.
# 7) Чести промени в обхвата на приложението или промяна на приоритета за модулите.
# 8) Пропуснати, неявни или недокументирани изисквания.
# 9) Несъответстващи или неясни изисквания, определени от клиентите.
# 10) Заключението на всички посочени по-горе фактори е, че „успехът“ или „неуспехът“ на даден проект зависи значително от дадено изискване.
Как проследяемостта на изискванията може да помогне
# 1) Къде е изпълнено изискване?
Например,
Изискване: Внедрете функцията „Съставяне на поща“ в пощенско приложение.
Изпълнение: Където на главната страница трябва да бъде поставен и достъпен бутонът „Създаване на поща“.
най-добрата безплатна защитна стена за Windows XP
# 2) Необходимо ли е изискване?
Например,
Изискване: Внедрете функцията „Съставяне на поща“ в пощенско приложение само за определени потребители.
Изпълнение: Според правата за достъп на потребителя, ако входящата поща на имейл е „Само за четене“, в този случай бутонът „Създаване на поща“ няма да е необходим.
# 3) Как да тълкувам изискване?
Например,
Изискване: Функция „Съставяне на поща“ в пощенско приложение със шрифтове и прикачени файлове.
Изпълнение: Когато щракнете върху „Създаване на поща“, кои всички функции трябва да бъдат предоставени?
- Текстово тяло, за да пише имейли и да редактира с различни типове шрифтове, а също така получер, курсив, да ги подчертава
- Видове прикачени файлове (изображения, документи, други имейли и др.)
- Размер на прикачените файлове (Максимално разрешен размер)
По този начин Изискванията се разбиват на под-изисквания.
# 4) Какви дизайнерски решения влияят върху изпълнението на изискване?
Например,
Изискване: Всички елементи „Вх. Поща“, „Изпратена поща“, „Чернови“, „Спам“, „Кошче“ и др. Трябва да бъдат ясно видими.
Изпълнение: Елементите, които трябва да бъдат видими, трябва да се показват във формата „Дърво“ или „Tab“.
# 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 )
регулярен израз в c ++
Забележка : BRD и FSD не са документирани от екипите за QA. Ние сме просто потребители на документите, заедно с останалите екипи по проекта.
Въз основа на горните два входящи документа, като екип за осигуряване на качеството, измислихме списъка със сценарии на високо ниво по-долу, които да тестваме.
Примерни тестови сценарии от горепосочените BRD и FSD: ( Изтеглете този файл с примерни тестови сценарии )
След като пристигнем тук, сега би било подходящо време да започнем да създаваме матрицата за проследяване на изискванията.
Аз лично предпочитам много прост Excel лист с колони за всеки документ, който искаме да проследим. Тъй като бизнес изискванията и функционалните изисквания не са номерирани еднозначно, ще използваме номерата на разделите в документа за проследяване.
(Можете да изберете да проследявате въз основа на номера на редове или номера на маркирани точки и т.н., в зависимост от това, което е най-смислено за вашия конкретен случай.)
Ето как би изглеждала проста матрица на проследимост за нашия пример:
Горният документ установява следа между BRD до FSD и в крайна сметка до тестовите сценарии. Създавайки документ като този, можем да се уверим, че всеки аспект от първоначалните изисквания е бил взет под внимание от екипа за тестване при създаването на техните тестови пакети.
Можете да го оставите по този начин. За да го направя по-четлив обаче, предпочитам да включа имената на разделите. Това ще подобри разбирането, когато този документ се споделя с клиента или друг екип.
Резултатът е както по-долу:
Отново изборът да използвате предишния или по-късния формат е ваш.
Това е предварителната версия на вашата TM, но като цяло не служи по предназначение, когато спрете тук. Максимални ползи могат да бъдат получени от него, когато го екстраполирате чак до дефекти.
Нека да видим как.
За всеки тестов сценарий, който сте измислили, ще имате поне 1 или повече тестови случая. Така че, включете друга колона, когато стигнете там и напишете идентификатори на тестовия случай, както е показано по-долу:
На този етап матрицата на проследимостта може да се използва за намиране на пропуски. Например, в горната Матрица за проследимост виждате, че няма написани тестови случаи за раздел 1.2 на FSD.
Като общо правило, всички празни пространства в матрицата на проследимостта са потенциални области за разследване. Така че празнина като тази може да означава едно от двете неща:
- Тестовият екип по някакъв начин пропусна да разгледа функционалността „Съществуващ потребител“.
- Функционалността „Съществуващ потребител“ е отложена за по-късно или е премахната от изискванията за функционалност на приложението. В този случай TM показва несъответствие в FSD или BRD - което означава, че трябва да се направи актуализация на FSD и / или BRD документи.
Ако е сценарий 1, той ще посочи местата, където тестовият екип трябва да работи още малко, за да осигури 100% покритие.
В сценарии 2, TM не просто показва пропуски, тя сочи към неправилна документация, която се нуждае от незабавна корекция.
Нека сега разширим TM, за да включим състоянието на изпълнение на тестовия случай и дефекти.
Долната версия на матрицата за проследяване обикновено се изготвя по време или след изпълнението на теста:
Изтеглете шаблон за матрица за проследяване на изискванията:
=> Шаблон за матрица на проследимост във формат Excel
Важни точки за отбелязване
По-долу са важните моменти, които трябва да се отбележат за тази версия на матрицата за проследяване:
# 1) Показва се и състоянието на изпълнение. По време на изпълнението дава консолидирана снимка на напредъка на работата.
# 2) Дефекти: Когато тази колона се използва за установяване на обратната проследимост, можем да кажем, че функционалността „Нов потребител“ е най-недостатъчна. Вместо да докладва, че така и така тестовите случаи са неуспешни, TM предоставя прозрачност обратно на бизнес изискването, което има най-много дефекти, като по този начин демонстрира Качеството по отношение на това, което клиентът желае.
# 3) Като следваща стъпка можете да оцветите кода на дефекта, за да представите техните състояния. Например, Идентификацията на дефекти в червено може да означава, че все още е отворена, а в зелено може да означава, че е затворена. Когато това е направено, TM работи като доклад за проверка на състоянието, показващ състоянието на дефектите, съответстващи на определена BRD или FSD функционалност, е отворен или затворен.
# 4) Ако има документ за технически дизайн или случаи на употреба или други артефакти, които бихте искали да проследите, винаги можете да разширите създадения по-горе документ според вашите нужди, като добавите допълнителни колони.
В обобщение, RTM помага за:
- Осигуряване на 100% покритие на теста
- Показване на несъответствия в изискванията / документа
- Показване на цялостното състояние на дефекти / изпълнение с фокус върху бизнес изискванията.
- Ако дадено бизнес и / или функционално изискване трябва да се промени, TM помага да се оцени или анализира въздействието върху работата на екипа за QA по отношение на преразглеждане / преработка на тестовите случаи.
Освен това,
- Матрицата за проследимост не е специфичен инструмент за ръчно тестване, тя може да се използва и за проекти за автоматизация. За проект за автоматизация идентификаторът на тестовия случай може да указва името на скрипта за автоматизация на теста.
- Това също не е инструмент, който може да се използва само от QA. Екипът за разработка може да използва същото, за да картографира изискванията на BRD / FSD към блокове / единици / условия на кода, създадени, за да се увери, че всички изисквания са разработени.
- Инструменти за управление на тестове като HP ALM идват с вградената функция за проследяване.
Важен момент, който трябва да се отбележи е, ченачинът, по който поддържате и актуализирате вашата проследяваща матрица, определя ефективността на нейното използване. Ако не се актуализира често или се актуализира неправилно, инструментът е в тежест, вместо да бъде помощ и създава впечатлението, че инструментът сам по себе си не е достоен за използване.
Заключение
Матрицата за проследяване на изискванията е средство за карта и проследяване всички изисквания на клиента с тестовите случаи и откритите дефекти. Това е единичен документ което служи на основната цел да не се пропускат тестови случаи и по този начин се обхваща и тества всяка функционалност на приложението.
Доброто „Тестово покритие“, което се планира преди време, предотвратява повтарящи се задачи във фазите на тестване и изтичане на дефекти. Високият брой на дефектите показва, че тестването е извършено добре и по този начин ‘Качеството’ на приложението се повишава. По същия начин много нисък брой дефекти показва, че тестването не е извършено до марката и това затруднява отрицателно „Качеството“ на приложението.
Ако тестовото покритие е извършено старателно, тогава нисък брой дефекти може да бъде оправдан и този брой дефекти може да се счита за поддържаща статистика, а не за първична. Качеството на приложението се нарича „добро“ или „удовлетворяващо“, когато тестовото покритие е максимизирано и броят на дефектите е сведен до минимум.
За автора: Членът на екипа на STH Урмила П. е опитен QA професионалист с високо качество умения за тестване и проследяване на проблеми.
Създали ли сте матрица за проследяване на изискванията във вашите проекти? Колко подобно или различно е от това, което сме създали в тази статия? Моля, споделете вашия опит, коментари, мисли и отзиви за тази статия чрез вашите коментари.
Препоръчително четене
- Примерен шаблон за план за тестване на софтуер с формат и съдържание
- Как да напиша ефективен обобщен отчет на теста [Примерен отчет за изтегляне]
- Примерен шаблон за тестови случаи с примери за тестови случаи [Изтегляне]
- Примерен шаблон за доклад за изпитване за приемане с примери
- Как да напиша документ за тестова стратегия (с примерен шаблон за тестова стратегия)
- Как да тествате спецификацията на софтуерните изисквания (SRS)?
- Топ 20+ Инструменти за управление на най-добрите изисквания (Пълният списък)
- Контролните списъци за тестване на софтуера QA (включени примерни контролни списъци)