Кога да спрете тестването (критерии за изход при тестване на софтуер)

when stop testing

Критерии за изход при тестване:

„Добре започнатото е наполовина направено“ - Прилага се навсякъде, дори тестване на софтуер.

Често виждаме тестери на софтуер с много ентусиазъм в началото на проекта. Ние създаваме документи за тестване като Тестова стратегия, Тестови план или Тестови случаи с нетърпение и ентусиазъм.

След това стигаме до тестване на софтуер с БАНГ! Това се усилва само от интересните дефекти, които откриваме в началото на проекта. Решаването им само ще допринесе за постиженията ни.

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

въпроси и отговори за интервю за тестване на Salesforce pdf

Много тестери смятат, че става монотонна работа при по-късните стартирания и започнете да губите интерес към тестване на същия софтуер отново и отново. Когато достигнем до, може би третото изпълнение, един въпрос започва да ни преследва и това е „Кога да спрем да тестваме софтуера?“

Обзалагам се, че трябва да сте се чувствали по същия начин и да сте попитали „Кога да спрете тестването?“, Поне веднъж. Бих казал, че въпросът е „Кога, къде и как да спра тестването?“ :)

Концептуално сме чели и много тестери вярват, че не може да има конкретно условие или уравнение, което да реши „Кога да спрете тестването?“ Има редица фактори, които трябва да се вземат предвид, преди да приключим по този въпрос.

В днешната статия бих искал да споделя мислите си за това как да приключим тестовите дейности, когато стигнем до точка от цикъла ни на тестване, където можем да кажем, че това тестване е достатъчно. Ще направим това с помощта на няколко примера от реалния живот в типичен цикъл на тестване.

Какво ще научите:

• Кога е достатъчно тестване?
• Спиране, когато бъдат открити всички дефекти: Възможно ли е?
• Решение за спиране на тестването: критерии за изход
• Какво представляват критериите за завършване или изход?
• Какво трябва да присъства в критериите за изход?
• Тестването може да бъде спряно, когато:
• Заключение:
• Препоръчително четене

Кога е достатъчно тестване?

Кога можем да кажем, че толкова много тестове са достатъчни? Може ли някога да приключи тестването?

За да отговорим на тези въпроси, ще трябва да анализираме тестовите дейности от началото до края. Моля, обърнете внимание, че - аз ще определя тези дейности в смисъла на миряни - Не по изискан технически начин.

Нека помислим, че започвате тестване на нов проект.

Първоначални дейности:

• Екипът за тестване получава изисквания.
• Екипът за тестване започва планиране и проектиране.
• Документите за първоначален тест са готови и прегледани.

Тестово изпълнение # 1)

• Екипът за тестване започва изпълнението на теста след като получат разработения продукт.
• По време на фазата на тестване те изпълняват различни сценарии, за да разбият софтуера и да намерят много дефекти. (Освен това процентът на дефекти тук е по-висок, тъй като приложението е ново и за първи път се подлага на оценка.)
• Дефектите се отстраняват от разработчиците и се връщат обратно към тестовия екип за повторно тестване.
• Екипът за тестване извършва повторно тестване на дефектите и извършва регресия.
• След като повечето дефекти с висока степен на сериозност бъдат отстранени и софтуерът изглежда стабилен, екипът за разработка пуска следващата версия.

Тестово изпълнение # 2)

• Екипът за тестване започва втория цикъл на тестване и подобни дейности се изпълняват като изпълнение 1.
• В този процес по време на второто тестване се улавят още няколко дефекта.
• Дефектите се отстраняват от разработчиците и се връщат обратно към тестовия екип за повторен тест.
• Екипът за тестване повторно тества дефектите и изпълнява регресия .

Това може да продължи вечно. Изпълнете 3, изпълнете 4 нататък, докато бъдат открити всички дефекти в софтуера и софтуерът стане без грешки.

Ако искаме да съставим блок-схема за тези дейности, тя ще изглежда приблизително като по-долу:

От горната диаграма можем ясно да заключим, че тестването може да продължи, докато не бъдат открити всички дефекти в софтуера.

Но въпросът е - възможно ли е да се намери всеки един дефект в софтуера? Нека се опитаме да намерим отговора на този въпрос за милиони долари :).

Спиране, когато бъдат открити всички дефекти: Възможно ли е?

Повечето софтуери са сложни и имат огромен обхват на тестване. Не е невъзможно да се намерят всички дефекти в софтуера, но това ще отнеме вечно.

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

Освен това целта на тестването не е да се открият всеки дефект в софтуера. Целта на софтуерното тестване е да докаже, че софтуерът работи по предназначение, като го счупи или открие отклонение между настоящото му поведение и очакваното поведение.

Има неограничени дефекти в софтуера и поради това е непрактично да го тествате, докато не бъдат открити всички дефекти, тъй като никога не можем да разберем кой дефект е последният. Истината е, че не можем да разчитаме на откриването на всички дефекти в софтуера, за да завършим нашето тестване.

Честно казано, тестването е безкрайно и циклите на тестване ще продължат, докато не се вземе решение кога и къде да се спре. Сега става още по-сложно да се стигне до решение за спиране на тестването. Ако „спирането, когато бъдат открити всички дефекти“ не е критерият за спиране на тестването, на какво основание трябва да се реши?

Решение за спиране на тестването: Критерии за изход

Нека сега се опитаме да разберем - Кои са най-важните фактори, които трябва да се имат предвид при приключване на тестовите дейности? Смятам, че решението за спиране на тестването зависи най-вече от Време, бюджет и обхват на тестване.

Най-често срещаният подход е да се спре, когато Времето / Бюджетът са изчерпани или изпълнени всички тестови сценарии. С този подход обаче ще направим компромис с качеството на тестването и това няма да даде достатъчно увереност относно софтуера; как

Нека да видим спример.

Тест сценарий:

Да предположим, че тествате софтуерен модул. Имате определен бюджет, за да го покриете. Сроковете на проекта са за един месец. Общият сценарий на теста е 200. Вие сте единственият, който тества този модул.

Сценарий # 1)

Седмица 1: Намирате дефекта на showstopper / сериозност 1 на ден 1 и цялото тестване е блокирано за 3 дни. Следователно не можете да изпълните нито един от сценариите, докато дефектът на сериозност 1 не бъде отстранен. След като загубите 3 дни, блокерът е разрешен и вие продължавате с изпълнението си.

В края на седмицата изпълнявате 20 сценария с няколко по-важни максимума приоритетни дефекти .

Седмица 2: Започвате да тествате софтуера, като поставяте повече внимание върху откриването на дефекти. Отваряте още няколко дефекта на сериозност 1, сериозност 2 и тежест 3 през втората седмица и в края на седмицата можете да покриете 70 сценария.

Седмица 3: До началото на 3^rdседмица получавате разрешени всички дефекти с висок приоритет, така че заедно с изпълнението на чакащите сценарии, сега трябва да тествате отново всички дефекти, попаднали в тестващата група. Продължавайки с добрия напредък, обхващате 120 сценария с допълнителни дефекти.

По това време всички дефекти с висок приоритет вече са намерени и докладвани. И така, сега ви остават само дефектите на сериозност 3.

Седмица 4: До седмица 4 трябва да тествате повторно повечето отворени дефекти и останалите 80 сценария. С това до края на седмица 4 можете да завършите до 180 сценария с всички дефекти с висок и среден приоритет, отстранени и повторно тествани.

Поставяне на тази информация в таблична форма:

Трябва ли да спреш до тук?

Причината, която сте изчерпали Време за тестване напълно и са докладвали и отстранили повечето дефекти с висок приоритет. Спирането в този момент ще ви даде ли увереност относно софтуера? Всъщност не се дължи на причините по-долу:

• Сценариите не се изпълняват напълно.
• Малко потоци дори не са тествани веднъж.
• Всички обхванати сценарии се изпълняват само веднъж.
• Софтуерът все още има дефекти в себе си.
• Регресията не е покрита.

Сценарий # 2)

Седмица 1: Откривате дефект на сериозност 1 на ден 1 и пълното тестване е блокирано за 3 дни. Следователно не можете да изпълните нито един от сценариите, докато не бъде отстранен дефектът на сериозността 1. След загуба на 3 дни блокерът е разрешен и вие продължавате с изпълнението си.

В края на седмицата изпълнявате 20 сценария с малко повече дефекти. Тази седмица остава същата като сценарий 1.

Седмица 2: Отваряте още няколко дефекта на сериозност 1, сериозност 2 и тежест 3 през втората седмица, но фокусът е да обхванете повече сценарии за покриване на изоставането от седмица 1. В края на седмицата можете да покриете 120 сценария.

Седмица 3: До началото на 3^rdседмица решавате всички отворени дефекти, така че заедно с изпълнението на чакащите сценарии, сега трябва да тествате отново всички дефекти, които са попаднали в тестваща група. Продължавайки с добър напредък в края, броят на завършените сценарии става 200 с допълнителни дефекти.

Сега можете да докладвате само за дефекти на сериозност 2 и сериозност 3.

Поставяне на тази информация в таблична форма:

Трябва ли да спреш до тук?

Ти имаш обхвана изцяло всички сценарии за тестване веднъж и са открили няколко големи дефекта. Спирането в този момент ще ви даде ли увереност относно софтуера?

Всъщност не се дължи на причините по-долу:

• Всички сценарии се изпълняват само веднъж.
• Софтуерът все още има много основни дефекти.
• Регресията не е покрита.

Виждаме, че качеството е компрометирано и при двата сценария. Най-добрият подход ще бъде намирането на точка, при която всички фактори от сценарий 1 и сценарий 2 са обхванати и качеството също не е нарушено. За да постигнем това, ще трябва да определим определени критерии в началото на тестването.

Тези критерии се наричат ​​критерии за завършване или изход. Това е отговорът на нашия въпрос - „Кога да спра тестването?“.

Какво представляват критериите за завършване или изход?

Критериите за изход се оценяват в края на тестовия цикъл и са дефинирани в тестовия план. Наборът от условия или дейности, които трябва да бъдат изпълнени, за да приключи изпитването.

Критериите за изход определят колко тестване е достатъчно и кога тестовите дейности могат да бъдат обявени за завършени. Покритие и критериите за завършване се комбинират, за да се определят критериите за изход за тестване.

Какво трябва да присъства в критериите за изход?

В идеалния случай критериите за излизане или спиране се определят чрез комбиниране на различни фактори и следователно са уникални за всички проекти. Това зависи от изискванията на проекта и следователно трябва да бъде определено по време на планирането на теста; в началото на проекта. Параметрите, дефинирани в него, трябва да се определят количествено, доколкото е възможно.

По-долу има няколко указателя, които трябва да бъдат взети предвид при определяне на критерии за изход в случай на функционално или системно тестване. Можете да комбинирате няколко или всички по-долу фактори, докато решавате къде да спрете тестването според нуждите на вашия проект.

Тестването може да бъде спряно, когато:

Изисквания:

• Постигнато е 100% покритие на изискванията.

Дефекти:

• Дефинираният / желаният дефект е достигнат.
• Всички дефекти на Show Stopper или блокиращи устройства са поправени и не е известен дефект Critical / Severity 1 е в отворен статус.
• Всички дефекти с висок приоритет са идентифицирани и отстранени.
• Степента на дефекти пада под определената приемлива норма.
• Много малко дефекти със среден приоритет са отворени и разполагат с решение.
• Много малко отворени дефекти с нисък приоритет, които не оказват влияние върху използването на софтуера.
• Всички дефекти с висок приоритет се тестват повторно и се затварят и съответните сценарии на регресия се изпълняват успешно.

Тестово покритие:

• Покритието на теста трябва да бъде постигнато на 95%.
• Процентът на успешен тест трябва да бъде 95%. Това може да се изчисли по формула
  • (Общ брой на приетите ТК / Общ брой ТК) * 100.
• Всички критични тестови случаи се предават.
• 5% тестови случаи могат да бъдат неуспешни, но неуспешните тестови случаи са с нисък приоритет.
• Постигнато е пълно функционално покритие.
• Всички основни функционални / бизнес потоци се изпълняват успешно с различни входни данни и работят добре.

Крайни срокове:

• Срокът за изпълнение на проекта или крайният срок на теста е достигнат.

Тестови документи:

• Всички тестови документи / резултати (Пример - Резюме на теста ) се подготвят, преглеждат и публикуват в.

Бюджет:

• Пълният бюджет за тестване е изчерпан.

Срещи „Go / No Go“:

• ' Отиди / Не върви ' среща е проведено със заинтересовани страни и се взема решение дали проектът трябва да бъде пуснат в производство или не.

Заключение:

Нека го направим много просто в края.

двойно свързан списък c ++ вмъкване

Моля, отговорете на въпросите с просто Да или Не.

Ако получите повечето отговори като Да, това означава, че можете да спрете тестването на този етап. Ако повечето от отговорите са Не, това означава, че трябва да проверите какво липсва при тестването и това може да ви помогне да откриете избягващ производствен дефект :)

• Изпълняват ли се всички тестови случаи поне веднъж?
• Определен ли е процентът на преминаване на тестовия случай?
• Постигнато ли е пълно покритие на теста?
• Всички функционални / бизнес потоци изпълняват ли се поне веднъж?
• Постигнат ли е броят на решените дефекти?
• Всички основни дефекти с висок приоритет фиксирани и затворени ли са?
• Всички дефекти са били повторно тествани и затворени?
• Направена ли е регресия за всички отворени дефекти?
• Изчерпали ли сте бюджета за тестване?
• Достигна ли крайният час на тестването?
• Всички тестови резултати прегледани и публикувани ли са?

За автора: Това е статия за гости на Ренука К. Тя има 11+ години опит в тестването на софтуер.

Надявам се, че тази статия е била полезна за вас. Бих искал също да чуя вашите мисли / коментари по темата.

Честито тестване!

Препоръчително четене

• Най-добри инструменти за тестване на софтуер 2021 г. (Инструменти за автоматизация на QA теста)
• Тестване на софтуер QA Assistant Job
• Учебна програма за курс за тестване на софтуер - подробен план за обучение на онлайн курс
• Курс за тестване на софтуер: Към кой институт за тестване на софтуер трябва да се присъединя?
• Изборът на софтуерно тестване като кариера
• Тестване на софтуер Техническо съдържание Writer Работа на свободна практика
• Някои интересни въпроси за интервю за тестване на софтуер
• Обратна връзка и рецензии на курсове за софтуерно тестване