difference between test plan
Научете каква е разликата между тестовия план, тестовата стратегия, тестовия случай, тестовия скрипт, сценария на теста и състоянието на теста с примери:
Софтуерното тестване включва няколко основни, както и важни концепции, които всеки тестващ софтуер трябва да знае.
Тази статия ще обясни различните понятия в софтуерното тестване заедно с тяхното сравнение.
Тестов план срещу тестова стратегия, тестов случай срещу тестов скрипт, тестов сценарий срещу тестово състояние и тестова процедура срещу тестов пакет са обяснени подробно за вашето лесно разбиране.
=> Щракнете тук за пълна серия уроци за план за тестване
Горният въпрос, зададен от Sasi C., е най-често задаваният въпрос в нашия Клас за тестване на софтуер и винаги казвам на нашите участници, че с опита почти не забелязваме тези думи и че те стават част от нашия речник.
Но често объркването ги заобикаля и в тази статия се опитвам да дефинирам няколко често използвани термина.
Различни концепции за тестване на софтуер
По-долу са изброени различните концепции за тестване на софтуер, заедно с тяхното сравнение.
Да започваме!!
Какво ще научите:
- Разлика между тестовия план и тестовата стратегия
- Разлика между тестовия случай и тестовия скрипт
- Разлика между сценария на теста и състоянието на теста
- Разлика между тестовата процедура и тестовия пакет
- Заключение
Разлика между тестовия план и тестовата стратегия
Тестовата стратегия и тестовият план са два важни документа в жизнения цикъл на тестване на всеки проект. Тук се опитваме да ви дадем задълбочени познания за тестовата стратегия и документите от плана за тестване.
План за тестване
Тестовият план може да бъде определен като документ, който определя обхвата, целта и подхода за тестване на софтуерното приложение. Тестовият план е термин и резултат.
Тестовият план е документ, който изброява всички дейности в даден QA проект, планира ги, определя обхвата на проекта, ролите и отговорностите, рисковете, критериите за влизане и излизане, целта на теста и всичко друго, за което можете да се сетите.
Тестовият план е така, както аз обичам да наричам „супер документ“, който изброява всичко, което трябва да се знае и трябва. Моля те проверете тази връзка за повече информация и проба.
Планът за изпитване ще бъде разработен въз основа на изискванията. Докато възлага работата на тестовите инженери, поради някои причини един от тестерите се заменя с друг. Тук планът за тестване се актуализира.
Тестовата стратегия очертава тестовия подход и всичко останало, което го заобикаля. Той се различава от тестовия план, в смисъл, че тестовата стратегия е само подмножество от тестовия план. Това е твърд тестов документ, който до известна степен е общ и статичен. Съществува и спор за това на какви нива се използва стратегия или план за тестване, но аз наистина не виждам някаква различителна разлика.
Пример: Планът за тестване дава информация за това кой в кой момент ще тества. Например, Модул 1 ще бъде тестван от „X тестер“. Ако тестер Y замени X по някаква причина, планът на теста трябва да бъде актуализиран.
Документ за план за изпитване
Тестовият план е документ, който предоставя пълна информация за тестовите задачи, свързани със софтуерен проект. Той предоставя подробности като обхват на тестването, видове тестове, цели, методология на теста, усилия за тестване, рискове и непредвидени обстоятелства, критерии за освобождаване, резултати от теста и др. Той проследява възможните тестове, които ще бъдат изпълнени в системата след кодиране.
Планът на теста очевидно е настроен да се промени. Първоначално ще бъде разработен проект на план за изпитване въз основа на яснотата на проекта по това време. Този първоначален план ще бъде модифициран с напредването на проекта. Ръководителят на тестовия екип или ръководителят на теста може да подготви документа за тестовия план. Той описва спецификациите и подлежи на промяна въз основа на същите.
Какво да тествате, кога да тествате, кой ще тества и как да тествате ще бъде определено в плана за тестване. Тестовият план ще подреди списък с проблеми, зависимости и основните рискове.
Видове план за изпитване
Тестовите планове могат да бъдат от различен тип въз основа на етапа на тестване. Първоначално ще има план за главен тест за цялото изпълнение на проекта. Могат да се създадат отделни планове за изпитване за специфични типове тестове като системно тестване, тестване на системна интеграция, тестване за приемане от потребителя и т.н.
Друг подход е да има отделни планове за тестване за функционално и нефункционално тестване. При този подход, тестването ще има отделен план за тестване.
c ++ въпроси за интервю за опитни професионалисти
Съдържание на документа за план за изпитване ( Структура на тестовия план на IEEE-829 )
Трудно е да се изготви ясен формат за тестовия план. Форматът на тестовия план може да варира в зависимост от конкретния проект. IEEE дефинира стандарт за тестови планове, които са описани като структура на тестовия план IEEE-829.
Вижте по-долу препоръките на IEEE за стандартно съдържание на план за тестване:
- Идентификатор на тестовия план
- Въведение
- Тестови елементи
- Проблеми със софтуерния риск
- Характеристики за тестване
- Характеристики, които не се тестват
- Приближаване
- Критерии за приемане / неуспех на артикула (или) Критерии за приемане
- Критерии за спиране и изисквания за възобновяване
- Тестови резултати
- Тестови задачи
- Изисквания за околната среда
- Нужди от персонал и обучение
- Отговорности
- График
- Одобрения
Предложено четене => Урок за тестов план - перфектно ръководство
Тестова стратегия
Тестовата стратегия е набор от насоки, които обясняват дизайна на теста и определят как трябва да се направи тестване.
Пример: Тестовата стратегия включва подробности като „Отделните модули трябва да бъдат тествани от членовете на тестовия екип“. В този случай кой тества не е от значение - така че е общ и промяната в члена на екипа не трябва да се актуализира, като се запазва статична.
Документ за тестова стратегия
Целта на тестовата стратегия е да дефинира подхода за тестване, видовете тестове, тестовите среди и инструментите, които ще се използват за тестване, и подробностите на високо ниво за това как тестовата стратегия ще бъде приведена в съответствие с други процеси. Документът за тестова стратегия е предназначен да бъде жив документ и ще бъде актуализиран **, когато получим повече яснота относно Изискванията, параметрите на SLA, тестовата среда и подхода за управление на изграждането и т.н.
Тестовата стратегия е предназначена за пълния екип на проекта, който се състои от спонсори на проекти, бизнес МСП, разработване на приложения / интеграция, партньори за системна интеграция, екипи за преобразуване на данни, екипи за управление на изграждане / пускане, като технически ръководители, ръководители на архитектура и екипи за внедряване и инфраструктура.
** Някои твърдят, че веднъж дефинираната тестова стратегия никога не трябва да се актуализира. В повечето проекти за тестване обикновено се актуализира с напредването на проекта.
По-долу са важните раздели, които трябва да има документ за стратегия за тестване:
# 1) Преглед на проекта
Този раздел може да започне с преглед на организацията, последван от кратко описание на проекта. Може да включва подробности по-долу
- Каква беше необходимостта от проекта?
- Какви цели ще постигне проектът?
Таблица на съкращенията: По-добре е да включите таблица със съкращения, които четецът на документи може да измисли, докато се позовава на документа.
# 2) Обхват на изискванията
Обхватът на изискванията може да включва обхват на приложението и функционален обхват
Обхват на приложение дефинира тестваната система и въздействието върху системата поради нова или променена функционалност. Свързани системи също могат да бъдат дефинирани.
| Система | Въздействие (нова или променена функционалност) | Свързана система |
|---|---|---|
| Той описва как да тествате, кога да тествате, кой ще тества и какво да тествате. | Той описва какъв тип техника да следва и кой модул да тества. | |
| Система A | Нови подобрения и корекции на грешки | • Система Б • Система C |
Функционален обхват дефинира въздействието върху различни модули в системата. Тук ще бъде обяснена всяка свързана система по отношение на функционалността.
| Система | Модул | Функционалност | Свързана система |
|---|---|---|---|
| Система C | Модул 1 | Функционалност 1 | Система Б |
| Функционалност 2 | Система C |
# 3) План за тестване на високо ниво
Тестовият план е отделен документ. В тестовата стратегия може да бъде включен план за тестване на високо ниво. Тестовият план на високо ниво може да включва цели на теста и обхват на теста. Обхватът на теста трябва да определя както обхват, така и дейности извън обхвата.
# 4) Тестов подход
Този раздел описва подхода за тестване, който ще се следва по време на жизнения цикъл на тестването.
Съгласно горната диаграма тестването ще се проведе на две фази, т.е. стратегия за тестване и планиране и изпълнение на теста. Фазата на тестване на стратегия и планиране ще бъде еднократна за обща програма, докато фазите за изпълнение на теста ще бъдат повторени за всеки цикъл от общата програма. Горната диаграма показва различни етапи и резултати (резултат) във всяка фаза на подхода за изпълнение.
Тестовият подход трябва да включва по-долу подраздели
а) График на теста: Обяснете предложената времева линия на проекта в този подраздел
б) Подход за функционално тестване: Използването на този подраздел предоставя преглед на всяка фаза и съответните критерии за влизане и излизане. Различните фази на тестване са модулно тестване, тестване на системата, тестване на системната интеграция, тестване за приемане от потребителя и тестване от край до край.
в) Тестване на ключови показатели за ефективност:
- Приоритизиране на тестови случаи: Определете подхода за приоритизиране на тестовите случаи, така че в случай на времеви ограничения, сценариите с висок приоритет да могат да бъдат изпълнени от тестовия екип. Трябва да има споразумение между заинтересованите страни по проекта относно възможните рискове, свързани с неизпълнението на всички планирани сценарии.
- Приоритизиране на дефекти: Стратегията за приоритизиране на дефекти е следващата тема, която ще разгледаме тук. Определете нивото на приоритет и дайте описанието на всяко ниво като критично, високо, средно и др. Също така
- Време за отстраняване на дефекти: Времето за отстраняване на дефекта се определя като времето между първото повдигане на дефекта и когато дефектът е отстранен и идва за повторно тестване. Бързото изпълнение гарантира бързо тестване и спазване на графика на проекта. За всяко ниво на приоритет на дефекта дефинирайте времето за изпълнение.
| Приоритетно ниво | Време за отстраняване на дефекти |
|---|---|
| 1 - критично | Време за реакция: 2 часа или по-малко Коригиране на готовност за миграция: 1 работен ден или по-малко |
# 5) Тестово покритие
Този раздел описва процесите, които екипът за осигуряване на качеството ще следва, за да оптимизира покритието на бизнес / функционални изисквания в тестови сценарии и тестови случаи. Матрица за проследяване на изискванията: (RTM) може да се използва за проследяване на всички изисквания със съответните тестови сценарии и тестови случаи.
# 6) Тестова среда
Дефинирайте различните налични QA среди. Споменете какво тестване ще бъде направено в коя среда и от кого. Създайте план за архивиране на околната среда, за да се грижите за извънредни ситуации. Достъпът до всяка среда трябва да бъде регулиран и извикан с яснота.
Инструменти за тестване, които ще бъдат използвани, също могат да бъдат споменати в този раздел.
| Дейност | Инструмент | Забележки |
|---|---|---|
| Управление на тестове | HP ALM | Споменете причината за използването на този инструмент |
| Управление на дефекти | JIRA | Споменете причината за използването на този инструмент |
# 7) QA Резултати и показатели
Избройте всички резултати от QA
| S. Не. | Доставим |
|---|---|
| 1 | Документ за тестова стратегия |
| две | Матрица за проследяване на изискванията |
| 3 | Сценарии за тест ST |
| 4 | Обобщен отчет на теста |
| 5 | Списък на сценариите, отговарящи на условията за автоматизация |
Избройте всички показатели за осигуряване на качеството
| # | Име на метриката | Определение на метриката | Метрична формула | Метрична мерна единица | Доклади, в които да се използват показателите |
|---|---|---|---|---|---|
| 1 | Показатели за покритие на изискванията (RCM) | Покритието на изискванията от QA | Съотношение между # тествани изисквания и # идентифицирани изисквания | % | Седмичен отчет за състоянието на качеството, Резюме на теста |
| две | Тестово покритие | Покритието на изпълнения тест | Съотношение между броя изпълнени тестови случаи / планирания брой тестови случаи | % | Ежедневен отчет за изпълнение, Седмичен отчет за състоянието на качеството, Резюме на теста |
# 8) Управление на дефекти
Ясно дефинирайте стратегия за управление на дефекти, като създадете работен процес на дефекти, методология за проследяване на дефектите и процес на триаж на дефекти. Споменете дефектната отговорност за ролите на всеки изпитател. Периодичният анализ на дефектите и анализът на първопричините ще подобрят цялостното качество на тестването
# 9) Управление на комуникацията
Задайте насоки за доклади за състоянието, срещи за състоянието и офшорна комуникация.
# 10) Предположения, рискове и зависимости
Опишете предположения, на които се основава проектът. Те могат да включват време, ресурси и системни възможности. Опишете всякакви зависимости като други проекти, наличие на временни ресурси, други срокове, които могат да повлияят на проекта
# 11) Приложение
Включете в този раздел неща като роли и отговорности, работна зона и справки
Допълнителна информация=> Ръководство за писане на документ за добра тестова стратегия .
Тестов план срещу тестова стратегия
| ПЛАН ЗА ИЗПИТВАНЕ | ТЕСТОВА СТРАТЕГИЯ |
|---|---|
| Той е получен от спецификацията на софтуерните изисквания (SRS). | Той е извлечен от документа за бизнес изисквания (BRS). |
| Изготвя се от ръководителя на теста или ръководителя. | Той е разработен от ръководителя на проекта или бизнес анализатора. |
| Идент. № на тестовия план, функции, които трябва да бъдат тествани, тестови техники, тестови задачи, критерии за преминаване или неуспех на критериите за изпълнение, тестови резултати, отговорности и график и т.н. | Целите и обхватът, форматите на документацията, тестовите процеси, структурата за отчитане на екипа, комуникационната стратегия на клиента и т.н. са компонентите на тестовата стратегия. |
| Ако има нова функция или промяна в изискването, което се е случило, документът за тестовия план се актуализира. | Тестовата стратегия поддържа стандартите, докато подготвя документа. Той се нарича още статичен документ. |
| Можем да изготвим индивидуално тестовия план. | При по-малки проекти тестовата стратегия често се среща като част от тестовия план. |
| Можем да изготвим план за изпитване на ниво проект. | Можем да използваме тестова стратегия в множество проекти. |
| Можем да опишем за спецификациите, като използваме Тестов план. | Тестовата стратегия описва общите подходи. |
| Тестовият план ще се промени в хода на проекта. | Тестовата стратегия обикновено няма да се промени, след като бъде одобрена. |
| Планът за изпитване се изписва след излизане от изискването. | Тестовата стратегия се прави преди тестовия план. |
| Тестовите планове могат да бъдат от различен тип. Ще има главен план за изпитване и отделен план за изпитване за различни видове изпитвания като план за изпитване на системата, план за изпитване на производителността и т.н. | За даден проект ще има само един документ за стратегия за тестване. |
| Планът за изпитване трябва да бъде ясен и кратък. | Тестовата стратегия предоставя цялостни насоки за текущия проект. |
Разликата между тези два документа е фина. Тестовата стратегия е статичен документ на високо ниво за проекта. От друга страна, планът за тестване ще посочи какво да тествате, кога да тествате и как да тествате.
Разлика между тестовия случай и тестовия скрипт
Според мен тези два термина могат да се използват взаимозаменяемо. Да, казвам, че няма разлика. Тестовият случай е последователност от стъпки, които ни помагат да извършим определен тест върху приложението. Тестовият скрипт също е същото.
Сега има една школа на мисълта, че тестовият случай е термин, използван в средата за ръчно тестване, а тестовият скрипт се използва в среда за автоматизация. Това отчасти е вярно, поради нивото на комфорт на тестерите в съответните полета, както и за това как инструментите се отнасят към тестовете (някои извикват скриптове за тестване, а други ги извикват за тестови случаи).
Така че на практика тестовият скрипт и тестовият случай са стъпки, които трябва да бъдат изпълнени на приложение, за да се провери неговата функционалност, независимо дали ръчно или чрез автоматизация.
Допълнителна информация=> Как да пиша ефективни тестови случаи? и Шаблон за пример за тест .
| ТЕСТОВ СЛУЧАЙ | ТЕСТОВ СЦЕНАРИЙ |
|---|---|
| Това е основната форма за тестване на приложение в последователност. | След като разработим, скриптът ще го стартира няколко пъти, докато изискването не бъде променено. |
| Това е стъпка по стъпка по процедура, която се използва за тестване на приложение | Това е набор от инструкции за автоматично тестване на приложение. |
| Терминът Test Case се използва в средата за ръчно тестване. | Терминът Test Script се използва в автоматизираната среда за тестване. |
| Прави се ръчно. | Извършва се чрез скриптов формат. |
| Той е разработен под формата на шаблони. | Той е разработен под формата на скриптове. |
| Шаблонът на тестовия случай включва ID на тестовия костюм, тестови данни, тестова процедура, действителни резултати, очаквани резултати и т.н. | В Test Scrip можем да използваме различни команди за разработване на скрипт. |
| Използва се за тестване на приложение. | Използва се и за тестване на приложение. |
| Пример: Трябва да проверим бутона за вход в приложение, Стъпките включват: а) Стартирайте приложението. б) Проверете дали бутонът за вход се показва или не. | Пример: Искаме да щракнем върху бутон за изображение в приложение. Сценарият включва: а) Щракнете върху бутона Изображение. |
Разлика между сценария на теста и състоянието на теста
Тест сценарий: Това е начин да се дефинират всички възможни начини за тестване на приложение. Това е едно изявление, което обхваща всички възможни начини за тестване на приложение.
Условие на теста: Тестово условие е спецификацията, която тестващият трябва да следва, за да тества приложение.
Това е едноредов указател, който тестерите създават като начална преходна стъпка във фазата на проектиране на теста. Това е предимно едноредова дефиниция на „Какво“, което ще тестваме по отношение на определена характеристика. Обикновено тестовите сценарии се въвеждат за създаването на тестови случаи.
В гъвкавите проекти тестовите сценарии са единствените резултати от тестовия дизайн и не се пишат тестови случаи след тях. Тестовият сценарий може да доведе до множество тестове.
Примери за тестови сценарии:
- Проверете дали администраторът може да добави нова държава
- Проверете дали съществуващата държава може да бъде изтрита от администратора
- Проверете дали съществуваща държава може да бъде актуализирана
Условията на теста, от друга страна, са по-специфични. Може грубо да се определи като цел / цел на определен тест.
Примерно състояние на теста: В горния пример, ако трябва да тестваме сценарий 1, можем да тестваме следните условия:
- Въведете името на държавата като „Индия“ (валидно) и проверете за добавяне на страната
- Въведете празно място и проверете дали държавата се добавя.
- Във всеки случай са описани конкретните данни и целта на теста е много по-точна.
Допълнителна информация=> 180+ примерни тестови сценария за тестване на уеб и настолни приложения.
| СЦЕНАРИЙ ЗА ИЗПИТВАНЕ | УСЛОВИЕ НА ИЗПИТВАНЕ |
|---|---|
| Това са едноредови изявления, които обясняват какво ще тестваме. | Условие на теста описва основната цел за тестване на приложение. |
| Това е процес за тестване на приложение с всички възможни начини. | Тестовите условия са статичните правила, които трябва да се спазват, за да се тества приложение. |
| Тестовите сценарии са вход за създаване на тестови случаи. | Тя дава основната цел да тествате приложение. |
| Тестовият сценарий обхваща всички възможни случаи за тестване на приложение. | Състоянието на теста е много специфично. |
| Намалява сложността. | Това прави системна грешка безплатна. |
| Тестовият сценарий може да бъде единичен или група тестови случаи. | Това е целта на тестовите случаи. |
| Чрез писане на сценарии ще бъде лесно да се разбере функционалността на дадено приложение. | Състоянието на теста е много специфично. |
| Примери за тестови сценарии: # 1) Проверете дали администраторът може да добави нова държава. # 2) Проверете дали съществуващата държава може да бъде изтрита от администратора. # 3) Проверете дали съществуваща държава може да бъде актуализирана. | Примери условия за изпитване: # 1) Въведете името на държавата като „Индия“ и проверете за добавяне на страната. # 2) Оставете празни полета и проверете дали държавата се добавя. |
Разлика между тестовата процедура и тестовия пакет
Тестовата процедура е комбинация от тестови случаи, базирани на определена логична причина, като изпълнение на ситуация от край до край или нещо подобно. Редът, в който трябва да се изпълняват тестовите случаи, е фиксиран.
Процедура за изпитване: Това не е нищо друго освен тестовия жизнен цикъл. Има 10 стъпки в тестовия жизнен цикъл.
Те са:
- Оценка на усилията
- Иницииране на проект
- Системно проучване
- План за изпитване
- Тестова кутия за дизайн
- Тестова автоматизация
- Изпълнете тестови случаи
- Докладвайте за дефекти
- Тестване на регресия
- Анализ и обобщен доклад
Например , ако трябваше да тествам изпращането на имейл от Gmail.com, редът на тестовите случаи, които бих комбинирал, за да формирам тестова процедура, ще бъде:
- Тестът за проверка на данните за вход
- Тестът за съставяне на имейл
- Тестът за прикачване на един / повече прикачени файлове
- Форматиране на имейла по необходимия начин чрез използване на различни опции
- Добавяне на контакти или имейл адреси към полетата To, BCC, CC
- Изпращане на имейл и уверяване, че се показва в раздела „Изпратени съобщения“
Всички тестови случаи по-горе са групирани, за да се постигне определена цел в края им. Също така, тестовите процедури включват няколко тестови случая, комбинирани във всеки момент от времето.
Тестовият пакет, от друга страна, е списъкът на всички тестови случаи, които трябва да бъдат изпълнени като част от тестов цикъл или фаза на регресия и т.н. Няма логическо групиране въз основа на функционалността. Редът, в който се изпълняват съставните тестови случаи, може да е или не е важен.
Тестови пакет: Test Suite е контейнер, който има набор от тестове, които помагат на тестерите при изпълнение и докладване на състоянието на изпълнение на теста. Може да отнеме всяко от трите състояния, т.е. Активно, в процес на изпълнение и завършено.
Пример за тестовия пакет : Ако текущата версия на приложението е 2.0. Предишната версия 1.0 може да е имала 1000 тестови случая, за да я изпробва изцяло. За версия 2 има 500 тестови случая, за да тествате новата функционалност, добавена в новата версия.
Така че, текущият набор от тестове ще бъде 1000 + 500 тестови случая, които включват както регресия, така и новата функционалност. Комплектът също е комбинация, но ние не се опитваме да постигнем целева функция.
Тестовите пакети могат да съдържат 100 или дори 1000 случая на тестове.
| ПРОЦЕДУРА НА ИЗПИТВАНЕ | ТЕСТЕН СУИТ |
|---|---|
| Създаването на процедури за изпитване се основава на теста от край до край. | Тестовите набори се създават въз основа на цикъла или въз основа на обхвата. |
| Това е комбинация от тестови случаи за тестване на приложение. | Това е група от тестови случаи за тестване на приложение. |
| Това е логично групиране въз основа на функционалността. | Няма логическо групиране въз основа на функционалността. |
| Процедурите за тестване са продукти за доставка в процеса на разработване на софтуер. | Изпълнява се като част от тестовия цикъл или регресия. |
| Редът на изпълнение е фиксиран. | Редът на изпълнение може да не е важен. |
| Тестовата процедура съдържа тестови случаи от край до край. | Тестовият пакет съдържа всички нови функции и тестове за регресия. |
| Тестовите процедури се кодират на нов език, наречен TPL (език на процедурата за изпитване). | Тестовият пакет съдържа ръчни тестови случаи или скриптове за автоматизация. |
Заключение
Концепциите за тестване на софтуер играят важна роля в жизнения цикъл на тестването на софтуер.
Ясното разбиране на обсъдените по-горе концепции, заедно с тяхното сравнение, е много важно за всеки софтуерен тестер за ефективно провеждане на процеса на тестване.
Обикновено статии като тези са отлична отправна точка за по-задълбочени дискусии. Така че, моля, споделете вашите мисли, споразумения, разногласия и всичко останало, в коментарите по-долу. Очакваме вашите отзиви.
Приветстваме и вашите въпроси относно тестването на софтуер като цяло или нещо, свързано с вашата кариерна дейност. Ще разгледаме тези въпроси по-подробно в предстоящите ни публикации от същата поредица.
Честито четене !!
=> Посетете тук за пълна серия уроци за план за тестване
Препоръчително четене
- Урок за план за тестване: Ръководство за писане на документ за план за тест на софтуер от нулата
- Как да напиша документ за тестова стратегия (с примерен шаблон за тестова стратегия)
- Как да се подготвите за писане на тестови казуси (Съвети за производителност)
- Какво е тестов сценарий: Шаблон за тестов сценарий с примери
- Разлика между плана за тестване на ефективността и стратегията за тестване на ефективността
- Как се пишат тестови случаи: Крайното ръководство с примери
- Примерен шаблон за план за тестване на софтуер с формат и съдържание
- Тестов сценарий срещу тестов случай: Каква е разликата между тях?