Меню

Примерен шаблон за доклад за изпитване за приемане с примери

sample template acceptance test report with examples

Опитайте Нашия Инструмент За Премахване На Проблемите

Преглед на протокола за приемане на изпитване (Част III):

Предишен урок | СЛЕДВАЩ урок

В предишния ни урок за „ Документация за приемане на тестове със сценарии в реално време ”Обсъдихме плана за приемане на изпит.

В този урок ще разгледаме задълбочено отчитането на състоянието на теста за приемане, обобщението на теста за приемане и изхода.

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

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

Шаблон за тест за приемане

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

Доклад за състоянието на теста за приемане

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

Общ шаблон за доклад за състоянието на теста за приемане:

Дата :Дата на доклад за състоянието на теста за приемане

Днешните тестове за приемане подробности за изпълнението:

  • Брой издържани тестове
  • Брой неуспешни тестове
  • Брой текущи тестове

Детайли за изпълнение на тестове за приемане до дата:

  • Общ брой тестове
  • Брой издържани тестове
  • Брой неуспешни тестове
  • Брой текущи тестове
  • Брой изчакващи тестове

Подробности за дефекти:

java метод, който взема масив
  • Брой регистрирани дефекти
  • Всеки дефект трябва да съдържа следните данни:
    • ID, Обобщение, Компонент, Тежест
  • Общият брой дефекти, регистрирани до момента (във фаза на приемане).

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

Обобщен доклад за теста за приемане

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

Общ шаблон за обобщен доклад за тест за приемане:

Обобщение

Вариации

Вариации

Резултати

Доклади

Оценка

Препоръка

тежест на дефектите , и Pass rate влияе на препоръката продуктът да бъде пуснат на пазара.>

Усилия

Усилия

Доклад за отписване

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

Общ шаблон за отчет за излизане:

Име на продукта, версия на изданието, номер на компилация

Последен доклад

Прегледано на

Прегледан от

Преглед на коментари

Дата на излизане

Подписване от

Коментари за отписване

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

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

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

Изпитване за приемане в Agile

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

Тестовете за приемане обикновено се проектират от QA, който е експертът по предмета в тази област. Изпитването за приемане в Agile започва много по-рано в сравнение с другите подходи, обикновено в рамките на самите спринтове.

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

Изпитването за приемане се извършва на два различни етапа в Agile:

  • Когато характеристиката е създадена и в началния си етап - основна.
  • Когато функцията е интегрирана и стабилизирана с другите характеристики на продукта.

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

Историческите точки се дават на всяка потребителска история въз основа на успеха на резултатите от теста за приемане за всеки от критериите за приемане. Изпитването за приемане също така определя попълването на ниво User Story, като заявява, че критериите за приемане за историята са изпълнени.

Кой прави тестове за приемане в Agile?

Обикновено продуктовите мениджъри, Експертиза по предмета (могат да бъдат клиенти И / ИЛИ бета тестери) извършват тестове за приемане в гъвкава среда. Понякога QA също включва в тази дейност заедно с техните редовни задачи за регресия.

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

Има няколко предимства от приемането на тестове в Agile.

Предимствата са:

  • По-тясно сътрудничество между продуктов мениджър и екипа.
  • Изгражда увереност на ниво User Story.
  • Ще помогне да се изведат повече сценарии, които да покрият всеки критерий за приемане.
  • Повишена вероятност за импровизиране на решенията на продукта чрез критерии за приемане в потребителски истории.

Недостатъци

Въпреки че има няколко предимства, има и някои недостатъци.

Недостатъците включват:

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

Разработване на тест за приемане (ATDD)

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

Това е така, защото различните гледни точки от всеки член на екипа ще дадат нов начин на мислене за всеки от критериите за приемане и ще пристигнат с голям брой тестове за приемане, обхващащи повече сценарии. Понякога, ATDD също се нарича Развитие на тестова история (STDD).

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

Това описва как се изгражда продуктът и от своя страна ще даде добра представа за това как продуктът действително ще функционира, преди да бъде предаден за тестване. Следователно то се нарича „ Развитие, управлявано от тест за приемане ”.

Заключение

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

Накратко:

  • Тестовете за приемане са преминати.
  • Дефектите са в допустими нива.
  • Постигнато покритие по сценарий / сценарий.
  • Продуктът и неговите решения се приемат.
  • Клиентът е достатъчно уверен в продукта.
  • Всички документи на продукта се актуализират, за да съответстват на най-новите функции.
  • Резултат от усилията на екипа.
  • Добре е да продължите напред със стартирането на производството.

Предишен урок | СЛЕДВАЩ урок

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

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

^