Introducere în activitatea de testare software
Care este primul lucru care îți vine în minte atunci când te gândești la un job de testare software? O lucrare fără codificare? Sau o profesie care este foarte ușoară, deoarece vă oferă oportunități de a găsi greșeli în munca celorlalți (găsirea greșelilor când în altele este cea mai ușoară sarcină pentru noi toți)? Sau te gândești la el ca la profesia care se ocupă cu verificarea corectitudinii produsului? Toate aceste gânduri sunt corecte și sunt activități de zi cu zi pentru o muncă de testare software. Cu toate acestea, testarea software nu se limitează doar la aceste activități.
Înțelegerea aplicației
Aplicația ar putea fi din orice domeniu - Asistență medicală, Asigurări, Finanțe, etc. Învățarea domeniului aplicației este foarte importantă pentru orice lucrare software pentru a deschide ușile gândirii din diverse unghiuri și perspective diferite ale utilizatorului în timp ce testează aplicația. Descoperirea și validarea căilor de aplicare evidente și nu atât de evidente este întotdeauna așteptarea primară de la aceasta. Având o cunoaștere aprofundată a aplicației ajută la validarea eficientă a produsului, în același timp, testatorul poate deveni un atu pentru un proiect în care este considerat una dintre principalele surse de cunoștințe în ceea ce privește comportamentul produsului.
În timp ce învățarea domeniului și funcționalității este un proces continuu, orice alt factor important este cunoașterea procesului de testare.
Procesul de testare
Procesul de testare poate varia de la această companie la companie sau chiar de la un proiect la altul. Astăzi avem diverse modele de dezvoltare software cum ar fi modelul V, modelul de prototipare sau o metodologie cu totul diferită, cum ar fi abordarea Agile a dezvoltării de software. Odată cu schimbarea modelului de dezvoltare, abordarea testelor care trebuie urmată variază de asemenea. Lucrul într-un model V va avea procese bine definite, în timp ce acest lucru în metodologie agilă este de așteptat să fie testat în condiții în continuă schimbare.
Locul de muncă nu este încă neted cu cunoștințe de domeniu acceptabile și înțelegere a procesului de testare, următoarea provocare care vine cu viața este de a învăța diverse instrumente.
Unelte
Instrumentele implică instrumente de gestionare a testelor, instrumente de înregistrare defecte, instrumente de gestionare a bazelor de date și așa mai departe.
Cu diverse programe de înregistrare a defectelor, calități și instrumente, unele open source și altele licențiate, este întotdeauna un avantaj să aveți cunoștințe despre mai multe instrumente. Îl ajută să treacă cu ușurință proiecte sau echipe urmând diferite instrumente. Cu o cunoaștere adecvată a domeniului, procesului și instrumentelor, există mai multă viață a activității de testare software, ceea ce face ca zilele sale de muncă să fie provocatoare și interesante. Colaborarea în cadrul echipelor este unul dintre factorii importanți în succesul oricărui proiect și pentru o colaborare eficientă, comunicarea joacă un rol foarte important.
Cursuri recomandate
- Curs complet de J2EE
- Instruire de programare online R
- Du-te curs de programare
- Training de certificare online în programul Haskell
Comunicare
Comunicarea joacă un rol foarte important pentru calitățile software pe care le are, din fazele inițiale ale dezvoltării software, membrii echipei de testare sunt implicați (ca cea mai bună practică) în discuția cerințelor, punând la îndoială analiștii de afaceri în caz de întrebări sau lacune în cerință. Un tster cu abilități de comunicare eficiente poate comunica eficient riscurile, poate comunica eficient cu echipa de dezvoltare și poate comunica eficient rezultatele testelor și rapoartele de testare.
Planificarea lucrărilor de testare software
După cum sugerează și numele, planificarea testelor este faza în care se face pregătirea pentru testare. Pregătirea pentru un tster va implica diferite tipuri de activități pe care un tster le face pentru a aplica în mod eficient. Acest lucru va ajuta la validarea aplicației și la descoperirea eficientă a defectelor din aplicație. Pentru a începe planificarea, un teste parcurge cerințele pentru a înțelege așteptările.
1. Cerințe
Cerințele ar putea fi furnizate echipei de testare sub formă de filme, tablouri de poveste, foi de excel. Scopul tuturor acestor documente este de a prezenta cerințele clientului într-un mod eficient și ușor de înțeles. Documentul Wireframe nu este altceva decât un document care poate fi sub formă de prezentare PowerPoint care prezintă cerințele clientului. Pe aceleași linii, storyboard-urile prezintă de obicei aspectul / design-ul necesar al ecranelor. În prezent sunt disponibile pe piață diverse instrumente care pot fi utilizate pentru pregătirea documentelor necesare. Crearea documentelor necesare este responsabilitatea principală a unui analist de afaceri. Un gust este de așteptat să înțeleagă minuțios cerințele. Pentru ca testul, precum și dezvoltatorii să înțeleagă corect cerințele, analiștii de afaceri țin forumul deschis pentru ca toată lumea să ridice și să primească răspunsurile la oricare dintre cerințe. Platforma pentru a discuta și comunica întrebările și întrebările deschise variază de la proiect la proiect. Ar putea fi lanțul de e-mailuri sau un apel de conferință sau chiar un depozit de unități partajate menținut pentru a ține evidența tuturor întrebărilor deschise și a răspunsurilor acestora, furnizate de analistul de afaceri.
Comunicarea clară și înregistrarea comunicării joacă un rol foarte important pentru o probă. O presupunere mică în cerință poate duce uneori la un defect major al produsului. În fiecare etapă, este recomandat unui tester software calități pentru a menține comunicarea curată. Software Tester Work comunicare ar putea fi cu analiștii de afaceri sau chiar în cadrul unei echipe. O comunicare clară ajută la menținerea ipotezelor la distanță în timpul planificării și execuției. În același timp, se recomandă înregistrarea unei comunicări (de preferință, comunicare prin e-mail). Să aveți o comunicare scrisă cu privire la interogări în cerințe ajută în etapele ulterioare ale execuției testului, în cazul în care funcționalitatea nu ar fi putut fi dezvoltată așa cum este confirmat în comunicarea înregistrată.
2. Scenariu
Odată ce cerințele sunt înțelese, testerul începe să documenteze scenariile din documentul Scenario de testare. Un scenariu așa cum sugerează numele este un flux de funcționalități pe care utilizatorul îl urmărește pentru a îndeplini o sarcină.
Exemple de scenarii -
- Utilizatorul ar trebui să se poată autentifica cu succes.
- Utilizatorul ar trebui să poată rezerva biletele în sistem.
- Utilizatorul ar trebui să poată anula biletele în sistem.
- Utilizatorul ar trebui să poată vizualiza / actualiza detaliile profilului.
Acestea sunt sarcinile logice pe care le realizează un utilizator în sistem. Aceste sarcini logice, atunci când sunt grupate, ajută proverul să ia notă de toate scenariile posibile pe care un utilizator este de așteptat să le efectueze. Aceste scenarii sunt de obicei documentate în foile Excel sau uneori folosind unele instrumente. Un prover se străduiește să extragă toate aceste scenarii din documentele cerințelor. Un document care conține astfel de scenarii este denumit Test Scenario Test (sau undeva ca Document Scenariu la nivel înalt). Acest document servește ca document de intrare pentru redactarea cazurilor de testare.
3. Caz
Acest caz este versiunea mai detaliată a scenariului de lucru cu software Tester în care scenariul este defalcat în pași mai detaliate pe care utilizatorul le va efectua efectiv în timpul utilizării aplicației. Un exemplu simplu bazat pe scenariile menționate mai sus este:
Scenariu - Utilizatorul ar trebui să se poată autentifica cu succes.
Cazuri de testare:
- Verificați dacă utilizatorul poate introduce numele de utilizator corect.
- Verificați dacă utilizatorul poate introduce parola.
- Verificați când faceți clic pe butonul de conectare după ce ați introdus un nume de utilizator și o parolă corecte, utilizatorul este capabil să se autentifice cu succes.
O astfel de listă a acestor cazuri poate continua să includă o verificare de validare pe fiecare câmp, verificarea scenariilor negative și așa mai departe.
Mai jos sunt câteva exemple suplimentare în aceste cazuri -
- Verificați dacă numele de utilizator nu este introdus, sistemul aruncă o eroare corespunzătoare.
- Verificați parola atunci când nu ați fost introduse, sistemul aruncă o eroare corespunzătoare.
- Verificați dacă numele de utilizator și parola atunci când nu sunt introduse, sistemul aruncă o eroare corespunzătoare.
- Verificați dacă introduceți o parolă incorectă, sistemul aruncă un mesaj de eroare adecvat.
- Verificați dacă introduceți un nume de utilizator incorect, sistemul aruncă un mesaj de eroare adecvat.
4. Matricea de trasabilitate a cerințelor (RTM)
Matricea de trasabilitate a cerințelor, după cum sugerează și numele, ajută la dovedirea verificării și încorporării acoperirii cerințelor prevăzute de Business în documentele de testare precum scenarii și cazuri de testare.
Ca o practică optimă, acesta este un document separat care arată maparea numărului cerinței cu cel al scenariilor / cazurilor care încorporează această cerință.
Acest document nu poate fi folosit de toate tipurile de proiecte, dar atunci când este utilizat, acesta ajută într-un mod puternic să urmărească maparea scenariilor la nivel înalt la cerințe. Acesta indică acoperirea și poate fi utilizat pentru a verifica prezența a cel puțin unuia dintre aceste cazuri în funcție de fiecare cerință. Crearea și întreținerea documentului RTM este considerată cea mai bună practică, însă nu toate tipurile de proiecte (cum ar fi Agile) folosesc software dovedesc document de lucru. Când cerințele se schimbă foarte des, menținerea acestui document ar putea fi auzită. Pentru a evita această depășire și, în același timp, să aibă o modalitate de a urmări cerințele, unele proiecte încorporează partea de trasabilitate în cazul de lucru Tester de software sau în documentul său de scenariu.
Aspectul important este de a avea o modalitate de a urmări scenarii / cazuri la cerințe și invers. Cerințele bine documentate facilitează crearea și întreținerea acestor documente pentru Prover. Cerințele ambigue, cerințele în continuă schimbare fac viața proverbe mai dificilă și pot duce la documente livrabile inconsistente, ceea ce duce la pierderea unor validări și, prin urmare, la un defect al produsului final.
Călătoria de până acum pentru un tester plănuia și se pregătea pentru testare. Deoarece pregătirea pentru război este parte a războiului, același lucru se aplică și aici. Cu cât aceste documente sunt mai concise, cu atât mai ușor este validarea funcționalității și descoperirea aproape toate defectele. Următoarea fază a călătoriei testerului este execuția.
Execută lucrări de testare software
Aceasta este faza în care sunt folosite toate documentele menționate mai sus. Cerințele au fost utilizate pentru a crea un scenariu, Scenariul a fost folosit pentru a crea cazuri. acest document de caz este documentul de autosuficiență aici pentru a începe validarea cererii. Prover începe să valideze aplicația executând pași din acest document de caz. Mai multe cazuri pot fi utilizate pentru a valida un singur scenariu sau chiar un singur caz de test poate corespunde unui scenariu de testare. Totul depinde de complexitatea scenariilor sau uneori de standardul urmat în echipa de testare. Prin urmare, un singur document de testare poate conține 20-50 de cazuri de testare sau poate avea 100-120 de cazuri de testare. Aceste numere sunt doar în scop explicativ, pot varia în mod sălbatic de la proiect la proiect. Rezultatul acestei faze este Defectele de testare. Numărul de defecte valide ridicate în această fază oferă o idee bună despre stabilitatea aplicației, calitatea testării, calitatea construcției și mulți astfel de factori care au un impact direct asupra produsului. Această fază este cea mai importantă fază, deoarece testerul prosperă pentru a acoperi toate cazurile de testare (validând aproape toate căile de utilizare necesare) și, în același timp, să ridice cât mai multe defecte valide. Toată pregătirea, abilitățile de comunicare, întrebările solicitate pentru afaceri intră în acțiune în această fază de testare.
Defectele de software funcționează tester
În timpul executării acestor cazuri, orice comportament care nu este egal cu rezultatul scontat este ridicat ca defect. Fiecare caz de test are o Descriere, Rezultatul așteptat și o coloană pentru Rezultatul Real. În timp ce aceste documente de planificare a programului de lucru software au o descriere și rezultatele așteptate și o coloană Blank pentru rezultatele reale În timpul executării cazurilor de testare, se presupune că testatorul completează coloana cu rezultatul real. În același timp, dacă efectivul nu este egal cu rezultatul scontat, defectul este înregistrat. Înregistrarea unui defect nu înseamnă doar informarea dezvoltatorului despre această problemă. Este din nou un proces formal de obicei realizat cu ajutorul unui instrument. În prezent, există diverse instrumente pe piață, unele open source și altele licențiate. Orice instrument de înregistrare a defectelor are următoarele câmpuri -
- Denumirea proiectului / lansării
- Rezumatul defectelor
- Descriere detaliu defect
- Defecțiune Severitate
- Prioritate cu defecte
- Faza a fost găsit defectul
- Atribuit
- Fișiere atașate
După cum putem vedea scopul tuturor acestor câmpuri este de a avea un proces formal detalii înțelepte ale problemei găsite. Acest lucru ajută dezvoltatorii să reproducă defectul din mediul lor și să-l remedieze. Mai jos este o scurtă descriere a tuturor acestor câmpuri -
- Nume proiect / versiune - numele lansării în care a fost găsit defectul, de obicei proiectul are mai multe versiuni și același proiect poate avea mai multe subproiecte. Acest câmp ajută la ridicarea unei probleme pentru o versiune specifică.
- Rezumatul defectelor - O scurtă descriere cu un liner a defectului găsit.
- Descriere detaliu a defectului - Aceasta este descrierea detaliată a defectului, ar trebui să includă detalii precum mediul în care a fost găsit defectul și datele de testare utilizate, rezultatele reale așteptate rezultatul și orice informații suplimentare care adaugă informații mai valoroase pentru părțile interesate să înțeleagă defect.
- Severitatea defectelor - semnifică cât de sever este defectul. De obicei, are valori similare cu valorile critice, ridicate, medii, scăzute sau numerice precum 4, 3, 2, 1.
- Prioritate de defect - semnifică cât de urgent este să remediați defectul.
- Faza a fost găsit defectul - deoarece există multe faze în care un defect poate fi înregistrat, faza de testare a unității, SIT (testarea integrării sistemului), UAT (testarea acceptării utilizatorului) sau chiar faza de producție.
- Alocat - Numele dezvoltatorului sau al dezvoltării.
- Atașări - Aceasta a dat o opțiune testerului de a atașa instantaneul ecranului în care a fost întâlnită problema.
Execuția testelor și înregistrarea defectelor este faza în care există multe provocări cu care se poate confrunta un tester. Unii dintre ei comunică eficient cu dezvoltatorii. S-ar putea să susținem că este înregistrarea unui defect cu toate informațiile necesare nu sunt suficiente pentru ca dezvoltatorii să înțeleagă defectul?
Este și, în unele cazuri, necesită explicații / discuții suplimentare cu dezvoltatorii. Există cazuri în care un tester întâlnește un comportament neașteptat, care ar putea să nu fie sigur dacă este un defect. Aceste circumstanțe sunt, de obicei, confruntate de către prover care sunt noi în echipă, au cunoștințe de domeniu limitate sau au ambiguitate cu privire la cerințe. Ei bine, testatorul nu trebuie învinuit aici dacă există termene stricte și există cerințe în continuă schimbare, iar în majoritatea cazurilor, învață despre domeniu în timp ce planifică și execută cazuri de testare. După cum putem vedea calea unui tester nu este atât de ușor pe cât este perceput. Necesită o atitudine de învățare mereu, abilități bune de comunicare, abilități bune de colaborare și dorință de a se regla în condițiile în care există schimbări în domenii, instrumente, procese utilizate. În timp ce am vorbit despre călătoria testerelor manuale, procesul general se aplică și testerilor de automatizare. Automatizarea, pe de altă parte, are schimbări semnificative în proces, întrucât sfera de testare și planificare, execuția variază semnificativ.
Ținând cont de călătoria proverbei, așa cum s-a discutat mai sus, putem spune că munca calităților de testare software este mai ușoară decât cea a unui dezvoltator?
Se poate spune că, mai mult decât compararea rolurilor de dezvoltator tester v / s, va fi mai util să avem o discuție despre modul în care colaborarea dintre doi poate duce la un succes major al produsului în ansamblu. Uităm uneori că treaba testerului este să găsească probleme în aplicație și să nu puncteze greșelile dezvoltatorilor. Când uităm chiar ideea meseriei noastre, uneori duce la discuții inutile. Cu toate acestea, s-a observat că există echipe de testare la fel de bune, în care toată lumea înțelege că scopul final este de a face ca aplicația să funcționeze așa cum era de așteptat. Să sperăm ca toată lumea să privească partea pozitivă a postului de testare ca un rol care ajută la curățarea produsului și nu ca pe cel care găsește doar greșeli!
Articole recomandate
Acesta a fost un ghid pentru descoperirea și validarea căilor de aplicare evidente și nu atât de evidente, este întotdeauna așteptarea principală a unei lucrări de testare software. Acestea sunt următoarele link-uri externe legate de activitatea de testare software.
- Ciclul de viață defect în testarea software-ului
- 6 Cele mai uimitoare întrebări pentru interviuri de testare software
- Cariere în testare software