ТЕСТОВ ПЛАН в софтуерното тестване (пример)

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

За да определите обхвата, трябва –

• Прецизно изискване на клиента
• Бюджет на проекта
• Спецификации на продукта
• Умения и талант на вашия тестов екип

Сега трябва ясно да дефинирате „в обхвата“ и „извън обхвата“ на тестването.

• Като софтуерно изискване очила, проектът Guru99 Bank се фокусира само върху тестването на всички функции и външен интерфейс на уебсайта Guru99 банка (в обхват тестване)
• Нефункционално тестване като напр стрес, пърформанс or логическа база данни в момента няма да се тества. (от обхват)

Проблемен сценарий

Клиентът иска да тествате неговия API. Но бюджетът на проекта не позволява това. В такъв случай какво ще направите?

Е, в такъв случай трябва да убедите клиента в това API тестване е допълнителна работа и ще изразходва значителни ресурси. Дайте му данни, подкрепящи вашите факти. Кажете му, че ако тестването на API е включено в обхвата, бюджетът ще се увеличи с XYZ сума.

Клиентът се съгласява и съответно новите обхвати, артикулите извън обхвата са

• Елементи в обхвата: Функционално тестване, тестване на API
• Елементи извън обхвата: Тестване на бази данни, хардуер и всякакви други външни интерфейси

Стъпка 2.2) Идентифицирайте типа тестване

A Тип тестване е стандартна тестова процедура, която дава очакван резултат от теста.

Всеки тип тестване е формулиран да идентифицира конкретен тип продуктови грешки. Но всички видове тестове са насочени към постигане на една обща цел "Ранно откриване на всички дефекти преди пускане на продукта на клиента”

- често употребявано типовете тестове са описани на следващата фигура

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

• Кои видове тестове трябва да бъдат фокусирани за тестване на уеб приложения?
• Кои видове тестове трябва да бъдат игнорирани за спестяване на разходи?

Стъпка 2.3) Документирайте рисковете и проблемите

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

В статията Анализ на риска и решение, вече сте научили подробно за анализа на риска и сте идентифицирали потенциалните рискове в проекта.

В Плана за тестване на QA ще документирате тези рискове

Стъпка 2.4) Създайте тестова логистика

В Тестовата логистика ръководителят на тестовете трябва да отговори на следните въпроси:

• Кой ще тества?
• Кога тестът ще се случи ли

Кой ще тества?

Може да не знаете точните имена на тестера, който ще тества, но тип тестер може да се определи.

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

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

• Способност за разбирам гледна точка на клиентите
• Здрав желание за качество
• Внимание до подробности
• добър сътрудничество

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

Кога ще се проведе тестът?

Тестовите дейности трябва да бъдат съчетани със свързаните дейности за разработка.

Ще започнете да тествате, когато го направите всички необходими елементи показано на следващата фигура

Стъпка 3) Определете целта на теста

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

За да определите целите на теста, трябва да направите следните 2 стъпки

1. Избройте всички функции на софтуера (функционалност, производителност, GUI...), които може да се наложи да тествате.
2. Определете цел или цел на теста въз основа на горните характеристики

Нека приложим тези стъпки, за да намерим тестовата цел на вашия проект за тестване на Guru99 Bank

Можете да изберете "ОТГОРЕ НАДОЛУ' метод за намиране на функциите на уебсайта, които може да се наложи да тествате. При този метод вие разбивате тестваното приложение на компонент намлява подкомпонент.

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

Тази фигура показва всички функции, които уебсайтът Guru99 може да има.

Въз основа на горните функции, можете да определите целта на теста на проекта Guru99, както следва

• Проверете дали уебсайтът Guru99 функционалност(Акаунт, Депозит...) работи според очакванията без никакви грешки или грешки в реална бизнес среда
• Проверете дали външният интерфейс на уебсайта, като напр UI работи според очакванията и отговаря на нуждите на клиента
• Проверете използваемостта на уебсайта. Тези функции удобни ли са за потребителя или не?

Стъпка 4) Дефинирайте тестови критерии

Тестовите критерии са стандарт или правило, на които може да се основава тестова процедура или тестова преценка. Има 2 вида тестови критерии, както следва

Критерии за спиране

Посочете критичните критерии за окачване за тест. Ако критериите за окачване са изпълнени по време на изпитването, активният цикъл на изпитване ще бъде окачен докато критериите са разрешен.

Пример за тестов план: Ако членовете на вашия екип докладват, че има 40% от тестови случаи неуспешни, трябва преустанови тестване, докато екипът за разработка коригира всички неуспешни случаи.

Критерии за изход

Той определя критериите, които обозначават a успешно завършване на тестова фаза. Изходните критерии са целевите резултати от теста и са необходими, преди да се премине към следващата фаза на разработка. Пример: 95% от всички критични тестови случаи трябва да преминат.

Някои методи за определяне на критерии за изход са чрез указване на targeted скорост на бягане намлява скорост на преминаване.

• Скоростта на движение е съотношението между брой изпълнени тестови случаи/общ брой тестови случаи на тестовата спецификация. Например спецификацията на теста има общо 120 TC, но тестерът е изпълнил само 100 TC, така че скоростта на изпълнение е 100/120 = 0.83 (83%)
• Пропускът е съотношение между номера тестови случаи преминали / тестови случаи изпълнени. Например, при над 100 изпълнени TC, има 80 издържани TC, така че процентът на преминаване е 80/100 = 0.8 (80%)

Тези данни могат да бъдат извлечени в документи за тестови показатели.

• бягане ставка е задължително да бъде 100% освен ако не е посочена ясна причина.
• Pass скоростта зависи от обхвата на проекта, но постигане на висока проходимост е цел.

Пример за тестов план:Вашият екип вече е извършил тестовите изпълнения. Те ви съобщават резултата от теста и искат да го потвърдите Критерии за изход.

В горния случай скоростта на движение е задължителна 100% но тестовият екип завърши само 90% от тестовите случаи. Това означава, че скоростта на изпълнение не е удовлетворена, така че НЕ потвърждавайте критериите за изход

Стъпка 5) Планиране на ресурсите

Ресурсният план е a подробно резюме на всички видове ресурси, необходими за изпълнение на проектната задача. Ресурсите могат да бъдат хора, оборудване и материали, необходими за завършване на даден проект

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

Този раздел представя препоръчителните ресурси за вашия проект.

Човешки ресурси

Следващата таблица представя различни членове на вашия проектен екип

Системен ресурс

За тестване на уеб приложение трябва да планирате ресурсите като следните таблици:

Стъпка 6) Планирайте тестова среда

Какво представлява тестовата среда

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

Как да настроите тестовата среда

Обратно към вашия проект, как го настройвате тестова среда за този банков уебсайт?

За да завършите тази задача, трябва силно сътрудничество между тестовия екип и екипа за разработка

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

• Каква е максималната потребителска връзка, която този уебсайт може да поддържа едновременно?
• Какви са хардуерните/софтуерните изисквания за инсталиране на този уебсайт?
• Компютърът на потребителя има ли нужда от някаква конкретна настройка, за да разглежда уебсайта?

Следната фигура описва тестовата среда на банковия уебсайт https://demo.guru99.com/V4

Стъпка 7) График и оценка

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

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

След това създавате график за изпълнение на тези задачи.

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

За да създаде график на проекта, Мениджърът на тестовете се нуждае от няколко типа входни данни, както е показано по-долу:

• Служител и краен срок на проекта: Работните дни, крайният срок на проекта, наличието на ресурси са факторите, които влияят върху графика
• Оценка на проекта: Въз основа на оценката мениджърът на тестовете знае колко време е необходимо за завършване на проекта. Така той може да направи подходящия график на проекта
• Проектен риск : Разбирането на риска помага на Test Manager да добави достатъчно допълнително време към графика на проекта, за да се справи с рисковете

Нека практикуваме с пример:

Да предположим, че шефът иска да завърши проекта Guru99 в един месец, вече сте изчислили усилията за всяка задача в Test Estimation. Можете да създадете графика по-долу

Стъпка 8) Тествайте резултатите

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

Има различни тестови резултати във всяка фаза на жизнен цикъл на разработка на софтуер.

Предоставени са резултати от теста преди фаза на тестване.

• Документ за тестови планове.
• Документи за тестови случаи
• Спецификации на тестовия дизайн.

Предоставени са резултати от теста по време на тестването

• Тестови скриптове
• Симулатори.
• Данни от теста
• Матрица за проследяване на теста
• Регистри на грешки и дневници на изпълнение.

Предоставени са резултати от теста след тестовите цикли приключиха.

• Резултати/доклади от тестове
• Доклад за дефект
• Указания за процедури за инсталиране/тест
• Бележки към изданието

Ресурси

Изтеглете примерен шаблон на тестов план

Изтеглете примерния план за тестване на системата на уебсайта Guru99 Bank