Meniu

Implementarea practică în 7 pași a testării manuale înainte de lansarea producției

7 step practical implementation manual testing before production release

Încercați Instrumentul Nostru Pentru Eliminarea Problemelor

În postarea anterioară a acestei serii în jurul testării manuale, am încercat să arunc cât mai multă lumină posibil pe elementele de bază ale testării manuale.

Dacă ți-a fost dor, îl puteți citi aici .

Sper că a avut succes în a vă lua cât mai aproape de răspunsurile pe care le căutați.

În acest caz, nu ți-ar plăcea să afli mai multe despre implementarea practică a testării manuale, cum să te familiarizezi cu ea și cum să începi de fapt o carieră în ea?

Acest articol va arunca o lumină asupra tuturor acestor aspecte.

Implementarea testării manuale

Să începem.

Ce veți învăța:

Ciclul de testare manuală

A întelege Ciclul de testare manuală sau Ciclul de viață al testului software (STLC), în primul rând, trebuie să înțelegem Ciclul de viață al dezvoltării software-ului (SDLC), despre care sunt sigur că aveți deja o înțelegere.

Oamenii se referă la ei separat, dar nu sunt siguri dacă pot coexista cu adevărat. Sunt atât de strâns integrate unul cu celălalt. Ei bine, chiar și aceste cicluri au atât de multe versiuni ale acestora create și plutitoare în spațiul de internet, acestea variază în principal în funcție de modelul de dezvoltare selectat.

Ca majoritatea lumea merge agil în aceste zile, voi păstra lucrurile mele simplificate în jurul Agile.

7 pași practici de testare manuală înainte de lansarea producției

Iată-mă.

Amintiți-vă că vorbesc atât despre SDLC, cât și despre STLC.

# 1) Adunarea cerințelor

Cerință Faza de adunare

Analistul de afaceri (persoană / echipă responsabilă pentru colectarea cerințelor) documentează cerințele. Acestea documentează cerințele, acesta este punctul culminant, puteți să vă concentrați doar pe asta. Unde este documentat contează mai puțin.

Oamenii folosesc orice pentru a le documenta, ceea ce li se potrivește, dar nu se limitează la platformele tradiționale cum ar fi MS Word doc, platformele moderne precum Jira / Rally și instrumentele new age precum Trello.

# 2) Discutarea / Distribuirea cerințelor

Faza de discuție a cerințelor

Business Analyst ar trebui apoi să împărtășească cerințele documentate cu echipa de dezvoltare, echipa de testare și echipa UX (dacă este necesar). Acest lucru se întâmplă de obicei printr-o întâlnire formală în care SPOC-urile (punct unic de contact sau o întreagă echipă, depinde) din toate cele trei funcții îndeplinesc și înțeleg întreaga cerință.

Într-o cultură a muncii sănătoase, cerințele sunt discutate din orice unghi și fiecare membru al întâlnirii poate pune întrebări și îndoieli. Odată ce toate întrebările au primit răspuns și este necesară modificarea cerinței, această fază poate fi considerată ca fiind Finalizată. Din nou, ceea ce se numește această întâlnire / pas special și documentația sa diferă de la o companie la alta.

Lecturi suplimentare=> Cum să revizuiți documentul SRS

Odată ce toate întrebările au primit răspuns și au fost făcute modificările necesare în cerință, această fază poate fi considerată ca fiind Terminat .

Din nou, ceea ce se numește această întâlnire / pas special și documentația sa diferă de la o companie la alta.

De exemplu, documentația este denumită sau descompusă ca SRS (Specificația cerințelor de sistem), Documentul cerințelor, Epic, Povestea utilizatorului, Punctul povestirii (posibil, cea mai mică unitate de cerință) etc. Pe liniile similare, această întâlnire în care este împărțită cerința este numită Cerințe Întâlnire de discuții, îngrijire, ședință de perforare etc., sper să îmi dai punctul meu?

Apăsând pe aceste terminologii, astfel încât să vă amintiți întotdeauna ideea principală, indiferent de diferitele nume.

Postați această întâlnire, doi pași se declanșează în același timp, fără o ordine specială, consultați următorii doi pași.

# 3) Proiectare

Echipa de dezvoltare începe cu proiectarea tehnică imediat ce sunt discutate cerințele și când nu există puncte majore în așteptare. Ceea ce se face în această fază diferă din nou de la o companie la alta.

Această fază poate implica, dar nu se limitează la următoarele sarcini:

  • Decizia abordării de dezvoltare
  • Pregătirea documentului de proiectare
  • Proiectarea diagramelor de flux
  • Estimarea eforturilor
  • Descoperirea impactului acestei noi cerințe asupra oricărei funcționalități existente
  • Trebuie să remediați datele existente etc.

Echipa UX se poate implica, de asemenea, în această fază atunci când există o modificare a interfeței de utilizare sau urmează să fie dezvoltat un nou ecran. Echipa UX ajută echipa de dezvoltare și echipa de testare cu prototip UI pentru funcționalitatea / caracteristica din discuție. Acesta poate fi un document Photoshop, o imagine simplă, o prezentare PowerPoint sau orice altceva care va face echipa de dezvoltare să înțeleagă cum ar trebui să fie dezvoltate ecranele.

Notă: În mod ideal, aceste ecrane sau cel puțin versiunile lor de versiune preliminară sunt afișate în sesiunea de discuții privind cerința numai pentru a ajuta echipa să construiască o mai bună înțelegere. Acesta este etichetat la cerința inițială, astfel încât să poată fi menționat în orice moment.

# 4) Scenariul de testare / proiectarea cazului de testare

Faza de proiectare a scenariului de testare

În paralel cu faza de proiectare, echipa de testare începe cu construirea scenariilor de testare și / sau a cazurilor de testare pe baza cerințelor discutate. Faptul că scenariile de testare sunt întotdeauna scrise mai întâi și apoi se sparg în cazuri de testare este ceva care nu este din nou constant.

În opinia mea, indiferent dacă documentați scenariile de testare sau nu, acestea sunt întotdeauna acolo înainte de cazurile de testare. Test Scenario este punctul tău glonț pe care îl poți spune, te ghidează pentru a detalia lucrurile în continuare. Odată încheiată scrierea cazului de testare, acesta poate fi împărtășit cu echipa de dezvoltare pentru a le oferi o idee despre sfera testării și se pot asigura, de asemenea, că dezvoltarea care s-a întâmplat sau se întâmplă satisface cazurile de testare scrise.

Odată încheiată scrierea cazului de testare, acesta poate fi împărtășit cu echipa de dezvoltare pentru a le oferi o idee despre sfera testării și se pot asigura, de asemenea, că dezvoltarea care s-a întâmplat sau se întâmplă satisface cazurile de testare scrise.

Testarea cazurilor odată scrise în mod ideal este examinată de un conducător de testare sau de un coleg din mai multe unghiuri, cum ar fi:

  • Acoperirea cerințelor
  • Gramatica ortografică
  • Testarea standardelor de scriere a cazurilor (nimic altceva decât un șablon pe care o urmează o echipă / companie)
  • Compatibilitate inversă
  • Compatibilitatea platformei
  • Referințe de date de testare
  • Tipuri de testări vizate etc.

Lecturi suplimentare=> Scrierea cazurilor de testare din documentul SRS

În mod ideal, numai după revizuire și modificări necesare, acestea sunt transmise echipei de dezvoltare.

Când am spus „odată ce scrierea cazului de testare s-a încheiat”, am vrut să spun că „toate cazurile de testare sunt scrise pe baza cunoașterii complete a cerințelor date și a posibilelor scenarii de testare descoperite până la acel moment”. Este aproape imposibil să aveți o acoperire de 100% a cazurilor de testare la prima trecere.

Vor exista defecte pe care le veți găsi în acțiuni aleatorii (dar intenționate), în acțiuni pur aleatorii (testarea maimuțelor) și în unele scenarii rare. Există șanse să ratați câteva dintre acestea. Și la un moment dat s-ar putea să ratezi chiar și cele foarte elementare, la urma urmei, ești om. Dar aici, cel puțin o analiză bună a cazului de testare și un mod structurat de scriere a cazului de testare vă pot salva.

Cel mai adesea, un tester sau o echipă de testare continuă să adauge din ce în ce mai multe cazuri de testare în bucățile existente pe măsură ce descoperă adevărul sau gândesc mai multe despre cerințe.

Ei bine, până acum unii dintre voi trebuie să se îndoiască de cunoștințele mele despre testarea software-ului, deoarece un cuvânt (care a devenit cam o normă în testarea software-ului) nu este încă folosit de mine. Plan de testare nu?

Lasă-mă să spun ceva despre asta. Cred cu tărie în necesitatea majorității informațiilor menționate în Planul de testare, dar documentarea acestora în același loc și obligativitatea absolută sunt ceva ce consider că este discutabil.

Oricum, acesta este cu totul un subiect separat de discutat. Este dificil să împărtășesc o informație „potrivită tuturor”, dar permiteți-mi să încerc.

Fie dvs., dumneavoastră, împreună cu conducătorul dvs. de testare, sau conducătorul dvs. de testare pregătiți Planul de testare sau documentați informațiile solicitate în diferite locuri.

Lecturi suplimentare=> Cum se scrie un document de plan de testare

Informații care ar trebui să fie absolut înghețate în această etapă:

  • Domeniul de aplicare al testării: Cerință, compatibilitate inversă, platforme, dispozitive etc.
  • Persoana / echipa care urmează să testeze
  • Estimarea efortului de testare
  • Limitări: Orice presupuneri făcute sau limitări acceptate în prealabil.
  • În plus, oamenii documentează criteriile de intrare, criteriile de ieșire, riscul etc., care cred că nu au nevoie de mențiuni separate, deoarece ar trebui să fie o înțelegere normală.
    • Criterii de intrare (Când începeți testarea): puțini încep când există o parte testabilă a funcționalității disponibile pentru testare. Puțini așteaptă ca întreaga funcționalitate să poată fi testată. După ce se constată că fluxul de bază funcționează, începe testarea.
    • Criterii de ieșire (Când să se oprească): Când nu există blocant, defectele critice și majore (supuse impactului) la testarea în fază deschisă pot fi oprite. Sau la jumătatea drumului, atunci când există prea multe defecte cu care se confruntă testarea poate fi oprită de către părțile interesate corespunzătoare.
    • Risc : Risc comercial sau risc funcțional dacă testarea nu are loc conform planului documentat.

# 5) Faza de dezvoltare

Faza de dezvoltare software

Echipa de dezvoltare după faza de proiectare începe cu dezvoltarea efectivă și testarea unităților, pe măsură ce se termină cu dezvoltarea unor bucăți de cerință testabile. Ei pot transmite funcționalitatea pentru testare în bucăți pe măsură ce este implementată sau pot trece întreaga funcționalitate simultan.

Într-un scenariu ideal, revizuirea formală a codului și testarea casetei albe au loc înainte de a transmite funcționalitatea dezvoltată pentru testare. în mod ideal, echipa de dezvoltare ar trebui să se refere și la cazurile de testare furnizate de echipa de testare, în plus față de cerințe și documente de proiectare.

# 6) Faza de testare

După cum sa menționat mai devreme, începutul acestei faze diferă de la o companie la alta, de la o echipă la alta.

Echipa de testare începe testarea fie atunci când este testată (ceva ce poate fi testat independent), o parte a întregii cerințe este dezvoltată, fie când este dezvoltată întreaga cerință.

întrebări și răspunsuri la interviul informatica powercenter

Permiteți-mi să aprofundez în această fază și să vorbesc despre sarcinile importante:

  • Echipa de testare / testare începe cu runda de testare (testare exploratorie și executarea cazurilor de testare scrise) și defecte de înregistrare
  • Echipa de dezvoltare le rezolvă conform priorității.
  • Noua versiune (cod) este luată pe mediul pe care se efectuează testarea
  • Defectele rezolvate sunt apoi verificate de Tester / Echipa de testare și marcate ca Fixate
  • Acest ciclu continuă până când se ating criteriile de ieșire.
  • Vă rugăm să rețineți că, după caz, defectele sunt, de asemenea, marcate ca nevalide, duplicate și pot fi, de asemenea, clasificate ca îmbunătățiri.

Un alt lucru care diferă între companii și companii este numărul de runde de testare de făcut. La fel ca în unele cazuri, prima rundă de testare are loc pe piese cu caracteristici mici, pe măsură ce sunt gata, urmată de o rundă de testare end-to-end pe un alt mediu, odată ce toate cerințele sunt dezvoltate. Dar, din nou, am auzit și de oameni care fac trei runde de testare complete și a patra ca rundă de sănătate / fum.

Prima agendă din spatele efectuării mai multor runde de testare este testarea funcționalității pe diferite medii și a doua pentru efectuarea testelor end-to-end odată ce toate punctele de poveste sunt dezvoltate. Runda de sănătate se întâmplă de obicei să câștige încredere rapidă odată ce toate poveștile dintr-o versiune sunt dezvoltate și testate independent.

Citiți pașii detaliați=> Faza de executare a testului

# 7) Recenzie analist de afaceri (BA)

Analistul de afaceri analizează funcționalitatea solicitată fie făcând referire la rezultatul testului, fie făcând referire la rezultatul testului, plus jucându-se cu aplicația pentru a obține o senzație reală. Acest pas este din nou supus unor acțiuni diferite între companii.

BA poate revizui scopul întregii versiuni dintr-o singură dată sau în bucăți. În funcție de același lucru, acest pas ar putea veni înainte de testarea finală a sănătății sau după runda finală de testare a sănătății de către echipa de testare.

Peste 7 pași se întâmplă pentru ca toate poveștile / cerințele utilizatorilor să fie îndeplinite, în special eliberarea (expedierea). Odată ce toți acești pași sunt finalizați pentru toate cerințele, se spune că versiunea este gata pentru expediere.

# 8) Expediere / Eliberare

Lansarea este etichetată ca Gata pentru expediere, după o analiză reușită de către Business Analyst.

Citire recomandată=> Procesul de lansare a testului

Tipuri de testare manuală (citiți umane)

Ei bine, dacă trebuie să vorbim despre tipurile generale de testare în număr, atunci am găsit undeva 100 de tipuri de teste cu nume diferite . Pentru a fi sincer, nu sunt suficient de inteligent pentru a înțelege distincția dintre toate aceste tipuri (joc de cuvinte).

Este drept și simplu: Testarea funcționalității aplicației în funcție de cerința dată cu eforturi și inteligență umană. Se împarte în continuare în câteva tipuri, în funcție de sfera și agenda de testare. Tipuri enumerate la următorul alin.

Se împarte în continuare în câteva tipuri, în funcție de sfera și agenda de testare. Tipuri enumerate la următorul alin.

Dacă mi se permite, permiteți-mi să vorbesc câteva rânduri de testare umană (pe care îi încurajez pe fiecare tester să facă doar testarea funcțională manuală). Acum nu vă confundați, în opinia mea, testarea funcțională manuală este un subset al testării umane. Pentru că sunt atât de multe lucruri pe care numai mintea umană le poate face.

Mai jos este lista cu unele dintre tipurile de testare populare și importante care pot fi clasificate în Testarea umană:

  • Testare funcțională manuală : Testarea funcționalității aplicației în funcție de cerința dată cu eforturi și inteligență umană. Mai departe se împarte în destul de multe tipuri pe baza domeniului de aplicare și a agendei de testare, cum ar fi testarea sistemului, testarea unității, testarea fumului, testarea sănătății, testarea integrării, testarea regresiei, testarea UI etc.
  • Test de performanta : Acest lucru este clasificat în testarea nefuncțională, nu? Dar, din nou, omul este cel care îl implementează, deși execuția se face fie de către om, fie de instrument. Testerul ar trebui să facă cel puțin această testare în termeni de timp de răspuns (pentru a vedea dacă este acceptabil) dacă nu ar trebui să folosească niciun instrument pentru testarea sarcinii și toate acestea.
  • Browser / Testarea compatibilității platformei: Aplicația testată ar trebui să arate și să funcționeze așa cum era de așteptat (evident că poate exista o diferență minoră în funcție de motorul browserului) între browsere și platforme (sau dispozitive dacă este o aplicație mobilă).
  • Testarea utilizabilității : Permiteți-mi să fiu de acord în primul rând că acesta este un subiect uriaș în sine și deținut de obicei de specialiști în testarea utilizabilității. Încă cred că, ca tester, ar trebui cel puțin să raportăm sau să evidențiem dacă găsim ceva mai puțin utilizabil sau ar trebui să ne împărtășim punctul de vedere.
  • Testarea securității : Din nou, un tip de testare foarte mare și necesită multe cunoștințe practice, desigur. Testerul ar trebui să încerce să învețe și să execute cel puțin teste de bază, cum ar fi modificarea adreselor URL, scriptarea pe site-uri, injecția SQL, deturnarea sesiunii etc., în funcție de cunoștințele disponibile și ori de câte ori este cazul.
  • Testare multi-chiriașă: Dacă aplicația dvs. este multi-chiriaș, adică o singură instanță care deține date de mai mulți clienți, atunci această testare este obligatorie. Indiferent de menționarea explicită a cerințelor, acest lucru trebuie făcut. Datele unui client care sunt prezentate altora reprezintă o infracțiune de dezvoltare și testare.

Notă: Vizualizările de deasupra sunt opiniile mele personale. De asemenea, vă recomand să aruncați o privire la lista extinsă a tipurilor de testare pentru cunoștințele dvs. și să le urmăriți / să le utilizați dacă vi se pare necesar. De-a lungul anilor am înțeles că, indiferent dacă folosiți ceva sau nici, credeți în ceva sau nu, ar trebui să aveți în continuare cunoștințe despre conceptele utilizate pe scară largă în domeniul dvs.

Asta este tot pentru această parte. Mulțumesc că ai citit. Împărtășiți-vă opiniile / feedback-ul în comentarii.

În următoarea și ultima parte a acestui lucru seria tutorialului de testare manuală , Voi încerca să vă ajut pe toți ce pregătire ar trebui să faceți dacă doriți să intrați în domeniul testării și care sunt modalitățile posibile de a intra acolo.

Lectură recomandată

^