difference between test plan
Aflați care este diferența dintre planul de testare, strategia de testare, cazul de testare, scenariul de testare, scenariul de testare și starea de testare cu exemple:
Testarea software-ului include mai multe concepte de bază, precum și importante, pe care fiecare tester de software ar trebui să le cunoască.
Acest articol va explica diferitele concepte din testarea software împreună cu comparația lor.
Planul de testare vs Strategia de testare, Cazul de testare vs Scriptul de testare, Scenariul de testare vs Starea testului și Procedura de testare vs Test Suite sunt explicate în detaliu pentru înțelegerea dvs. ușoară.
=> Faceți clic aici pentru seria completă de programe de testare
Întrebarea de mai sus adresată de Sasi C. este cea mai frecventă întrebare din noi Clasa de testare software și le spun mereu participanților noștri că, cu experiența, cu greu observăm aceste cuvinte și că acestea devin o parte a vocabularului nostru.
Dar de multe ori confuzia le înconjoară și în acest articol încerc să definesc câțiva termeni folosiți în mod obișnuit.
Diverse concepte de testare software
Mai jos sunt enumerate diferitele concepte de testare software împreună cu comparația lor.
Să începem!!
Ce veți învăța:
- Diferența dintre planul de testare și strategia de testare
- Planul de testare
- Documentul planului de testare
- Strategia de testare
- Document de strategie de testare
- # 1) Prezentare generală a proiectului
- # 2) Domeniul de aplicare al cerințelor
- # 3) Plan de testare la nivel înalt
- # 4) Abordarea de testare
- # 5) Acoperirea testului
- # 6) Mediul de testare
- # 7) Livrabile și valorile QA
- # 8) Gestionarea defectelor
- # 9) Managementul comunicării
- # 10) Ipoteze, riscuri și dependențe
- # 11) Anexă
- Planul de testare împotriva strategiei de testare
- Diferența dintre cazul de testare și scriptul de testare
- Diferența dintre scenariul testului și starea testului
- Diferența dintre procedura de testare și suita de testare
- Concluzie
Diferența dintre planul de testare și strategia de testare
Strategia de testare și planul de testare sunt două documente importante în ciclul de viață al testării oricărui proiect. Aici încercăm să vă oferim o cunoaștere aprofundată a strategiei de testare și a documentelor planului de testare.
Planul de testare
Un plan de testare poate fi definit ca un document care definește scopul, obiectivul și abordarea de testare a aplicației software. Planul de testare este un termen și un produs.
Planul de testare este un document care listează toate activitățile dintr-un proiect de asigurare a calității, le planifică, definește domeniul de aplicare al proiectului, rolurile și responsabilitățile, riscurile, criteriile de intrare și ieșire, obiectivul testului și orice altceva la care vă puteți gândi.
Planul de testare este așa cum îmi place să numesc un „super document” care listează tot ceea ce este de știut și de care trebuie. Vă rog verificați acest link pentru mai multe informații și un eșantion.
Planul de testare va fi conceput pe baza cerințelor. În timp ce atribuie lucrări inginerilor de testare, din anumite motive, unul dintre testeri este înlocuit cu altul. Aici, Planul de testare este actualizat.
Strategia de testare prezintă abordarea de testare și orice altceva care o înconjoară. Este diferit de Planul de testare, în sensul că o strategie de testare este doar un subset al planului de testare. Este un document de testare dur, care este într-o măsură generic și static. Există, de asemenea, un argument cu privire la ce niveluri se folosește strategia sau planul de testare, dar chiar nu văd nicio diferență semnificativă.
Exemplu: Planul de testare oferă informații despre cine va testa la ce oră. De exemplu, Modulul 1 va fi testat de „testerul X”. Dacă testerul Y îl înlocuiește pe X din anumite motive, planul de testare trebuie actualizat.
Documentul planului de testare
Planul de testare este un document care oferă informații complete despre sarcinile de testare legate de un proiect software. Oferă detalii precum Scopul testării, Tipuri de testare, Obiective, Metodologie de testare, Efort de testare, Riscuri și Contingențe, Criterii de lansare, Livrabilități de testare etc. Urmărește evidența posibilelor teste care vor fi rulate pe sistem după codificare.
Planul de testare este în mod evident setat să se schimbe. Inițial, un proiect de plan de testare va fi dezvoltat pe baza clarității proiectului în acel moment. Acest plan inițial va fi modificat pe măsură ce proiectul progresează. Managerul echipei de testare sau conducătorul de testare poate pregăti documentul planului de testare. Acesta descrie specificațiile și poate fi modificat pe baza acelorași.
Ce să testați, când să testați, cine va testa și cum să testați va fi definit în planul de testare. Planul de testare va rezolva o listă de probleme, dependențe și riscurile subiacente.
Tipuri de plan de testare
Planurile de testare pot fi de diferite tipuri pe baza etapei de testare. Inițial, va exista un plan principal de testare pentru întreaga execuție a proiectului. Pot fi create planuri de testare separate pentru tipuri de testare specifice, cum ar fi testarea sistemului, testarea integrării sistemului, testarea acceptării utilizatorilor etc.
O altă abordare este de a avea planuri de testare separate pentru testarea funcțională și nefuncțională. În această abordare, testarea va avea un plan de testare separat.
Conținutul documentului planului de testare ( Structura planului de testare IEEE-829 )
Este dificil să desenați un format clar pentru planul de testare. Formatul planului de testare poate varia în funcție de proiectul în cauză. IEEE a definit un standard pentru planurile de testare care sunt descrise ca structura planului de testare IEEE-829.
Găsiți mai jos recomandările IEEE pentru un conținut standard al planului de testare:
- Identificatorul planului de testare
- Introducere
- Elemente de testare
- Probleme de risc software
- Caracteristici de testat
- Caracteristici care nu trebuie testate
- Abordare
- Element Criterii de trecere / nereușită (sau) Criterii de acceptare
- Criterii de suspendare și cerințe de reluare
- Testați livrabilele
- Sarcini de testare
- Cerințe de mediu
- Nevoi de personal și instruire
- Responsabilități
- Programa
- Aprobări
Citire sugerată => Tutorial pentru planul de testare - Un ghid perfect
Strategia de testare
Strategia de testare este un set de linii directoare care explică proiectarea testului și determină modul în care trebuie efectuate testele.
Exemplu: O strategie de testare include detalii precum „Modulele individuale vor fi testate de membrii echipei de testare”. În acest caz, cine îl testează nu contează - deci este generic, iar schimbarea membruului echipei nu trebuie actualizată, menținându-l static.
Document de strategie de testare
Scopul strategiei de testare este de a defini abordarea de testare, tipurile de teste, mediile de testare și instrumentele care trebuie utilizate pentru testare și detaliile la nivel înalt despre modul în care strategia de testare va fi aliniată cu alte procese. Documentul de strategie de testare este destinat să fie un document viu și va fi actualizat ** atunci când vom obține mai multă claritate privind cerințele, parametrii SLA, mediul de testare și abordarea de gestionare a construcției etc.
Strategia de testare este destinată întregii echipe de proiect care cuprinde sponsori de proiecte, IMM-uri de afaceri, dezvoltare de aplicații / integrare, parteneri de integrare a sistemului, echipe de conversie a datelor, echipe de management de construire / lansare, cum ar fi conducători tehnici, conducători de arhitectură și echipe de implementare și infrastructură.
** Unii susțin că strategia de testare odată definită nu ar trebui actualizată niciodată. În majoritatea proiectelor de testare, de obicei, se actualizează pe măsură ce proiectul progresează.
Mai jos sunt secțiunile importante pe care ar trebui să le aibă un document de strategie de testare:
# 1) Prezentare generală a proiectului
Această secțiune poate începe prin a oferi o imagine de ansamblu asupra organizației urmată de o scurtă descriere a proiectului în mână. Poate include mai jos detalii
- Care a fost nevoia proiectului?
- Ce obiective va atinge proiectul?
Tabelul acronimelor: Este mai bine să includeți un tabel cu acronime cu care cititorul de documente ar putea veni în timp ce se referă la document.
# 2) Domeniul de aplicare al cerințelor
Domeniul de aplicare al cerinței poate include domeniul de aplicare al aplicației și domeniul de aplicare funcțional
Domeniul de aplicare definește sistemul testat și impactul asupra sistemului datorită funcționalității noi sau modificate. Sistemele conexe pot fi, de asemenea, definite.
| Sistem | Impact (funcționalitate nouă sau modificată) | Sistem conex |
|---|---|---|
| Descrie cum se testează, când se testează, cine va testa și ce să testeze. | Descrie ce tip de tehnică să urmeze și ce modul să testeze. | |
| Sistemul A | Noi îmbunătățiri și remedieri de erori | • Sistemul B • Sistemul C |
Domeniul de aplicare funcțional definește impactul asupra diferitelor module din sistem. Aici va fi explicat fiecare sistem legat de funcționalitate.
| Sistem | Modul | Funcționalitate | Sistem conex |
|---|---|---|---|
| Sistemul C | Modulul 1 | Funcționalitate 1 | Sistemul B |
| Funcționalitate 2 | Sistemul C |
# 3) Plan de testare la nivel înalt
Planul de testare este un document separat. În strategia de testare, poate fi inclus un plan de testare la nivel înalt. Un plan de testare la nivel înalt poate include obiectivele și domeniul de aplicare al testului. Domeniul de testare ar trebui să definească atât activitățile din domeniu, cât și din afara domeniului.
# 4) Abordarea de testare
Această secțiune descrie abordarea de testare care va fi urmată în timpul ciclului de viață al testării.
Conform diagramelor de mai sus, testarea va fi efectuată în două faze, adică Strategia și planificarea testelor și Executarea testelor. Faza de strategie și planificare a testelor va fi o singură dată pentru un program general, în timp ce fazele de execuție a testului vor fi repetate pentru fiecare ciclu al programului general. Diagrama de mai sus prezintă diferite etape și rezultate (rezultat) în fiecare fază a abordării de execuție.
Abordarea testului ar trebui să includă mai jos subsecțiuni
a) Programul de testare: Explicați cronologia proiectului propus în această subsecțiune
b) Abordarea testării funcționale: Utilizarea acestei subsecțiuni oferă o prezentare generală a fiecărei faze și a criteriilor de intrare și ieșire respective. Diferite faze de testare sunt testarea unității, testarea sistemului, testarea integrării sistemului, testarea acceptării utilizatorilor și testarea end-to-end.
c) Testarea indicatorilor cheie de performanță:
- Prioritizarea cazului de testare: Definiți abordarea de prioritizare a cazului de testare astfel încât, în cazul constrângerilor de timp, scenariile cu prioritate ridicată să poată fi executate de echipa de testare. Ar trebui să existe un acord între părțile interesate ale proiectului cu privire la posibilele riscuri implicate de neexecutarea tuturor scenariilor planificate.
- Prioritizarea defectelor: Strategia de prioritizare a defectelor este următorul subiect care trebuie acoperit aici. Definiți nivelul de prioritate și dați descrierea fiecărui nivel, cum ar fi critic, ridicat, mediu etc. De asemenea
- Timp de returnare a defectelor: Timpul de răspuns la defecte este definit ca timpul dintre momentul în care defectul a fost ridicat pentru prima dată și momentul în care defectul este remediat și vine pentru o nouă testare. Modificarea rapidă asigură testarea rapidă și respectarea cronologiei proiectului. Pentru fiecare nivel de prioritate a defectului, definiți timpul de schimbare.
| Nivel de prioritate | Timp de schimbare a defectelor |
|---|---|
| 1 - Critic | Timp de raspuns: 2 ore sau mai puțin Remediere gata pentru migrare: 1 zi lucrătoare sau mai puțin |
# 5) Acoperirea testului
Această secțiune descrie procesele pe care echipa QA le va urma pentru a optimiza acoperirea cerințelor de afaceri / funcționale în scenarii de testare și cazuri de testare. Matricea de trasabilitate a cerințelor: (RTM) poate fi utilizat pentru a urmări toate cerințele cu scenariile și cazurile de testare respective.
# 6) Mediul de testare
Definiți diferitele medii QA disponibile. Menționați ce testare se va face în ce mediu și de către cine. Creați un plan de rezervă de mediu pentru a avea grijă de situații de urgență. Accesul la fiecare mediu ar trebui reglementat și solicitat cu claritate.
formulare oraculare și raportează întrebări de interviu
Instrumentele de testare care urmează să fie utilizate, de asemenea, pot fi menționate în această secțiune.
| Activitate | Instrument | Observații |
|---|---|---|
| Managementul testelor | HP ALM | Menționați motivul utilizării acestui instrument |
| Gestionarea defectelor | JIRA | Menționați motivul utilizării acestui instrument |
# 7) Livrabile și valorile QA
Enumerați toate livrabilele QA
| S. Nu | Livrabil |
|---|---|
| 1 | Document de strategie de testare |
| Două | Matricea de trasabilitate a cerințelor |
| 3 | Scripturi de testare ST |
| 4 | Raport rezumat test |
| 5 | Lista de scenarii eligibile pentru automatizare |
Enumerați toate valorile QA
| # | Nume metric | Definiție metrică | Formula metrică | Unitate de măsură metrică | Rapoarte în care se utilizează valorile |
|---|---|---|---|---|---|
| 1 | Valori de acoperire a cerințelor (RCM) | Acoperirea cerințelor de către QA | Raportul dintre numărul de cerințe testate și numărul de cerințe identificate | % | Raport de stare săptămânal al QA, Raport rezumat test |
| Două | Acoperirea testului | Acoperirea cazului de testare a fost executată | Raportul numărului de cazuri de testare executate / numărul de cazuri de testare planificate | % | Raport zilnic de execuție, Raport de stare săptămânal al QA, Raport rezumat test |
# 8) Gestionarea defectelor
Definiți în mod clar o strategie de gestionare a defectelor prin crearea unui flux de lucru pentru defecte, metodologia de urmărire a defectelor și procesul de triere a defectelor. Menționează responsabilitatea defectelor pentru rolurile fiecărui tester. Analiza periodică a defectelor și analiza cauzelor profunde vor îmbunătăți calitatea generală a testării
# 9) Managementul comunicării
Stabiliți orientări pentru rapoarte de stare, întâlniri de stare și comunicare la fața locului-offshore.
# 10) Ipoteze, riscuri și dependențe
Descrieți ipotezele pe care se bazează proiectul. Acestea pot include sincronizarea, resursele și capacitățile sistemului. Descrieți orice dependență, cum ar fi alte proiecte, disponibilitatea resurselor temporare, alte termene care pot avea impact asupra proiectului
# 11) Anexă
Includeți lucruri precum Roluri și responsabilități, Fus orar de lucru și Referințe în această secțiune
Lecturi suplimentare=> Ghid pentru scrierea unui document de strategie de testare bună .
Planul de testare împotriva strategiei de testare
| PLANUL DE TESTARE | STRATEGIA DE TESTARE |
|---|---|
| Este derivat din specificațiile cerințelor software (SRS). | Este derivat din documentul privind cerințele de afaceri (BRS). |
| Este pregătit de conducătorul sau managerul de testare. | Este dezvoltat de managerul de proiect sau de analistul de afaceri. |
| ID-ul planului de testare, caracteristicile de testat, tehnicile de testare, sarcinile de testare, caracteristicile trec sau nu criteriile, rezultatele testelor, responsabilitățile și programul etc. sunt componentele planului de testare. | Obiectivele și domeniul de aplicare, formatele de documentare, procesele de testare, structura de raportare a echipei, strategia de comunicare a clienților etc. sunt componentele strategiei de testare. |
| Dacă există o funcție nouă sau o modificare a cerinței care se întâmplă, documentul planului de testare se actualizează. | Strategia de testare menține standardele în timpul pregătirii documentului. Este, de asemenea, numit ca document static. |
| Putem pregăti planul de testare individual. | În proiectele mai mici, strategia de testare este adesea găsită ca o secțiune a unui plan de testare. |
| Putem pregăti un plan de testare la nivel de proiect. | Putem folosi strategia de testare pentru mai multe proiecte. |
| Putem descrie specificațiile utilizând un plan de testare. | Strategia de testare descrie abordările generale. |
| Planul de testare se va schimba pe parcursul proiectului. | Strategia de testare nu se va schimba de obicei după aprobare. |
| Planul de testare este scris după semnarea cerințelor. | Strategia de testare se face înainte de planul de testare. |
| Planurile de testare pot fi de diferite tipuri. Va exista un plan de testare master și un plan de testare separat pentru diferite tipuri de testare, cum ar fi planul de testare a sistemului, planul de testare a performanței etc. | Va exista un singur document de strategie de testare pentru un proiect. |
| Planul de testare trebuie să fie clar și concis. | Strategia de testare oferă îndrumări generale pentru proiectul în cauză. |
Diferența dintre aceste două documente este subtilă. O strategie de testare este un document static la nivel înalt despre proiect. Pe de altă parte, planul de testare va specifica ce să testați, când să testați și cum să testați.
Diferența dintre cazul de testare și scriptul de testare
În opinia mea, acești doi termeni pot fi folosiți în mod interschimbabil. Da, spun că nu există nicio diferență. Cazul de testare este o secvență de pași care ne ajută să efectuăm un anumit test pe aplicație. Scriptul de testare este, de asemenea, același lucru.
Acum, există o școală de gândire că un caz de testare este un termen folosit în mediul de testare manuală, iar scriptul de testare este utilizat într-un mediu de automatizare. Acest lucru este parțial adevărat, datorită nivelului de confort al testerilor în domeniile respective și, de asemenea, cu privire la modul în care instrumentele se referă la teste (unii apelează scripturi de testare, iar unii îi apelează la testarea cazurilor).
Deci, de fapt, scriptul de testare și cazul de testare sunt ambii pași care trebuie efectuați pe o aplicație pentru a-și valida funcționalitatea, fie manual, fie prin automatizare.
Lecturi suplimentare=> Cum se scriu cazuri de testare eficiente? și Model de exemplu de caz de testare .
| CAZ DE TESTARE | SCRIPT DE TEST |
|---|---|
| Este formularul de bază pentru a testa o cerere în ordine. | Odată ce ne dezvoltăm, scriptul îl va rula de mai multe ori până când se modifică cerința. |
| Este un proces pas cu pas care este folosit pentru a testa o aplicație | Este un set de instrucțiuni pentru a testa automat o aplicație. |
| Termenul Test Case este utilizat în mediul de testare manuală. | Termenul Test Script este utilizat în mediul de testare a automatizării. |
| Se face manual. | Se face prin format de script. |
| Este dezvoltat sub formă de șabloane. | Este dezvoltat sub formă de scripting. |
| Șablonul cazului de testare include ID-ul costumului de testare, datele de testare, procedura de testare, rezultatele efective, rezultatele așteptate etc. | În Test Scrip, putem folosi diferite comenzi pentru a dezvolta scriptul. |
| Este folosit pentru a testa o aplicație. | De asemenea, este folosit pentru a testa o aplicație. |
| Exemplu: Trebuie să verificăm butonul de conectare într-o aplicație, Pașii includ: a) Lansați aplicația. b) Verificați dacă butonul de conectare se afișează sau nu. | Exemplu: dorim să facem clic pe un buton imagine dintr-o aplicație. Scenariul include: a) Faceți clic pe butonul Imagine. |
Diferența dintre scenariul testului și starea testului
Scenariu de testare: Este o modalitate de a defini toate modalitățile posibile de a testa o aplicație. Este o singură declarație care acoperă toate modalitățile posibile de a testa o aplicație.
Starea testului: Condiția de testare este specificația pe care un tester trebuie să o respecte pentru testarea unei aplicații.
Acesta este un indicator cu o singură linie pe care testerii îl creează ca etapă inițială, de tranziție, în faza de proiectare a testului. Aceasta este în principal o definiție cu o singură linie a „Ce” vom testa cu privire la o anumită caracteristică. De obicei, scenariile de testare sunt introduse pentru crearea cazurilor de testare.
În proiectele agile, scenariile de testare sunt singurele rezultate ale proiectării testelor și nu sunt scrise cazuri de testare în urma acestora. Un scenariu de testare poate avea ca rezultat mai multe teste.
Exemple de scenarii de testare:
- Validați dacă o nouă țară poate fi adăugată de administrator
- Validați dacă o țară existentă poate fi ștearsă de către administrator
- Validați dacă o țară existentă poate fi actualizată
Condițiile de testare, pe de altă parte, sunt mai specifice. Poate fi definit aproximativ ca scopul / scopul unui anumit test.
Exemplu de condiție de testare: În exemplul de mai sus, dacă ar fi să testăm scenariul 1, putem testa următoarele condiții:
- Introduceți numele țării ca „India” (valabil) și verificați adăugarea țării
- Introduceți un gol și verificați dacă țara este adăugată.
- În fiecare caz, sunt descrise datele specifice, iar scopul testului este mult mai precis.
Lecturi suplimentare=> 180+ exemple de scenarii de testare pentru testarea aplicațiilor web și desktop.
| SCENARIU DE TESTARE | CONDIȚIA TESTULUI |
|---|---|
| Acestea sunt afirmații dintr-o singură linie pentru a explica ce vom testa. | Condiția de testare descrie obiectivul principal de testare a unei aplicații. |
| Este un proces de testare a unei aplicații cu toate modalitățile posibile. | Condițiile de testare sunt regulile statice care trebuie respectate pentru a testa o aplicație. |
| Scenariile de testare sunt o intrare pentru crearea cazurilor de testare. | Oferă obiectivul principal de a testa o aplicație. |
| Scenariul de testare acoperă toate cazurile posibile pentru a testa o aplicație. | Starea testului este foarte specifică. |
| Reduce complexitatea. | Face un bug de sistem gratuit. |
| Scenariul de testare poate fi un singur sau un grup de cazuri de testare. | Acesta este scopul cazurilor de testare. |
| Scriind scenarii va fi ușor să înțelegeți funcționalitatea unei aplicații. | Starea testului este foarte specifică. |
| Exemple de scenarii de testare: # 1) Validați dacă o nouă țară poate fi adăugată de administrator. # 2) Validați dacă o țară existentă poate fi ștearsă de către administrator. # 3) Validați dacă o țară existentă poate fi actualizată. | Exemple de condiții de testare: # 1) Introduceți numele țării ca „India” și verificați adăugarea țării. # 2) Lăsați câmpuri goale și verificați dacă țara este adăugată. |
Diferența dintre procedura de testare și suita de testare
Procedura de testare este o combinație de cazuri de testare bazate pe un anumit motiv logic, cum ar fi executarea unei situații end-to-end sau ceva în acest sens. Ordinea în care trebuie rulate cazurile de testare este fixă.
Procedura de testare: Nu este altceva decât ciclul de viață al testului. Există 10 pași în testarea ciclului de viață.
Sunt:
- Estimarea efortului
- Initierea proiectului
- Studiu de sistem
- Planul de testare
- Caz de testare a designului
- Automatizarea testelor
- Executați cazuri de testare
- Raportați defecte
- Testarea regresiei
- Raport de analiză și rezumat
De exemplu , dacă ar trebui să testez trimiterea unui e-mail de pe Gmail.com, ordinea cazurilor de testare pe care le-aș combina pentru a forma o procedură de testare ar fi:
- Testul pentru a verifica datele de conectare
- Testul pentru a compune un e-mail
- Testul pentru atașarea unuia / mai multor atașamente
- Formatarea e-mailului în modul dorit folosind diverse opțiuni
- Adăugarea de contacte sau adrese de e-mail în câmpurile Către, BCC, CC
- Trimiterea unui e-mail și asigurarea faptului că este afișat în secțiunea „Mesaje trimise”
Toate cazurile de test de mai sus sunt grupate pentru a atinge o anumită țintă la sfârșitul lor. De asemenea, procedurile de testare au câteva cazuri de test combinate în orice moment.
Suita de testare, pe de altă parte, este lista tuturor cazurilor de testare care trebuie executate ca parte a unui ciclu de testare sau a unei faze de regresie etc. Nu există o grupare logică bazată pe funcționalitate. Ordinea în care se execută cazurile de testare constituente poate fi sau nu importantă.
Test Suite: Test Suite este un container care are un set de teste care ajută testerii să execute și să raporteze starea de execuție a testului. Poate lua oricare dintre cele trei stări, adică Active, în curs și finalizată.
Exemplu de test Suite : Dacă versiunea curentă a unei aplicații este 2.0. Versiunea anterioară 1.0 ar fi putut avea 1000 de cazuri de testare pentru a o testa în totalitate. Pentru versiunea 2 există 500 de cazuri de testare pentru a testa doar noua funcționalitate adăugată în noua versiune.
Deci, suita de testare actuală ar fi de 1000 + 500 de cazuri de testare care includ atât regresia, cât și noua funcționalitate. De asemenea, suita este o combinație, dar nu încercăm să realizăm o funcție țintă.
Suitele de testare pot conține 100 sau chiar 1000 de cazuri de testare.
| PROCEDURA DE TESTARE | SUITĂ DE TESTARE |
|---|---|
| Crearea procedurilor de testare se bazează pe fluxul de testare de la capăt la cap. | Suitele de testare sunt create pe baza ciclului sau pe baza domeniului de aplicare. |
| Este o combinație de cazuri de testare pentru a testa o aplicație. | Este un grup de cazuri de testare pentru a testa o aplicație. |
| Este o grupare logică bazată pe funcționalitate. | Nu există o grupare logică bazată pe funcționalitate. |
| Procedurile de testare sunt produse livrabile în procesul de dezvoltare software. | Se execută ca parte a ciclului de testare sau regresie. |
| Ordinea de execuție este fixă. | Este posibil ca ordinea de execuție să nu fie importantă. |
| Procedura de testare conține cazuri de testare de la un capăt la altul. | Suita de testare conține toate funcțiile noi și cazurile de testare de regresie. |
| Procedurile de testare sunt codificate într-un nou limbaj numit TPL (Test Procedure language). | Suita de testare conține cazuri de testare manuale sau scripturi de automatizare. |
Concluzie
Conceptele de testare a software-ului joacă un rol major în ciclul de viață al testării software-ului.
O înțelegere clară a conceptelor discutate mai sus împreună cu comparația lor este foarte importantă pentru fiecare tester de software pentru a efectua procesul de testare în mod eficient.
De obicei, articole ca acestea sunt puncte de plecare excelente pentru discuții mai profunde. Așadar, vă rugăm să contribuiți cu gândurile, acordurile, dezacordurile și orice altceva, în comentariile de mai jos. Așteptăm cu nerăbdare feedback-ul dvs.
De asemenea, salutăm întrebările dvs. despre testarea software-ului în general sau despre orice legătură cu cariera dvs. de testare. Le vom aborda mai detaliat în postările noastre viitoare din aceeași serie.
Lectura placuta!!
=> Vizitați aici pentru seria completă de programe de testare
Lectură recomandată
- Tutorial plan de testare: un ghid pentru a scrie un document de plan de testare software de la zero
- Cum să scrieți un document de strategie de testare (cu un șablon de strategie de testare exemplar)
- Cum să vă pregătiți pentru scrierea cazurilor de testare (Sfaturi de productivitate)
- Ce este scenariul de testare: șablonul scenariului de testare cu exemple
- Diferența dintre planul de testare a performanței și strategia de testare a performanței
- Cum să scrieți cazuri de testare: ultimul ghid cu exemple
- Exemplu de șablon de plan de testare software cu format și conținut
- Test Scenario Vs Test Case: Care este diferența dintre acestea?