Когато за завършване на теста?

Начало - половината от битката. Това правило се прилага за почти всяка индустрия, а дори и тестване на софтуер.

Често в началото на проекта, тестери излъчват ентусиазъм, счетоводна документация (стратегия тест, тест план и тест случаи).

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

В такива ситуации, много от тях имат чувство за това, което правят повтарящи се действия, и като резултат, загубил интерес към по-нататъшно изпитване вече са запознати. И в третата, грубо, кръг над тестера неизбежно виси въпроса: "Когато става, че трябва да спрете тестване е?"

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

"Когато, на какъв етап и как да се спре тестване?"

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

Да предположим, че задачата да се тества новия проект.

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

Тестване Кръг # 1)

Екипът QA започне тестване, веднага след като тя почина новосъздадената софтуера.

Във фазата на тестване, тестери изпълняват различни сценарии, като се опитва да се справи на софтуера и за откриване на дефекти. (Тъй като прилагането е нов и се оценява за първи път, скоростта на откритите дефекти е относително висока).

Разработчиците отстраняване на недостатъци и да се върнат на развитието на тестери за повторно тестване.

Тестери поведение се извършва проверка за дефекти, а след това се премести в тестването на регресия.

След сериозните дефекти са отстранени и софтуерът показва стабилни резултати, развитието отбор освободен следващата версия.

Тестване кръг # 2)

Тестери започват втори кръг на тестване и повтаряне на това, което се извършва по време на първия тур.

По време на този процес, като правило, установено още някои дефекти.

Дефекти са отстранени от разработчици и приложни изпратена за повторен преглед.

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

Тя продължава и върху. Кръг 3, 4, 5 ... толкова дълго, тъй като софтуерът е напълно изчистена от бъгове.

Графично, този процес може да бъде представен, както следва:

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

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

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

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

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

И ако "тест прекратяване на договора, след пълното отстраняване на дефекти" вече не е критерий, а след това от къде да започнете?

Опитайте се да разберете какви фактори трябва да се разглежда като най-важни?

Решението за прекратяване тестване обикновено зависи от време (който е на разположение), бюджетът и необходимото време на изпитването.

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

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

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

До края на седмицата проверени 20 сценария и е установено, няколко по-опасни грешки.

2-ра седмица да започнете тестване, внимателно търси дефектите. През втората седмица можете да намерите някои бъгове 1-ви, 2-ри и 3-ти нива на критичност. През това време той успя да се провери 70 сценарии.

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

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

Данните за изпитване се поставят в таблицата: