acceptance testing documentation with real time scenarios
Документация за приемане (част II):
Този урок е продължението на предишния ни урок, където обсъдихме какво е тестване за приемане, кога трябва да се направи, кой го прави, неговото значение, видове, процес, въздействие върху различни екипи и т.н.
j2ee въпроси и отговори за интервю за старши разработчици
Документите играят много важна роля в теста за приемане и всички въпроси, свързани с документа, имат огромно отрицателно въздействие. Когато не се извърши правилна проверка, това може дори да доведе до отказ на продукта.
=> Щракнете тук за пълна серия уроци за план за тестване
В този урок ще научим повече за различната документация, участваща в изпитването за приемане, т.е. план за изпитване за приемане, контролен списък за преглед на плана за изпитване, шаблон за изпитване за приемане, примери, базирани на сценарии в реално време, как да се идентифицират и напишат подробно тестове за приемане и т.н. .
Какво ще научите:
- План за приемане на изпит
- Шаблон за план за приемане на изпит
- Преглед на плана за приемане на изпит
- Тестове за приемане
- Преглед на тестовете за приемане
- Заключение
- Препоръчително четене
План за приемане на изпит
Както всеки друг план за изпитване, планът за изпитване за приемане също включва някои компоненти като обхват, подход, среда за изпитване, ресурси, отговорности, справки за приемане на тестове, критерии за влизане, критерии за изход, инструменти и др.
Единственото нещо, което разграничава плана за приемане на изпит от обикновения план за изпитване, са факторите, които водят до бизнес решение. Планът за приемане на изпит е една от жизненоважната документация, която предоставя насоки за това как да се извършат тестове за приемане за определен проект.
Планът за приемно изпитване трябва да бъде преразгледан и одобрен преди изпълнението на приемния тест. Всички последващи промени отново трябва да преминат през процес на преглед и одобрение и трябва да бъдат в процес на проследяване.
Прегледът на плана за приемане на изпит обикновено се извършва от мениджъри / бизнес анализатори / клиенти.
Основни моменти, които трябва да се вземат предвид при изготвянето на план за приемане:
- Трябва да бъде Подробни и конкретни. Трябва да включва само това, което се изисква за тестване и каква информация е необходима на екипа за извършване на тестване.
- Трябва да бъде Ясно и кратко . Без неяснота. Ако изобщо има нещо, което може да доведе до объркване, довършете го, но го поддържайте кратко и ефективно.
- Всеки компонент в документа трябва да се пише, като се имат предвид само бизнес изискванията.
- Надеждни и адаптивни - Той трябва да бъде актуализиран, както се изисква в бъдещите версии.
- Последователен - Не трябва да има повече промени в бъдеще.
- Следвайте шаблона, предоставен от Организацията или клиента.
Шаблон за план за приемане на изпит
Тук ще разгледаме общ шаблон за План за изпитване за приемане, който може да бъде допълнително променен според изискванията на проекта.
Заглавие
Обективен
История на редакциите / Дневник на промените
< Това трябва да бъде в таблична форма със следната информация:
- Дата - Датата, на която документът е променен.
- Променено от - Кой е променил съдържанието на документа.
- Предназначение - Защо документът е модифициран.
- Версия - Текуща версия на документа след модификации (става 1.0, 1.1, 1.2, 1.3, ... за конкретна версия. Следващата версия ще започне от 2, 2.1, 2.2, 2.3, ..., Списъкът продължава).
- Одобрен от - Кой е одобрил направените промени (имплицитно означава, че документът е прегледан и одобрен).
Първият ред в тази таблица трябва да бъде подробностите за създадения документ. След това следва подробностите за направените промени.>
Съдържание
Препратки
Обхват
Въведение
Тестови елементи
Характеристики, които трябва да бъдат тествани
Характеристики, които не се тестват
Приближаване
Подробности за тестовата среда
Критерии за влизане
Тестове - ако няма отделни писмени тестове за приемане
Всеки тест трябва да включва:
- Тест #.
- Описание на това, което се тества ( Пример : Проверете дали потребителят е в състояние да създаде акаунт успешно).
- Бизнес изискване, към което този тест съответства ( Матрица за проследимост ) - Много важно.
- Предварителни условия:
- Състояние на продукта преди започване на тестването (Потребителят трябва да бъде регистриран успешно, но не е активирал акаунта, Потребителят е трябвало да има достъп до продукта преди поне 30 дни и т.н.)
- Всички условия на сървъра - Ако сървърът не работи за известно време.
- Тестови стъпки: Подробен номериран поток ( Пример: виж отдолу
- Отворете приложението.
- Опит за влизане с валидни идентификационни данни с отметнато квадратче Запомни ме).
- очакван резултат : Какво е очакваното поведение на стъпката>
Тестове за приемане - Ако има отделни писмени тестове за приемане
Критерии за изход
Ресурси
Роли и отговорности
Инструменти
Фактори за бизнес решения
Процедура за изписване
Точка на допир
Планът за приемане се счита за План за главен тест за фазата .
Преглед на плана за приемане на изпит
След като планът е готов, той трябва да бъде прегледан за пълнота, недвусмисленост, яснота, качество и др. Без съмнение, цялото съдържание в плана за приемане трябва да бъде прегледано щателно за правилна информация, но трябва да бъдат прегледани и срещу няколко други точки, да кажем точки от контролния списък.
Тук нека да категоризираме съдържанието и да видим точките от контролния списък срещу тях.
| Категория | Точки от контролния списък |
|---|---|
| Тестове за приемане | Номерирани ли са тестовете Номерирани ли са предварителните условия Ясни ли са стъпките на теста за разбиране Изпълнени ли са стъпките за тестване Очакваният резултат завършен ли е Има ли отворен въпрос в тестовете (ако има такъв, проследяване и попълване) Валидна и съществуваща ли е препратката към тестове за приемане (ако е написана отделно) Правилна ли е проследимостта Пропуснато ли е някакво бизнес изискване, което да се покрие за тест |
| Заглавие | Съответства ли заглавието на заглавието на проекта както е посочено навсякъде Дали заглавието следва конвенциите за именуване на проекта |
| История на редакциите, Съдържание | Дали всяка версия на модификациите се проследява правилно за плана Дали всяка промяна на версията е била подложена на правилен преглед и е спомената Правилна ли е конвенцията за версиите Съдържанието отговаря ли на действителното съдържание в плана Правилен ли е номерът на страницата за всяко съдържание Актуализира ли се номерът на страницата, ако промените, направени в плана, променят номера на страницата на съдържанието |
| Препратки | Съществуват ли и са валидни препратките Съвпадат ли те с обхвата Пълни ли са и взети ли са предвид за идентифициране на тестове |
| Тестови елементи, Характеристики за тестване, Характеристики, които не се тестват | Номерирани ли са Дали всяка характеристика / модул / подмодул попада в обхвата Може ли планираният график да обхване всички идентифицирани тестови елементи в рамките |
| Критерии за влизане, критерии за излизане | Номерирани ли са Дали всеки критерий е споменат подробно |
| Подробности за тестовата среда | Има ли всички споменати необходими конфигурации Дали трябва да се разгледа версията за всяка конфигурация или най-новата Съществуват ли виртуални машини, среда (ако не, посочете възможната дата за нейната наличност) Споменат ли е методът за споделяне на идентификационни данни за конкретен достъп до околната среда |
| Ресурси, роли и отговорности | Номерирани ли са отговорностите за всяка роля Могат ли да бъдат постигнати отговорностите Способен ли е идентифицираният ресурс да се справи със споменатите отговорности |
| Инструменти | Всички посочени инструменти ли са Номерирани ли са всички инструменти Всички инструменти са версирани Има ли нужда от някой от инструментите лиценз или съществуващ лиценз, валиден по време на фазата Правилно и достатъчно ли е ръководството за използване на инструмента |
| Фактори за бизнес решения | Има всички споменати фактори Номерирани ли са всички фактори |
| Процедура за изписване | Валидна ли е процедурата Допустима ли е процедурата Ясна ли е процедурата за разбиране |
| Точка на допир | Идентифициран ли е ресурсът като точка за контакт, налична в организацията по време на фазата Идентифициран ли е ресурсът, способен ли е да се справи с фазата |
Всеки план за изпитване, отговарящ на горния документ от контролния списък, ще служи като силен документ и за вътрешни одити.
Тестове за приемане
Тестовете за приемане по-рано са били известни като функционални тестове. За да направи името по-подходящо за фазата на приемане и да служи на целта, то беше преименувано на Тестове за приемане. Понякога се нарича и Тестове на клиенти.
Тестовете за приемане винаги се извличат от истории на потребителите, критерии за приемане и случаи на употреба. Това са системни тестове в черна кутия и представляват само онези бизнес тестове, които трябва да бъдат проверени. Те трябва да бъдат предназначени главно за поведение, употреба и потоци на продуктите.
Проектираните тестове за приемане също могат да бъдат взети под внимание за фазата на изпитване на системата в регресионните цикли, за да се получи увереност в продукта, преди да се предаде на фазата на изпитване за приемане.
Основни моменти, които трябва да се запомнят, преди да се напишат тестове за приемане:
- Дръжте всички референтни документи на място: Спецификация на софтуерните изисквания, документ за бизнес изисквания, случаи на употреба, потребителски истории, матрица от данни (в случай на логика) и др.
- Фокусирайте се само върху бизнес изискванията (проверими бизнес изисквания).
- Изчистете най-рано всички съмнения, запитвания относно бизнес изискванията.
- Уверете се, че няма промени в изискванията за текущата версия поне.
Общ и прост шаблон за написване на тестове за приемане:
Този шаблон може отново да бъде променен според нуждите на проекта и да се включи повече информация.
Сега, нека вземем някои често срещани сценарии и да видим как сценариите за приемане могат да бъдат написани върху тях.
Случай 1: Обработка на потребителски акаунт
Това е сценарият, при който на потребителите е разрешено да създават, преглеждат, актуализират и деактивират своя акаунт. По принцип това е CRUD операция (Създаване, четене, актуализиране и изтриване). Така че директно ще получим 4 основни сценария за тестване.
Заедно с това, при обработката на потребителски акаунти в реално време имаме много области, когато става въпрос за преглед и актуализиране.
Продължаване с писмените тестове за приемане:
Тест 1: Регистрация / Регистрация / Създаване на акаунт, проверете дали Потребителят е в състояние да:
- Създайте акаунта.
- Активирайте акаунта.
- Активирайте акаунта само веднъж (Тук връзката за активиране трябва да бъде тествана за 2ndВъпреки че това е отрицателно тестване, това е една от основните точки за проверка, която трябва да се има предвид).
Тест 2: За достъп и преглед на информацията за акаунта проверете дали потребителят е в състояние:
- Влезте в акаунта.
- Преглеждайте различни секции в профила (ако секцията Профил е категоризирана, тогава всяка категория трябва да бъде видима).
- Проверете дали данните, показани в Профил, са верни според въведеното от потребителя.
Тест 3: За да актуализирате информацията за акаунта, проверете дали потребителят е в състояние:
- Актуализиране на информацията за профила (Профил):
- Актуализирайте всяка категория на профила.
- Уверете се, че информацията за актуализация се отразява правилно в профила.
- Проверете дали Потребителят не е в състояние да актуализира информация в Профила (В някои приложения Име, Фамилия, Потребителско име и др. Няма да бъде разрешено да се актуализира. Въпреки че това е отрицателно тестване, това е една от основните точки за проверка да бъдат разгледани).
- Отменете потока на актуализацията (Въпреки че това е отрицателно тестване, това е и една от основните точки за проверка, която трябва да се има предвид).
Тест 4: Ако е разрешено деактивиране на акаунт, проверете дали Потребителят е в състояние да:
- Деактивирайте акаунта.
- Отменете деактивиращия поток (Въпреки че това е отрицателно тестване, това е една от основните точки за проверка, която трябва да се има предвид).
- Достъп до акаунт след отмяна на деактивиране.
Тест 5: Ако се изискват проверки за имейл адрес или телефонни номера, проверете дали потребителят е в състояние да:
коя е най-добрата безплатна защитна стена за Windows 10
- Актуализирайте имейл адреса до другия валиден.
- Проверете ”актуализиран имейл адрес.
- Проверете дали актуализираният и „проверен“ имейл адрес се счита за по-нататък - Изпратете няколко имейла от приложението и проверете за неговото пристигане на актуализирания имейл адрес. Старият не трябва да получава имейли.
- Добавете новия телефонен номер.
- Проверете добавения телефонен номер чрез Call.
- Проверете добавения телефонен номер чрез SMS.
- Уверете се, че добавеният и „проверен“ телефонен номер се отразява в акаунта.
- Актуализирайте телефонния номер.
- Проверете актуализирания телефонен номер чрез Call.
- Проверете ”актуализиран телефонен номер чрез SMS.
- Проверете дали актуализираният и „проверен“ телефонен номер се отразява в акаунта.
Случай 2: Закупуване на продукт
Закупуването на продукта обикновено има общия поток.
Някои общи сценарии, които гледат крайните потребители, са изброени тук:
Предварително условие: Потребителят трябва да влезе в приложението.
Тест 1: Подробности за продукта, проверете дали потребителят е в състояние да:
- Вижте страницата с подробности за продукта.
- Вижте всички подраздели в страницата с подробности за продукта (описание, характеристика, информация за марката и т.н.).
- Изберете Количество на продукта, Цвят, Размер и др., Както е налично на страницата с подробности за продукта.
- Придвижете се до страниците с категории, подкатегории от страницата с подробности за продукта (ако е налична в страницата с подробности за продукта).
- Придвижете се до страницата с подробности за другия продукт (ако е предоставена съответната секция за продукти).
- Преглед на коментари и оценки за продукта.
- Сортирайте коментарите на продукта въз основа на оценки.
- Вижте общата оценка на продукта.
- Добавете коментар за продукта.
- Актуализирайте неговия / нейния коментар за продукта.
- Изтрийте неговия / нейния коментар за продукта (ако е предоставен).
Тест 2: Добавете в кошницата, проверете дали потребителят е:
- Може да добавите продукта в кошницата:
- Чрез страницата с подробности за продукта.
- Чрез страницата със списък с продукти.
- Възможност за добавяне на необходимото количество към количката (1 до максимално зададеното ограничение).
- Не може да добави продукта в кошницата, ако няма наличност.
Тест 3: На страницата с количката проверете дали потребителят е в състояние да:
- Разгледайте продукта в количката с подробности за цената за добавено количество.
- Актуализиране на количеството (1 до максимално зададено ограничение).
- Извадете продукта от кошницата.
- Върнете се обратно към пазаруването.
- Продължете към Checkout.
- Прегледайте празната количка, когато не е добавен продукт,
Тест 4: На страницата с подробности за акаунта проверете дали потребителят е в състояние да:
- Продължете със съществуващите данни за доставка.
- Актуализирайте адреса за доставка.
- Добавете нов адрес за доставка.
- Продължете със съществуващия телефонен номер.
- Актуализирайте телефонен номер за поръчката.
- Добавете нов телефонен номер за поръчката.
- Придвижете се обратно до страницата Количка.
- Отворете страницата за плащане.
Тест 5: На страницата за плащания проверете дали потребителят е в състояние да:
- Проверете верността на сумата, която трябва да бъде таксувана.
- Обработете поръчката с всички налични опции (Една опция за всяка отделна поръчка).
- Обработете транзакцията успешно. Отидете на страницата за потвърждение на поръчката.
- Неуспех на транзакцията (Въпреки че това е отрицателно тестване, това трябва да се разглежда като основен сценарий).
- Прилагане на купони:
- Валидни купони - успех. Тук проверете промяната в сумата, която трябва да бъде таксувана.
- Невалидни купони - Неуспех
- Купони с изтекъл срок на годност - Неуспех.
- Приберете се обратно към страницата с подробности за акаунта.
Преглед на тестовете за приемане
Прегледът на тестовете за приемане е важна задача, тъй като трябва да бъде коректен и точен по отношение на бизнес изискванията. Тъй като те могат да се извършват от самите клиенти и / или крайни потребители, е много необходимо да бъдат пълни, недвусмислени, коректни и достатъчно подробни, за да може някой да разбере и изпълни.
Прегледът на тестовете за приемане трябва да се извършва от бизнес анализатори, клиенти и всякакви коментари за прегледи трябва да бъдат включени във висок приоритет.
На ниво индивидуален тест, прегледът трябва да бъде направен спрямо следните:
- Дали тестът покрива бизнес изискванията или не.
- Ясни ли са предварителните условия?
- Лесни ли са за разбиране и подробни стъпки на теста?
- Правилен и ясен ли е очакваният резултат?
- Съответства ли на бизнес изискванията за проследимост?
- Достатъчно пълен ли е тестът, за да покрие конкретния поток или употреба?
- Изисква ли се конкретният тест като част от тестовете за приемане.
- Има ли някаква точка за проверка, която не е необходима за тестове за приемане.
- Чисто функционален ли е или е включен някакъв графичен интерфейс (трябва да е само функционален).
- Необходими ли са специалните входни данни? Ако отговорът е да, предвижда ли се за подробности?
Като цяло, целият преглед на пакета за приемни тестове трябва да обхваща:
- Двупосочна проследимост: Бизнес изисквания към тестове И тестове към бизнес изисквания.
- Покрити ли са всички бизнес изисквания?
- Обхваща ли се всяко бизнес изискване от един или повече тестове?
- Покрити ли са бизнес правилата?
- Обработва ли се специалният случай на данни?
- Колко теста са написани, за да покрият всяко изискване или правило?
- Могат ли тестовете да бъдат групирани заедно и класифицирани за потоци.
- Правилно ли са подредени тестовете, така че изпълнението да е ефективно?
Заключение
Накратко, както споменахме по-рано, документите играят много драстична роля в теста за приемане.
Следователно, всеки изпит за приемане, който е написан, трябва да бъде добре структуриран и да е в ход с използването му, така че да поддържа тестерите за приемане да се интересуват от това, което тестват и как го правят. Това от своя страна автоматично би довело до успех.
=> Посетете тук за пълна серия уроци за план за тестване
Следете и следете предстоящия урок за тестване за приемане, за да научите повече за докладите за тестване за приемане, заедно с някои общи шаблони. Също така, уведомете ни, ако имате някакви въпроси.
Препоръчително четене
- Най-добри инструменти за тестване на софтуер 2021 г. (Инструменти за автоматизация на QA теста)
- Положително тестване: Значение и достойнства, обяснени с реални тестови сценарии
- Изтегляне на eBook за тестване на Primer
- TimeShiftX, издаден за опростяване на тестването на изместване на времето
- Какво е тестване за приемане (Пълно ръководство)
- Примерен шаблон за доклад за изпитване за приемане с примери
- Вие сте експерт по ръчно тестване или автоматизация? Работете на непълно работно време за нас!
- Тестване на натоварване с уроци за HP LoadRunner