Meniu

Ce este testarea software-ului? 100+ Tutoriale gratuite de testare manuală

what is software testing

Încercați Instrumentul Nostru Pentru Eliminarea Problemelor

Un ghid complet de testare software cu peste 100 de tutoriale de testare manuală cu definiție de testare, tipuri, metode și detalii despre proces:

Ce este testarea software-ului?

Testarea software-ului este un proces de verificare și validare a funcționalității unei aplicații pentru a afla dacă îndeplinește cerințele specificate. Este procesul de identificare a defectelor într-o aplicație și verificarea funcționării aplicației în conformitate cu cerințele utilizatorului final.

Ce este testarea manuală?

Testarea manuală este un proces în care comparați comportamentul unei piese de cod dezvoltate (software, modul, API, caracteristică etc.) cu comportamentul așteptat (Cerințe).

Ce veți învăța:

Lista tutorialelor de testare manuală a software-ului

Aceasta este cea mai aprofundată serie de tutoriale despre testarea software-ului. Parcurgeți cu atenție subiectele menționate în această serie pentru a afla tehnicile de testare de bază și avansate.

Această serie de tutoriale vă va îmbogăți cunoștințele și vă va îmbunătăți abilitățile de testare.

Practicați testarea manuală de la un capăt la altul Instruire gratuită într-un proiect live:

Tutorial nr. 1: Bazele testării manuale a software-ului
Tutorial nr. 2: Introducere proiect live
Tutorial # 3: Scrierea scenariului de testare
Tutorial # 4: Scrieți un document de plan de testare de la Scratch
Tutorial # 5: Scrierea cazurilor de testare din documentul SRS
Tutorial nr. 6: Executarea testului
Tutorial nr. 7: Urmărirea erorilor și deconectarea testului
Tutorial # 8: Curs de testare software

Ciclul de viață al testării software-ului:

Tutorial nr. 1: STLC

Testare web:

Tutorial nr. 1: Testarea aplicațiilor web
Tutorial nr. 2: Testarea browserului încrucișat

Managementul cazului de testare:

cel mai bun software de recuperare pentru Windows 10

Tutorial nr. 1: Cazuri de testare
Tutorial nr. 2: Exemplu de șablon de caz de testare
Tutorial # 3: Cerințe Matricea de trasabilitate (RTM)
Tutorial # 4: Acoperirea testului
Tutorial # 5: Gestionarea datelor de testare

Managementul testului:

Tutorial nr. 1: Strategia de testare
Tutorial nr. 2: Șablon de plan de testare
Tutorial # 3: Estimarea testului
Tutorial # 4: Instrumente de gestionare a testelor
Tutorial # 5: Tutorial HP ALM
Tutorial nr. 6: Jira
Tutorial nr. 7: Tutorial TestLink

Teste tehnice:

Tutorial nr. 1: Utilizați testarea cazurilor
Tutorial nr. 2: Testarea tranziției de stat
Tutorial # 3: Analiza valorii limită
Tutorial # 4: Partiționarea echivalenței
Tutorial # 5: Metodologii de testare software
Tutorial nr. 6: Metodologie agilă

Gestionarea defectelor:

Tutorial nr. 1: Ciclul de viață al bug-urilor
Tutorial nr. 2: Raportarea erorilor
Tutorial # 3: Prioritatea defectelor
Tutorial # 4: Tutorial Bugzilla

Testarea funcțională

Tutorial nr. 1: Testarea unitara
Tutorial nr. 2: Testarea sănătății și a fumului
Tutorial # 3: Testarea regresiei
Tutorial # 4: Testarea sistemului
Tutorial # 5: Testarea de acceptare
Tutorial nr. 6: Testarea integrării
Tutorial nr. 7: Testarea acceptării utilizatorului UAT

Testare nefuncțională:

Tutorial nr. 1: Testare nefuncțională
Tutorial nr. 2: Test de performanta
Tutorial # 3: Testarea securității
Tutorial # 4: Testarea securității aplicațiilor web
Tutorial # 5: Testarea utilizabilității
Tutorial nr. 6: Testarea compatibilității
Tutorial nr. 7: Testarea instalării
Tutorial # 8: Testarea documentației

Tipuri de testare software:

Tutorial nr. 1: Tipuri de testare
Tutorial # 2 : Testare cutie neagră
Tutorial # 3: Testarea bazei de date
Tutorial # 4: Testarea cap la cap
Tutorial # 5: Testarea exploratorie
Tutorial nr. 6: Testarea incrementală
Tutorial nr. 7: Testarea accesibilității
Tutorial # 8: Testare negativă
Tutorial # 9: Testare Backend
Tutorial # 10: Testarea alfa
Tutorial # 11: Testarea beta
Tutorial # 12: Testarea Alpha vs Beta
Tutorial # 13: Testarea Gamma
Tutorial # 14: Testarea ERP
Tutorial # 15: Testare statică și dinamică
Tutorial # 16: Testarea adhoc
Tutorial # 17: Testarea localizării și internaționalizării
Tutorial # 18: Testarea automatizării
Tutorial # 19: Testarea cutiei albe

Cariera de testare software:

Tutorial nr. 1: Alegerea unei cariere de testare software
Tutorial nr. 2: Cum să obțineți un job de testare QA - Ghid complet
Tutorial # 3: Opțiuni de carieră pentru testeri
Tutorial # 4: Comutator de testare non-IT către software
Tutorial # 5: Începeți cariera de testare manuală
Tutorial nr. 6: Lecții învățate de la 10 ani de testare
Tutorial nr. 7: Supraviețuiește și progresează în domeniul testării

Pregătirea interviului:

Tutorial nr. 1: Pregătirea CV-ului QA
Tutorial nr. 2: Întrebări de testare manuală pentru interviu
Tutorial # 3: Întrebări de interviu pentru testarea automatizării
Tutorial # 4: Întrebări privind interviul QA
Tutorial # 5: Gestionați orice interviu de muncă
Tutorial nr. 6: Obțineți testarea jobului ca un proaspăt

Testarea diferitelor aplicații de domeniu:

Tutorial # 1 : Testarea aplicațiilor bancare
Tutorial nr. 2: Testarea aplicațiilor de îngrijire a sănătății
Tutorial # 3: Testarea gateway-ului de plată
Tutorial # 4: Sistem de testare punct de vânzare (POS)
Tutorial # 5: Testarea site-ului eCommerce

Testarea certificării QA:

Tutorial nr. 1: Ghid de certificare pentru testarea software-ului
Tutorial nr. 2: Ghid de certificare CSTE
Tutorial # 3: Ghid de certificare CSQA
Tutorial # 4: Ghid ISTQB
Tutorial # 5: ISTQB Advanced

Subiecte avansate de testare manuală:

Tutorial nr. 1: Complexitatea ciclomatică
Tutorial nr. 2: Testarea migrației
Tutorial # 3: Testarea în cloud
Tutorial # 4: Testarea ETL
Tutorial # 5: Valori de testare software
Tutorial nr. 6: Servicii Web

Pregătiți-vă să aruncați o privire la primul tutorial din această serie de testare manuală !!!

Introducere în testarea manuală a software-ului

Testarea manuală este un proces în care comparați comportamentul unei piese de cod dezvoltate (software, modul, API, caracteristică etc.) cu comportamentul așteptat (Cerințe).

Și de unde vei ști care este comportamentul așteptat?

O veți cunoaște citind sau ascultând cu atenție cerințele și înțelegându-le complet. Nu uitați, înțelegerea completă a cerințelor este foarte foarte importantă.

cum se dezvoltă aplicația Java în eclipsă

Gândiți-vă ca utilizator final la ceea ce urmează să testați. După aceea, nu mai sunteți legat de documentul de cerință software sau de cuvintele din acesta. Apoi puteți înțelege cerința de bază și nu doar să verificați comportamentul sistemului în raport cu ceea ce este scris sau spus, ci și cu propria înțelegere și cu lucruri care nu sunt scrise sau spuse.

Uneori, poate fi o cerință ratată (cerință incompletă) sau o cerință implicită (ceva care nu are nevoie de menționare separată, dar ar trebui să fie îndeplinită) și trebuie să testați și acest lucru.

Mai mult, o cerință nu trebuie să fie neapărat una documentată. Puteți avea foarte bine cunoștințe despre funcționalitatea software-ului sau puteți chiar ghici și testa apoi un pas la rând. În general, îl numim testare ad-hoc sau testare exploratorie.

Să aruncăm o privire în profunzime:

Mai întâi, să înțelegem faptul - Fie că comparați testarea unei aplicații software sau altceva (să spunem un vehicul), conceptul rămâne același. Abordarea, instrumentele și prioritățile pot diferi, dar obiectivul de bază rămâne același și este SIMPLE, adică compararea comportamentului real cu comportamentul așteptat.

În al doilea rând - Testarea este ca o atitudine sau mentalitate care ar trebui să vină din interior. Abilitățile pot fi învățate, dar veți deveni un tester de succes numai atunci când aveți câteva calități în interiorul dvs. în mod implicit. Când spun că abilitățile de testare pot fi învățate, mă refer la educație concentrată și formală în jurul procesului de testare software.

Dar care sunt calitățile unui tester de succes? Puteți citi despre acestea la linkul de mai jos:

Citiți-l aici => Calitățile testatorilor extrem de eficienți

Vă recomand cu tărie să parcurgeți articolul de mai sus înainte de a continua cu acest tutorial. Vă va ajuta să comparați caracteristicile dvs. cu cele care sunt așteptate în rolul Software Tester.

Pentru cei care nu au timp să treacă prin articol, iată un sinopsis:

„Curiozitatea, atenția, disciplina, gândirea logică, pasiunea pentru muncă și abilitatea de a diseca lucrurile contează foarte mult pentru a fi un Tester distructiv și de succes. A funcționat pentru mine și cred cu tărie că va funcționa și pentru tine. Dacă aveți deja aceste calități, atunci trebuie să funcționeze și pentru dvs. ”

Am vorbit despre cerințele esențiale ale devenind tester de software. Acum să înțelegem de ce testarea manuală are și ar avea întotdeauna existența sa independentă cu sau fără creșterea testării automatizate.

De ce este necesară testarea manuală?

Știți care este cel mai bun lucru despre a fi un tester, și asta un tester manual?

Este faptul că aici nu puteți depinde doar de setul de competențe. Trebuie să aveți / dezvoltați și să vă îmbunătățiți procesul de gândire. Acesta este un lucru pe care nu îl poți cumpăra cu adevărat pentru câțiva dolari. Tu însăși trebuie să lucrezi la asta.

Va trebui să dezvolta obiceiul de a pune întrebări și va trebui să le întrebați în fiecare minut când testați. De cele mai multe ori ar trebui să-ți pui aceste întrebări decât altora.

Sper că ați parcurs articolul pe care l-am recomandat în secțiunea anterioară (adică calitățile testerilor extrem de eficienți). Dacă da, atunci veți ști că testarea este considerată un proces de gândire și cât de mult succes veți avea ca tester depinde complet de calitățile pe care le dețineți ca persoană.

Să vedem acest flux simplu:

  • Faci ceva ( efectuați acțiuni ) în timp ce îl observați cu o anumită intenție (comparând cu cel așteptat). Acum observare abilități și disciplina pentru a efectua lucruri intră aici în imagine.
  • Voila! Ce a fost asta? Ai observat ceva. Ai observat asta pentru că dădeai perfect atenție la detalii în fața ta. Nu o vei lăsa să plece pentru că ești curios . Acest lucru nu era în planul tău că se va întâmpla ceva neașteptat / ciudat, îl vei observa și îl vei investiga în continuare. Dar acum o faci. O poți lăsa să plece. Dar nu ar trebui să o lași să plece.
  • Ești fericit, ai aflat cauza, pașii și scenariul. Acum veți comunica acest lucru corect și în mod constructiv echipei de dezvoltare și celorlalte părți interesate din echipa dumneavoastră. S-ar putea să o faceți prin intermediul unui instrument de urmărire a defectelor sau verbal, dar trebuie să vă asigurați că sunteți comunicându-l constructiv .
  • Hopa! Dacă o fac așa? Ce se întâmplă dacă introduc un număr întreg corespunzător ca intrare, dar cu spații albe de conducere? Ce-ar fi dacă? … Ce-ar fi dacă? … Ce-ar fi dacă? Nu se termină ușor, nu ar trebui să se termine ușor. Veți imagina o mulțime de situații și scenarii și într-adevăr veți fi tentați să le efectuați și.

Diagrama prezentată mai jos reprezintă Viața unui tester:

Viața unui tester

Citiți încă patru puncte glonț menționate mai sus. Ai observat că l-am ținut foarte scurt, dar am evidențiat totuși cea mai bogată parte a unui tester manual? Și ai observat evidențierea îndrăzneață peste câteva cuvinte? Acestea sunt tocmai cele mai importante calități de care are nevoie un tester manual.

Acum, chiar crezi că aceste acte pot fi complet înlocuite cu altceva? Și trendul fierbinte de astăzi - poate fi vreodată înlocuit cu automatizarea?

În SDLC cu orice metodologie de dezvoltare, puține lucruri rămân întotdeauna constante. În calitate de tester, veți consuma cerințele, le veți converti în scenarii de testare / cazuri de testare. Apoi veți executa aceste cazuri de testare sau le veți automatiza direct (știu că o fac câteva companii).

Când îl automatizați, focalizarea dvs. este constantă, care automatizează pașii scrisi.

Să ne întoarcem la partea formală, adică să executăm cazurile de test scrise manual.

Aici, nu vă concentrați doar pe executarea cazurilor de testare scrise, ci efectuați și o mulțime de teste exploratorii în timp ce faceți acest lucru. Îți amintești, ești curios? Și vă veți imagina. Și nu vei putea rezista, vei face într-adevăr ceea ce ți-ai imaginat.

Imaginea prezentată mai jos descrie modul în care este simplificată scrierea testelor:

Scrierea cazurilor de testare simplificată

Completez un formular și am terminat cu completarea primului câmp. Sunt prea leneș ca să mă duc ca mouse-ul să schimbe focalizarea pe câmpul următor. Apăs tasta „tab”. Am terminat să completez și următorul și ultimul câmp, acum trebuie să fac clic pe butonul Trimite, focalizarea este încă pe ultimul câmp.

Hopa, am lovit din greșeală tasta „Enter”. Lasă-mă să verific ce s-a întâmplat. SAU există un buton de trimitere, voi face dublu clic pe el. Nesatisfacut. Fac clic de mai multe ori, prea repede.

Ai observat? Există atât de multe acțiuni posibile ale utilizatorilor, atât intenționate, cât și neintenționate.

Nu veți reuși să scrieți toate cazurile de test care acoperă cererea dvs. testată 100%. Acest lucru trebuie să se întâmple într-un mod explorator.

Veți continua să adăugați noile cazuri de test pe măsură ce testați aplicația. Acestea vor fi cazuri de testare pentru erorile pe care le-ați întâlnit pentru care anterior nu a fost scris niciun caz de testare. Sau, în timp ce testați, ceva v-a declanșat procesul de gândire și ați primit încă câteva cazuri de testare pe care doriți să le adăugați în suita de cazuri de testare și să le executați.

Chiar și după toate acestea, nu există nicio garanție că nu există bug-uri ascunse . Software-ul cu zero bug-uri este un mit. Puteți viza doar să îl apropiați de Zero, dar asta nu se poate întâmpla fără ca o minte umană să țintească în mod continuu același lucru, similar, dar fără a se limita la exemplul procesului pe care l-am văzut mai sus.

Cel puțin începând de astăzi, nu există niciun software care să gândească ca o minte umană, să observe ca un ochi uman, să pună întrebări și să răspundă ca un om și apoi să efectueze acțiuni intenționate și neintenționate. Chiar dacă se întâmplă așa ceva, a cui minte, gânduri și ochi îi va imita? A ta sau a mea? Noi, oamenii, nu avem același drept. Cu toții suntem diferiți. Atunci?

Necesitatea testării manuale atunci când automatizarea este în jur:

Testarea automatizării are propria sa parte de glorie în zilele noastre și va avea și mai mult în anii următori, dar pur și simplu nu poate înlocui testarea manuală a QA (citiți testarea umană / explorativă).

Trebuie să fi auzit înainte ... Nu automatizați testarea, automatizați verificarea '. Această frază vorbește foarte mult despre locul în care se află testarea manuală a calității calității cu testarea automatizării. Multe nume mari din întreaga lume au scris și au vorbit despre acest subiect, așa că nu mă voi accentua prea mult pe acest subiect.

Automatizarea nu poate înlocui testarea umană, deoarece:

  • Solicită judecăți în timpul rulării cu privire la tot ce se întâmplă în fața ochilor tăi (în timp ce testezi) și în câteva cazuri și în culise.
  • Cere o observare clară și constantă.
  • Se cere întrebări.
  • Cere o anchetă.
  • Cere raționament.
  • Solicită acțiuni neplanificate, după cum este necesar, în timpul testării.

Testarea poate fi înlocuită de un instrument / mașină care va fi capabil să absoarbă detaliile, să le proceseze, să comande acțiuni și să le efectueze ca o minte umană și umană, și toate acestea la rulare și în toate contextele posibile. Acest instrument trebuie să fie din nou ca toți oamenii posibili.

Deci, pe scurt, testarea umană nu poate fi înlocuită. Poate că o serie de filme SF de la Hollywood în câțiva ani vor arăta aproape de ea, dar în viața reală, nu o pot vedea pentru câteva sute de ani, pe care mi le pot imagina. Nu o voi anula pentru totdeauna, deoarece cred în posibilități infinite.

Pe o notă separată, chiar dacă se întâmplă cu adevărat după câteva sute de ani, imaginea pe care mi-o pot imagina este cu siguranță o lume înfricoșătoare. Age of Transformers. :)

= >> Lectură recomandată - Cele mai bune companii de servicii de testare manuală

Cum completează automatizarea testarea manuală?

Am mai spus și spun din nou că automatizarea nu mai poate fi ignorată. În lumea în care integrarea continuă, livrarea continuă și implementarea continuă devin lucruri obligatorii, testarea continuă nu poate rămâne inactiv. Trebuie să aflăm modalități de a face acest lucru.

De cele mai multe ori, implementarea din ce în ce mai multă forță de muncă nu ajută pe termen lung pentru această sarcină. Prin urmare, Testerul (șeful de testare / Arhitectul / Managerul) trebuie să decidă cu precauție ce să automatizeze și ce ar trebui să se facă în continuare manual.

Devine extrem de important să aveți scrise teste / verificări foarte precise, astfel încât să poată fi automatizate fără nicio abatere față de așteptările inițiale și să poată fi utilizate în timp ce regresați produsul ca parte a „testării continue”.

Notă: Cuvântul continuu de la termenul „Testare continuă” este supus unor apeluri condiționale și logice similare celorlalți termeni pe care i-am folosit mai sus cu același prefix. Continuitate în acest context înseamnă din ce în ce mai des, mai rapid decât ieri. În timp ce are sens, poate însemna foarte bine fiecare secundă sau nano-secundă.

Fără a avea o potrivire perfectă de testatori umani și verificări automate (teste cu pași precisi, rezultatul așteptat și criteriile de ieșire ale testului menționat documentate), realizarea testării continue este foarte dificilă și acest lucru, la rândul său, va face integrarea continuă, livrarea continuă și implementarea continuă mai dificil.

Am folosit în mod intenționat termenul de criterii de ieșire a unui test de mai sus. Costumele noastre de automatizare nu mai pot fi similare cu cele tradiționale. Trebuie să ne asigurăm că, dacă eșuează, ar trebui să eșueze rapid. Și pentru a le face să eșueze rapid, și criteriile de ieșire ar trebui automatizate.

Exemplu:

Să presupunem că există un defect de blocare în care nu pot să mă conectez la Facebook.

Funcționalitatea de conectare trebuie să fie apoi prima dvs. verificare automată și suita dvs. de automatizare nu ar trebui să ruleze următoarea verificare în care autentificarea este o condiție prealabilă, cum ar fi postarea unei stări. Știți foarte bine că este obligat să eșueze. Deci, faceți eșecul mai rapid, publicați rezultatele mai repede, astfel încât defectul să poată fi rezolvat mai repede.

Următorul lucru este din nou ceva ce trebuie să fi auzit înainte - Nu puteți și nu trebuie să încercați să automatizați totul.

Selectați cazuri de testare care, dacă sunt automatizate, vor beneficia considerabil pentru testatorii umani și are o bună rentabilitate a investiției. De altfel, există o regulă generală care spune că ar trebui să încercați să automatizați toate cazurile de testare Prioritatea 1 și, dacă este posibil, apoi Prioritatea 2.

Automatizarea nu este ușor de implementat și consumă mult timp, de aceea este recomandat să evitați automatizarea cazurilor cu prioritate scăzută cel puțin până când ați terminat cu cele mari. Selectarea a ceea ce trebuie automatizat și concentrarea asupra acestuia îmbunătățesc calitatea aplicației atunci când sunt utilizate și întreținute continuu.

Concluzie

Sper că până acum trebuie să fi înțeles de ce și cât de rău este necesară testarea manuală / umană pentru a livra produse de calitate și modul în care automatizarea o completează.

Acceptarea importanței testării manuale QA și cunoașterea de ce este specială este chiar primul pas către a fi un tester manual excelent.

În viitoarele noastre tutoriale de testare manuală, vom aborda o abordare generică pentru efectuarea testării manuale, modul în care va coexista cu automatizarea și multe alte aspecte importante.

Sunt sigur că veți dobândi cunoștințe imense despre testarea software-ului odată ce parcurgeți întreaga listă de tutoriale din această serie.

procesul de gestionare a defectelor în testarea software-ului

Ne-ar plăcea să aflăm de la dvs. Nu ezitați să vă exprimați gândurile / sugestiile în secțiunea de comentarii de mai jos.

Lectură recomandată

^