Meniu

Exemplu de șablon pentru raportul testului de acceptare cu exemple

sample template acceptance test report with examples

Încercați Instrumentul Nostru Pentru Eliminarea Problemelor

Prezentare generală a raportului testului de acceptare (partea III):

Tutorial anterior | NEXT Tutorial

În tutorialul nostru anterior despre „ Documentație de testare a acceptării cu scenarii în timp real ”Am discutat despre planul de testare a acceptării.

În acest tutorial, vom analiza în detaliu raportarea stării testului de acceptare, a rezumatului testului de acceptare și a deconectării.

Unele șabloane generice sunt incluse în acest tutorial pentru a vă îmbunătăți înțelegerea într-un mod mai bun. De asemenea, vom trece peste conceptul de testare a acceptării în dezvoltarea agilă și testul de acceptare.

Pe scurt, acest tutorial vă va explica despre raportul de stare al testului de acceptare și raportul rezumat, împreună cu câteva șabloane generice pentru înțelegerea dvs. clară și, de asemenea, prezintă conceptul de testare a acceptării în dezvoltare agilă și bazată pe testare într-un mod ușor de înțeles.

Șablon de test de acceptare

Ce veți învăța:

Raport de stare a testului de acceptare

Raportul testului de acceptare trebuie să rezume întotdeauna testele de acceptare care sunt efectuate împreună cu rezultatele lor. Ar trebui să se adreseze tuturor părților interesate identificate care fac parte din faza de testare a acceptării. Odată ce au început executarea testelor de acceptare, progresul ar trebui raportat în fiecare zi.

Șablon generic pentru raportul de stare al testului de acceptare:

Data :Data raportului de stare a testului de acceptare

Teste de acceptare de azi Detalii de execuție:

  • Numărul de teste promovate
  • Numărul de teste nu a reușit
  • Numărul de teste în curs

Teste de acceptare Detalii de execuție până în prezent:

  • Numărul total de teste
  • Numărul de teste promovate
  • Numărul de teste nu a reușit
  • Numărul de teste în curs
  • Numărul de teste în așteptare

Detalii defecte:

cum să găsiți fișiere apk pe tableta Android
  • Numărul de defecte înregistrate
  • Fiecare defect ar trebui să aibă detaliile de mai jos:
    • ID, rezumat, componentă, severitate
  • Numărul total de defecte înregistrate până acum (în faza de testare a acceptării).

Acest raport trebuie revizuit zilnic pentru a se asigura că execuția este pe drumul cel bun și că nu există nicio abatere de la programele planificate.

Raport sumar al testului de acceptare

Acesta este raportul care rezumă starea întregii faze de testare a acceptării. Aceasta implică detalii precum activitățile de testare desfășurate, referințe la criteriile îndeplinite, specificațiile cerințelor, regulile de afaceri, rezultatele executării, planificările planificate, abaterile etc.

Șablon generic pentru raportul sumar al testului de acceptare:

rezumat

Variante

Variante

Rezultate

Rapoarte

Evaluare

Recomandare

severitatea defectelor , și rata de promovare are impact asupra recomandării pentru produsul care urmează să fie lansat pe piață.>

Eforturi

Eforturi

Raport de deconectare

Odată ce produsul a trecut testul de acceptare, se va recomanda să activați. Înainte de a fi lansat în producție, trebuie să fie semnat formal.

Șablon generic pentru raportul de deconectare:

Numele produsului, versiunea de lansare, numărul de construcție

Ultimul raport

Revizuit pe

Revizuite de

Examinați comentariile

Data semnării

Deconectare de

Comentarii de deconectare

În general, oricare dintre rapoartele de mai sus ar trebui să fie revizuit de către principalele părți interesate pentru șablonul său și trebuie să fie convenit asupra a ceea ce trebuie să fie ca informațiile din interior.

Toate detaliile care sunt completate în raport trebuie verificate înainte de a fi partajate cu părțile interesate. Orice discrepanțe din raport vor avea un impact puternic asupra deciziei comerciale și ar putea duce la eșecul produsului pe piață.

Prin urmare, raportarea ar trebui să fie întotdeauna gestionată de specialiști sau membri superiori ai echipei.

Testarea acceptării în Agile

În Agil , Criteriile de acceptare ale fiecărei povești ale utilizatorilor sunt vizate pentru testele de acceptare, adică testele de acceptare sunt derivate din criteriile de acceptare ale unei povești ale utilizatorului. Fiecare criteriu de acceptare poate avea unul sau mai multe teste de acceptare pentru a acoperi scenariul.

Testele de acceptare sunt, de obicei, proiectate de o autoritate de asigurare a calității care este expertiza în materie în zonă. Testarea acceptării în Agile începe mult mai devreme în comparație cu celelalte abordări, de obicei în sprinturile în sine.

Se efectuează foarte frecvent, deoarece fiecare sprint va avea povești noi ale utilizatorilor și, de asemenea, îmbunătățiri / continuarea poveștilor anterioare.

Testarea acceptării se efectuează în două etape diferite în Agile:

  • Când caracteristica este creată și în etapa inițială - de bază.
  • Când caracteristica este integrată și stabilizată cu celelalte caracteristici ale produsului.

Fiecare poveste de utilizator de aici trebuie să fie supusă testului de acceptare și trebuie trecută pentru a fi luată în considerare. Orice eșecuri în testul de acceptare ar trebui considerat ca fiind o prioritate ridicată și remediat imediat, acesta, la rândul său, va avea testul de acceptare pentru a-l executa.

Puncte de poveste sunt date fiecărei povești de utilizator pe baza succesului rezultatelor testului de acceptare pentru fiecare dintre criteriile de acceptare. Testarea acceptării definește, de asemenea, finalizarea la nivelul Povestii utilizatorului, afirmând că sunt îndeplinite criteriile de acceptare pentru poveste.

Cine face testarea acceptării în Agile?

De obicei, managerii de produse, expertiza în materie (pot fi testeri clienți ȘI / SAU beta) efectuează teste de acceptare într-un mediu agil. Uneori, QA implică și această activitate împreună cu sarcinile lor de regresie obișnuite.

Avantajele testării acceptării în Agile

Există mai multe avantaje ale testelor de acceptare în Agile.

Beneficiile sunt:

  • Colaborare mai strânsă între managerul de produs și echipă.
  • Creează încredere la nivelul User Story.
  • Va ajuta la obținerea mai multor scenarii pentru a acoperi fiecare criteriu de acceptare.
  • Probabilitate crescută de a improviza soluțiile pentru produs prin criterii de acceptare în User Stories.

Dezavantaje

Deși există mai multe beneficii, există și anumite dezavantaje.

Dezavantajele includ:

  • Nu toate poveștile pot fi luate în considerare pentru testarea acceptării. Numai poveștile funcționale care urmează să fie acoperite - Acoperirea în funcție de poveste poate să coboare.
  • Nu toate criteriile de acceptare pot fi luate în considerare pentru testarea acceptării. Trebuie acoperite numai criteriile funcționale - Criteriile de acceptare acoperire înțeleaptă în povestea utilizatorului poate coborî.
  • Întrucât sunt implicate părți interesate din medii diferite și întrucât testarea acceptării în funcție de poveste este efectuată direct, este destul de dificil pentru toată lumea să fie pe aceeași pagină (practic în înțelegerea nivelului în povestea individuală a utilizatorului).
  • Deoarece durata de lansare este mai mică în comparație cu alte abordări, este destul de dificil să se accepte testele de acceptare în Sprints.

Acceptance Test Driven Development (ATDD)

Aceasta este una dintre practicile de dezvoltare Agile în care întreaga echipă discută în colaborare fiecare dintre criteriile de acceptare din User Story și construiește teste de acceptare puternice în jurul lor.

Acest lucru se datorează faptului că perspective diferite de la fiecare membru al echipei vor oferi un nou mod de gândire pentru fiecare dintre criteriile de acceptare și vor ajunge cu un număr bun de teste de acceptare care acoperă mai multe scenarii. Uneori, ATDD se mai numește Story Test Driven Development (STDD).

De fapt, ATDD se întâmplă înainte de începerea dezvoltării. Deci, dezvoltatorii, în această abordare, vor ști ce se așteaptă de fapt și cum să-l realizeze. Întreaga echipă va împărtăși o înțelegere comună a caracteristicii și a ceea ce este construit.

Aceasta descrie modul în care produsul este construit și, la rândul său, va da o idee corectă despre modul în care produsul va funcționa efectiv înainte de a fi predat pentru testare. Prin urmare, este denumit „ Dezvoltare determinată de testul de acceptare ”.

Concluzie

Testarea acceptării în oricare dintre abordările sale are scopul comun de a construi încrederea și satisfacția clienților cu privire la produsul dezvoltat înainte de a fi lansat. Acest lucru se obține numai atunci când nu există / mai puține defecte de gravitate scăzută în produs care nu împiedică niciuna dintre funcționalități.

Pe scurt:

  • Testele de acceptare sunt promovate.
  • Defectele sunt la niveluri acceptabile.
  • S-a realizat o acoperire în funcție de flux / scenariu.
  • Produsul și soluțiile sale sunt acceptate.
  • Clientul este suficient de încrezător în produs.
  • Toate documentele despre produs sunt actualizate pentru a se potrivi cu cele mai recente funcții.
  • Rezultatul efortului echipei.
  • Mă bucur să merg mai departe cu lansarea producției.

Tutorial anterior | NEXT Tutorial

Sper că ați fi câștigat cunoștințe imense din aceste tutoriale de testare a acceptării. Simțiți-vă liber să ne împărtășiți gândurile și să ne prezentați întrebările în secțiunea de comentarii de mai jos.

Lectură recomandată

^