acceptance testing documentation with real time scenarios
Documentația testării acceptării (partea II):
Tutorial anterior | NEXT Tutorial
Acest tutorial este continuarea tutorialului nostru anterior, unde am discutat despre testarea acceptării, când trebuie făcut, cine o face, importanța, tipurile, procesul, impactul asupra diferitelor echipe etc.
ce este nepotrivirea cheii de securitate a rețelei?
Documentele joacă un rol foarte important în testarea acceptării și orice problemă cu privire la document are un impact negativ imens. Atunci când nu se exercită o verificare adecvată, atunci poate duce chiar la eșecul produsului.
=> Faceți clic aici pentru seria completă de programe de testare
În acest tutorial, vom afla mai multe despre diferite documentații implicate în testarea acceptării, adică, planul de testare a acceptării, lista de verificare a revizuirii planului de testare, șablonul de testare a acceptării, exemple bazate pe scenarii în timp real, cum să identificați și să scrieți testele de acceptare etc. .
Ce veți învăța:
- Planul de testare a acceptării
- Șablon de plan de test de acceptare
- Revizuirea planului de testare a acceptării
- Teste de acceptare
- Revizuirea testelor de acceptare
- Concluzie
- Lectură recomandată
Planul de testare a acceptării
La fel ca orice alt plan de testare, planul de testare a acceptării include, de asemenea, unele componente precum domeniul de aplicare, abordarea, mediul de testare, resursele, responsabilitățile, referințele testelor de acceptare, criteriile de intrare, criteriile de ieșire, instrumentele etc.
Singurul lucru care diferențiază planul de testare a acceptării de un plan obișnuit de testare este factorii săi care duc la decizia de afaceri. Planul de testare a acceptării este una dintre documentațiile vitale care oferă îndrumări cu privire la modul de efectuare a testelor de acceptare pentru un anumit proiect.
Planul de testare a acceptării trebuie revizuit și aprobat înainte de executarea testului de acceptare. Toate modificările ulterioare trebuie din nou să fie supuse procesului de revizuire și aprobare și trebuie să fie pe urmele.
Revizuirea planului de testare a acceptării se face de obicei de către manageri / analiști de afaceri / clienți.
Puncte cheie care trebuie luate în considerare la proiectarea planului de testare a acceptării:
- Ar trebui să fie Detaliat și specific. Trebuie să includă doar ceea ce este necesar pentru testare și ce informații sunt necesare pentru ca echipa să efectueze testarea.
- Ar trebui să fie Clar și concis . Fără ambiguitate. Dacă există ceva care poate duce la confuzie, elaborați-l, dar păstrați-l scurt și eficient.
- Fiecare componentă în document trebuie să fie scris ținând cont doar de cerințele de afaceri.
- Fiabil și adaptabil - Ar trebui să poată fi actualizat după cum este necesar în versiunile viitoare.
- Consistent - Nu ar trebui să aibă mai multe schimbări în viitor.
- Urmați șablonul furnizat de organizație sau client.
Șablon de plan de test de acceptare
Aici vom arunca o privire la un șablon comun pentru planul de testare a acceptării, care poate fi modificat în continuare conform cerințelor proiectului.
Titlu
Obiectiv
Istoricul reviziilor / Jurnalul modificărilor
< Acesta ar trebui să fie sub formă de tabel cu informațiile de mai jos:
- Data - Data la care documentul a fost modificat.
- Modificat de - Cine a schimbat conținutul documentului.
- Scop - De ce a fost modificat documentul.
- Versiune - Versiunea curentă a documentului după modificări (merge ca 1.0, 1.1, 1.2, 1.3, ... pentru o anumită versiune. Următoarea versiune va începe de la 2, 2.1, 2.2, 2.3, ..., Lista continuă).
- Aprobat de - Cine a aprobat modificările aduse (implicit înseamnă că documentul a fost revizuit și aprobat).
Primul rând din acest tabel ar trebui să fie detaliile create de document. Urmează apoi detaliile modificărilor efectuate.>
Cuprins
Referințe
Domeniul de aplicare
Introducere
Elemente de testare
Caracteristici de testat
Caracteristici care nu trebuie testate
Abordare
Detalii despre mediul de testare
Criterii de intrare
Teste - Dacă nu sunt scrise teste de acceptare separate
Fiecare test trebuie să includă:
- Test #.
- O descriere a ceea ce este testat ( Exemplu : Verificați dacă un utilizator este capabil să creeze un cont cu succes).
- Cerința de afaceri la care se aplică acest test ( Matricea de trasabilitate ) - Foarte important.
- Condiții prealabile:
- Starea produsului înainte de începerea testării (utilizatorul ar trebui să fie înregistrat cu succes, dar să nu activeze contul, utilizatorul ar fi trebuit să aibă acces la produs cu cel puțin 30 de zile în urmă etc.)
- Orice condiție de server - Dacă serverul este oprit pentru o perioadă de timp.
- Etape de testare: Flux numerotat detaliat ( Exemplu: Vezi mai jos
- Deschideți aplicația.
- Încercați să vă conectați cu acreditări valide cu caseta de selectare Rețineți-mă bifată).
- rezultat asteptat : Care este comportamentul așteptat al pasului>
Teste de acceptare - Dacă sunt scrise teste de acceptare separate
Criterii de ieșire
Resurse
Roluri si responsabilitati
Instrumente
Factori de decizie în afaceri
Procedură de semnare
Punct de contact
Planul de testare a acceptării este considerat ca fiind Planul principal de testare pentru fază .
Revizuirea planului de testare a acceptării
Odată ce planul este gata, acesta trebuie revizuit pentru a fi complet, non-ambiguitate, claritate, calitate etc. Fără îndoială că întregul conținut din planul de testare a acceptării trebuie revizuit cu atenție pentru informații adecvate, dar trebuie să să fie revizuite în raport cu alte câteva puncte, de asemenea, să spunem punctele listei de control.
Aici, să clasificăm conținutul și să vedem punctele listei de verificare împotriva acestora.
Categorie | Puncte de listă de verificare |
---|---|
Teste de acceptare | Testele sunt numerotate Sunt premisele numerotate Sunt pașii de test clari de înțeles Sunt pașii de test complet Rezultatul așteptat este complet Există vreo întrebare deschisă în teste (dacă există, urmăriți-o și finalizați-o) Referința la testele de acceptare (dacă este scrisă separat) este valabilă și existentă Este trasabilitatea corectă Există o cerință de afaceri ratată pentru acoperirea testului |
Titlu | Titlul se potrivește cu titlul proiectului așa cum este menționat peste tot Titlul urmează convențiilor de numire ale proiectului |
Istoricul reviziilor, Cuprins | Fiecare modificare a versiunii este urmărită corect pentru plan Fiecare modificare a versiunii a fost supusă unei revizuiri adecvate și este menționată Convenția de versiune este corectă Cuprinsul se potrivește cu conținutul real din plan Numărul paginii pentru fiecare conținut este corect Numărul paginii este actualizat dacă modificările făcute în plan au modificat numărul paginii conținutului |
Referințe | Sunt referințele existente și valabile Se potrivesc cu scopul Sunt complete și luate în considerare pentru identificarea testelor |
Elemente de testare, caracteristici de testat, caracteristici de testat | Sunt numerotate Fiecare caracteristică / modul / sub-modul intră în sfera de aplicare Poate programul să acopere toate elementele testate identificate în interior |
Criterii de intrare, Criterii de ieșire | Sunt numerotate Toate criteriile sunt menționate în detaliu |
Detalii despre mediul de testare | Are toate configurațiile necesare menționate Versiunea pentru fiecare configurație este specifică sau cea mai recentă care trebuie luată în considerare VM-urile, mediul există (dacă nu, menționați data posibilă pentru disponibilitatea acestuia) Este menționată metoda de partajare a acreditărilor pentru un anumit acces la mediu |
Resurse, roluri și responsabilități | Responsabilitățile pentru fiecare rol sunt numerotate Pot fi îndeplinite responsabilitățile Resursa identificată este capabilă să gestioneze responsabilitățile menționate |
Instrumente | Sunt toate instrumentele menționate Sunt toate instrumentele numerotate Sunt versionate toate instrumentele Are vreun instrument necesar licență sau licența existentă valabilă în timpul fazei Este corect și suficient ghidul de utilizare a instrumentului? |
Factori de decizie în afaceri | Are toți factorii menționați Sunt toți factorii numerotați |
Procedură de semnare | Procedura este valabilă Procedura este acceptabilă Este clar procedura de înțeles |
Punct de contact | Resursa este identificată ca punct de contact disponibil în organizație în timpul fazei Resursa identificată este capabilă să gestioneze faza |
Orice plan de testare care îndeplinește documentul de listă de verificare de mai sus va servi ca un document puternic și pentru auditurile interne.
Teste de acceptare
Testele de acceptare erau cunoscute anterior ca teste funcționale. Pentru a face numele mai potrivit pentru faza de testare a acceptării și pentru a servi scopului, a fost redenumit ca Teste de acceptare. Uneori este denumit și ca Testele clienților.
Testele de acceptare sunt întotdeauna derivate din poveștile utilizatorilor, criteriile de acceptare și cazurile de utilizare. Acestea sunt teste de sistem cu cutie neagră și reprezintă doar acele teste de afaceri care trebuie verificate. Acestea ar trebui să fie destinate în principal comportamentului, utilizării și fluxurilor produsului.
Testele de acceptare proiectate pot fi luate în considerare și pentru faza de testare a sistemului în ciclurile de regresie pentru a câștiga încredere în produs înainte de a-l preda la faza de testare a acceptării.
Puncte cheie care trebuie amintite înainte de a scrie testele de acceptare:
- Păstrați toate documentele de referință la locul lor: Specificații privind cerințele software, documentul privind cerințele de afaceri, cazuri de utilizare, povești ale utilizatorilor, matrice de date (în caz de logică implicată) etc.
- Concentrați-vă doar pe cerințele companiei (cerințe comerciale testabile).
- Ștergeți toate îndoielile, întrebările cu privire la cerințele afacerii cel mai devreme.
- Asigurați-vă că nu există modificări cu privire la cerințele pentru versiunea curentă cel puțin.
Șablon general și simplu pentru a scrie teste de acceptare:
Acest șablon poate fi modificat din nou conform necesităților proiectului și cu mai multe informații de inclus.
Acum, să luăm câteva scenarii comune și să vedem cum pot fi scrise scenarii de testare a acceptării.
Cazul 1: gestionarea contului de utilizator
Acesta este scenariul în care utilizatorii au permisiunea de a crea, vizualiza, actualiza și dezactiva contul. În general, este o operație CRUD (Creați, citiți, actualizați și ștergeți). Deci, direct vom primi 4 scenarii majore de testat.
Împreună cu aceasta, în gestionarea conturilor de utilizator în timp real, avem multe domenii atunci când vine vorba de vizualizare și actualizare.
Continuarea testelor de acceptare a scrisului:
Testul 1: Înregistrare / Înscriere / Creare cont, verificați dacă un Utilizator este capabil să:
- Creați contul.
- Activați contul.
- Activați contul o singură dată (Aici, linkul de activare trebuie testat pentru 2ndChiar dacă aceasta este o testare negativă, este unul dintre punctele majore de verificare care trebuie luate în considerare).
Testul 2: Pentru a accesa și vizualiza informații despre cont, verificați dacă un utilizator este capabil să:
- Conectați-vă la cont.
- Vizualizați diferite secțiuni din profil (dacă secțiunea Profil este clasificată, atunci fiecare categorie ar trebui să poată fi vizualizată).
- Verificați dacă datele afișate în profil sunt corecte conform informațiilor introduse de utilizator.
Test 3: Pentru a actualiza informațiile despre cont, verificați dacă un utilizator este capabil să:
- Actualizați informațiile despre cont (profil):
- Actualizați fiecare categorie a profilului.
- Verificați dacă informațiile de actualizare sunt reflectate corect în profil.
- Verificați dacă utilizatorul nu poate actualiza informațiile din profil (în unele aplicații, prenumele, prenumele, numele de utilizator etc. nu vor fi permise să se actualizeze. Chiar dacă aceasta este o testare negativă, este unul dintre punctele majore de verificare a fi considerat).
- Anulați fluxul de actualizare (Chiar dacă este vorba de testare negativă, este, de asemenea, unul dintre punctele majore de verificare care trebuie luate în considerare).
Testul 4: Dacă este permisă dezactivarea contului, verificați dacă un Utilizator este capabil să:
- Dezactivați contul.
- Anulați fluxul de dezactivare (Chiar dacă acesta este un test negativ, acesta este unul dintre principalele puncte de verificare care trebuie luate în considerare).
- Accesați contul după anularea dezactivării.
Testul 5: Dacă sunt necesare verificări pentru o adresă de e-mail sau un număr de telefon, atunci verificați dacă un utilizator este capabil să:
în unix, permisiunea de acces w (write) permite
- Actualizați adresa de e-mail la cealaltă validă.
- Verificați ”adresa de e-mail actualizată.
- Verificați dacă adresa de e-mail actualizată și „verificată” este considerată mai departe - Trimiteți câteva e-mailuri din aplicație și verificați sosirea acesteia la adresa de e-mail actualizată. Cel vechi nu ar trebui să primească e-mailuri.
- Adăugați noul număr de telefon.
- Verificați numărul de telefon adăugat prin apel.
- Verificați numărul de telefon adăugat prin SMS.
- Verificați dacă numărul de telefon adăugat și „verificat” se reflectă în cont.
- Actualizați numărul de telefon.
- Verificați numărul de telefon actualizat prin Apel.
- Verificați ”numărul de telefon actualizat prin SMS.
- Verificați dacă numărul de telefon actualizat și „verificat” reflectă în cont.
Cazul 2: achiziționarea unui produs
Achiziționarea produsului are de obicei fluxul general.
Unele scenarii generale la care se uită utilizatorii finali sunt enumerate aici:
Pre-condiție: Utilizatorul ar trebui să fie conectat la aplicație.
Testul 1: Detalii produs, verificați dacă un Utilizator este capabil să:
- Vizualizați pagina Detalii produs.
- Vizualizați toate subsecțiunile din pagina cu detalii despre produs (descriere, caracteristică, informații despre marcă etc.).
- Selectați Cantitatea produsului, Culoare, Dimensiune etc., așa cum este disponibil în pagina Detalii produs.
- Navigați la categoriile, subcategoriile din pagina Detalii produs (dacă este disponibilă în pagina Detalii produs).
- Navigați la pagina de detalii a celuilalt produs (dacă este furnizată secțiunea produselor relevante).
- Vizualizați comentariile și evaluările produsului.
- Sortați comentariile produsului pe baza evaluărilor.
- Vedeți evaluarea generală a produsului.
- Adaugă comentariu la produs.
- Actualizați comentariul său despre produs.
- Ștergeți comentariul său despre produs (dacă este furnizat).
Test 2: Adăugați în coș, verificați dacă un utilizator este:
- Capabil să adauge produsul în coș:
- Prin pagina cu detalii despre produs.
- Prin pagina Listă produse.
- Poate adăuga cantitatea necesară în coș (de la 1 la limita maximă setată).
- Nu pot adăuga produsul în coș dacă este epuizat.
Test 3: În pagina Coș, verificați dacă un utilizator este capabil să:
- Vizualizați produsul din coș cu detalii despre preț pentru cantitatea adăugată.
- Actualizați cantitatea (1 până la limita maximă setată).
- Scoateți produsul din coș.
- Navigați înapoi la cumpărături.
- Continuați până la Checkout.
- Vizualizați coșul gol când nu este adăugat niciun produs,
Test 4: În pagina Detalii cont, verificați dacă un utilizator este capabil să:
- Continuați cu detaliile existente de expediere.
- Actualizați adresa de expediere.
- Adăugați o nouă adresă de expediere.
- Continuați cu numărul de telefon existent.
- Actualizați numărul de telefon pentru comandă.
- Adăugați un nou număr de telefon pentru comandă.
- Navigați înapoi la pagina Coș.
- Navigați la pagina de plată.
Test 5: pe pagina Plăți, verificați dacă un Utilizator este capabil să:
- Verificați corectitudinea sumei de facturat.
- Procesați comanda cu toate opțiunile disponibile (o opțiune pentru fiecare comandă separată).
- Procesează tranzacția cu succes. Accesați pagina Confirmare comandă.
- Eșecul tranzacției (Chiar dacă este vorba de testare negativă, ar trebui considerat ca un scenariu major).
- Aplicați cupoane:
- Cupoane valide - Succes. Aici verificați modificarea sumei de facturat.
- Cupoane nevalide - Eșec
- Cupoane expirate - Eșec.
- Navigați înapoi la pagina Detalii cont.
Revizuirea testelor de acceptare
Revizuirea testelor de acceptare este o sarcină importantă, deoarece trebuie să fie corectă și exactă în ceea ce privește cerințele afacerii. Întrucât acestea pot fi realizate de clienții înșiși și / sau de utilizatorii finali, este foarte necesar să fie complet, neambigu, corect și suficient de detaliat pentru ca oricine să înțeleagă și să execute.
Revizuirea testelor de acceptare trebuie făcută de către analiști de afaceri, clienți și orice comentarii de examinare ar trebui să fie încorporate în prioritate.
La nivelul testului individual, revizuirea trebuie făcută în conformitate cu următoarele:
- Dacă testul acoperă sau nu cerința afacerii.
- Sunt precondițiile clare?
- Pașii testului sunt ușor de înțeles și detaliați?
- Rezultatul scontat este corect și clar?
- Este mapat la cerințele companiei pentru trasabilitate?
- Testul este suficient de complet pentru a acoperi fluxul sau utilizarea particulară?
- Este testul special necesar ca parte a testării de acceptare.
- Există un punct de verificare care nu este necesar pentru testarea acceptării.
- Este pur funcțional sau orice GUI este acoperită (ar trebui să fie doar funcțională).
- Sunt necesare datele speciale de intrare? Dacă da, este prevăzut pentru detalii?
În ansamblu, întreaga revizuire a suitei de teste de acceptare ar trebui să acopere:
- Trasabilitate bidirecțională: Cerințe de afaceri la Teste și Teste la cerințe de afaceri.
- Este acoperită fiecare cerință de afaceri?
- Fiecare cerință comercială este acoperită de unul sau mai multe teste?
- Sunt reglementate regulile de afaceri?
- Este tratat cazul de date speciale?
- Câte teste sunt scrise pentru a acoperi fiecare cerință sau regulă?
- Testele pot fi grupate împreună și clasificate pentru fluxuri.
- Testele sunt secvențiate corect, astfel încât executarea să fie eficientă?
Concluzie
Pe scurt, după cum sa menționat anterior, documentele joacă un rol foarte drastic în testarea acceptării.
Prin urmare, orice test de acceptare care este scris ar trebui să fie bine structurat și să intre în flux cu utilizarea acestuia, astfel încât să mențină testerii de acceptare să fie interesați de ceea ce testează și cum o fac. Acest lucru, la rândul său, ar aduce automat succes.
=> Vizitați aici pentru seria completă de programe de testare
Tutorial anterior | NEXT Tutorial
Rămâneți la curent și urmăriți următorul tutorial de testare a acceptării pentru a afla mai multe despre rapoartele de testare a acceptării, împreună cu câteva șabloane generice. De asemenea, anunțați-ne dacă aveți întrebări.
Lectură recomandată
- Cele mai bune instrumente de testare software 2021 [Instrumente de automatizare a testelor de calitate]
- Testare pozitivă: semnificație și merite explicate cu scenarii de testare reale
- Descărcare eBook Descărcare Primer
- TimeShiftX lansat pentru a simplifica testarea Time Shift
- Ce este testarea acceptării (Un ghid complet)
- Exemplu de șablon pentru raportul testului de acceptare cu exemple
- Ești expert în testare manuală sau automatizată? Lucrați cu jumătate de normă pentru noi!
- Testarea încărcării cu tutoriale HP LoadRunner