Ce este testarea software? 100+ tutoriale gratuite de testare manuală

Un ghid complet de testare software cu 100+ tutoriale de testare manuală cu definiția, tipurile, metodele și detaliile procesului de testare:

Ce este testarea software?

Testarea software este un proces de verificare și validare a funcționalității unei aplicații pentru a afla dacă aceasta satisface cerințele specificate. Este procesul de a găsi defecte într-o aplicație și de a verifica dacă aplicația funcționează în conformitate cu cerințele utilizatorului final.

Ce este testarea manuală?

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

Listă de tutoriale 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 învăța tehnicile de testare de bază și avansate.

Această serie de tutoriale vă va îmbogăți cunoștințele și, la rândul său, vă va îmbunătăți abilitățile de testare.

Practicați testarea manuală de la un capăt la altul Training gratuit pe un proiect live:

Tutorial #1: Bazele testării manuale a software-ului
Tutorial #2: Introducerea proiectului live
Tutorial #3: Scrierea scenariilor de testare
Tutorial #4: Scrierea unui document de plan de testare de la zero
Tutorial #5: Scrierea cazurilor de testare din documentul SRS
Tutorial #6: Scrierea cazurilor de testare din documentul SRS
Tutorial #6: Test Execution
Tutorial #7: Bug Tracking and Test Sign off
Tutorial #8: Software Testing Course

Software Testing Life-Cycle:

Tutorial #1: STLC

Web Testing:

Tutorial #1: Testarea aplicațiilor web
Tutorial #2: Testarea între browsere

Gestionarea cazurilor de testare:

Tutorial #1: Cazuri de testare
Tutorial #2: Testarea aplicațiilor web: Exemplu de model de caz de testare
Tutorial #3: Matrice de trasabilitate a cerințelor (RTM)
Tutorial #4: Acoperirea testului
Tutorial #5: Managementul datelor de testare

Managementul testelor:

Tutorial #1: Strategia de testare
Tutorial #2: Modelul planului de testare
Tutorial #3: Estimarea testelor
Tutorial #4: Instrumente de management al testelor
Tutorial #5: Tutorial HP ALM
Tutorial #6: Jira
Tutorial #7: TestLink Tutorial

Tehnici de testare:

Tutorial #1: Testarea cazurilor de utilizare
Tutorial #2: Testarea tranziției de stare
Tutorial #3: Analiza valorii limită
Tutorial #4: Partiționarea echivalenței
Tutorial #5: Metodologii de testare software
Tutorial #6: Metodologie agilă

Managementul defectelor:

Tutorial #1: Ciclul de viață al erorilor
Tutorial #2: Raportarea erorilor
Tutorial #3: Prioritatea defectelor
Tutorial #4: Tutorial Bugzilla

Testarea funcțională

Tutorial #1: Testarea unitară
Tutorial #2: Sanity și Smoke Testing
Tutorial #3: Testarea de regresie
Tutorial #4: Testarea sistemului
Tutorial #5: Testarea de acceptare
Tutorial #6: Testarea de integrare
Tutorial #7: Testarea de acceptare a utilizatorului UAT

Testarea nefuncțională:

Tutorial #1: Testarea nefuncțională
Tutorial #2: Testarea performanței
Tutorial #3: Testarea securității
Tutorial #4: Testarea securității aplicațiilor web
Tutorial #5: Testarea capacității de utilizare
Tutorial #6: Testarea compatibilității
Tutorial #7: Testarea instalării
Tutorial #8: Testarea documentației

Tipuri de testare a software-ului:

Tutorial #1: Tipuri de testare
Tutorial #2: Tipuri de testare: Testarea cutiei negre
Tutorial #3: Testarea bazelor de date
Tutorial #4: Testarea end to end
Tutorial #5: Testarea exploratorie
Tutorial #6: Testarea incrementală
Tutorial #7: Testarea accesibilității
Tutorial #8: Testarea negativă
Tutorial #9: Testarea backend
Tutorial #10: Testarea alfa
Tutorial #11: Testarea beta
Tutorial #12: Testarea Alfa vs Beta
Tutorial #13: Testarea Gamma
Tutorial #14: Testarea ERP
Tutorial #15: Testarea statică și dinamică
Tutorial #16: Testarea ad-hoc
Tutorial #17: Testarea localizării și internaționalizării
Tutorial #18: Testarea de automatizare
Tutorial #19: White box testing

Cariera de testare software:

Tutorial #1: Alegerea carierei de testare software
Tutorial #2: Cum să obții un job de testare QA – Ghid complet
Tutorial #3: Opțiuni de carieră pentru testeri
Tutorial #4: Non-IT to Software Testing Switch
Tutorial #5: Kick Start Your Manual Testing Career
Tutorial #6: Lessons Learned from 10 Years in Testing
Tutorial #7: Survive and Progress in Testing Field

Pregătirea interviului:

Tutorial #1: Pregătirea CV-ului QA
Tutorial #2: Întrebări pentru interviul de testare manuală
Tutorial #3: Întrebări pentru interviul de testare automată
Tutorial #4: Întrebări pentru interviul QA
Tutorial #5: Gestionați orice interviu de angajare
Tutorial #6: Obțineți un loc de muncă în domeniul testării ca proaspăt absolvent

Testarea diferitelor domenii de aplicații:

Tutorial #1: Testarea aplicației bancare
Tutorial #2: Testarea aplicației de îngrijire a sănătății
Tutorial #3: Testarea gateway-ului de plată
Tutorial #4: Testarea sistemului de punct de vânzare (POS)
Tutorial #5: Testarea site-ului de comerț electronic

Testarea certificării QA:

Tutorial #1: Software Testing Certification Guide
Tutorial #2: CSTE Certification Guide
Tutorial #3: CSQA Certification Guide
Tutorial #4: ISTQB Guide
Tutorial #5: ISTQB Advanced

Subiecte de testare manuală avansată:

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

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

Introducere la Testarea Manuală a Software-ului

Testarea Manuală este un proces în care comparați comportamentul unei bucăți de cod dezvoltat (software, modul, API, funcționalitate, etc.) cu comportamentul așteptat (Cerințe).

Și cum veți ști care este comportamentul așteptat?

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

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

Atunci, poate fi o cerință omisă (cerință incompletă) sau o cerință implicită (ceva care nu are nevoie de o mențiune separată, dar care ar trebui să fie îndeplinită), și trebuie să testați și pentru aceasta.

În plus, o cerință nu trebuie să fie neapărat una documentată. Puteți foarte bine să aveți cunoștințe despre funcționalitatea software-ului sau puteți chiar să ghiciți și apoi să testați pas cu pas. În general, o numim testare ad-hoc sau testare exploratorie.

Să aruncăm o privire în profunzime:

În primul rând, haideți să înțelegem faptul – Indiferent dacă comparați testarea unei aplicații software sau a altceva (să spunem un vehicul), conceptul rămâne același. Abordarea, instrumentele și prioritățile pot fi diferite, dar obiectivul de bază rămâne SIMILAR și este SIMPLU, adică compararea comportamentului real cu cel așteptat.

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

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

Citește aici =>Qualities of Highly Effective Testers

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

Pentru cei care nu au timp să parcurgă articolul, iată un rezumat:

„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, într-adevăr, trebuie să funcționeze și pentru dumneavoastră.”

Am vorbit despre prerechizitele de bază pentru a deveni tester de software. Acum haideți să înțelegem de ce testarea manuală are și va avea întotdeauna o existență independentă, cu sau fără creșterea testării automate.

De ce este necesară testarea manuală?

Știți care este cel mai bun lucru în a fi un tester, și anume un tester manual?

Este faptul că aici nu te poți baza doar pe skillset. Trebuie să ai/dezvolți și să-ți îmbunătățești procesul de gândire. Acesta este un lucru pe care nu îl poți cumpăra cu adevărat pentru câțiva dolari. Tu însuți trebuie să lucrezi la asta.

Trebuie să dezvolți obiceiul de a pune întrebări și va trebui să le pui în fiecare minut când testezi. De cele mai multe ori ar trebui să vă puneți aceste întrebări vouă înșivă decât altora.

Sper că ați parcurs articolul pe care vi l-am recomandat în secțiunea anterioară (adică calitățile testeriștilor foarte eficienți). Dacă da, atunci ar trebui să știți că testarea este considerată un proces de gândire și că succesul pe care îl veți avea ca tester depinde în totalitate de calitățile pe care le posedați ca persoană.

Să vedem acest flux simplu:

• Faceți ceva (efectuați acțiuni) în timp ce observați cu o anumită intenție (comparând cu ceea ce este așteptat). Acum, aici intră în scenă abilitățile tale de observare și disciplina de a realiza lucruri.
• Voila! Ce a fost asta? Ai observat ceva. Ai observat pentru că ai acordat o atenție perfectă detaliilor din fața ta. Nu-l lași să treacă pentru că ești curios. Nu era în planul tău ca ceva neașteptat/straniu să se întâmple, îl vei observa și îl vei cerceta mai departe. Dar acum o faci. Poți să-i dai drumul. Dar nu ar trebui să o lași baltă.
• Ești fericit, ai aflat cauza, pașii și scenariul. Acum veți comunica acest lucru în mod corespunzător și 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ă o comunicați în mod constructiv.
• Oops! Ce se întâmplă dacă o fac în acest fel? Ce se întâmplă dacă introduc un număr întreg corespunzător ca intrare, dar cu spații albe la început? Și dacă… și dacă… și dacă… și dacă… și dacă… Nu se termină ușor, nu ar trebui să se termine ușor. Vă veți imagina o mulțime de situații & scenarii și, într-adevăr, veți fi tentați să le executați și pe acestea.

Schema de mai jos reprezintă viața unui tester:

Recitiți încă o dată cele patru puncte menționate mai sus. Ați observat că am ținut-o foarte scurtă, dar am evidențiat totuși cea mai bogată parte a meseriei de tester manual? Și ați observat evidențierea cu bold peste câteva cuvinte? Acestea sunt exact cele mai importante calități de care are nevoie un tester manual.

Acum, chiar credeți că aceste acte pot fi complet înlocuite cu orice altceva? Iar 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âteva companii care fac acest lucru).

Când le automatizați, accentul este constant, adică automatizarea etapelor scrise.

Să ne întoarcem la partea formală, adică la executarea cazurilor de testare 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. Vă amintiți că sunteți curioși? Și vă veți imagina. Și nu veți putea rezista, veți face într-adevăr ceea ce v-ați imaginat.

Imaginea de mai jos ilustrează modul în care se simplifică scrierea Cazurilor de Test:

Completez un formular și am terminat de completat primul câmp. Mi-e prea lene să mă duc după mouse pentru a muta focusul pe următorul câmp. Apăs tasta „tab”. Am terminat de completat și următorul și ultimul câmp, acum trebuie să dau click pe butonul „Submit”, focusul este încă pe ultimul câmp.

Oops, am apăsat din greșeală tasta ‘Enter’. Permiteți-mi să verific ce s-a întâmplat. SAU există un buton de trimitere, voi da dublu clic pe el. Nu sunt mulțumit. Dau click de mai multe ori, prea repede.

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

Nu veți reuși să scrieți toate cazurile de test care să acopere 100% aplicația dumneavoastră testată. Acest lucru trebuie să se întâmple într-un mod exploratoriu.

Vă veți continua să adăugați noi cazuri de testare pe măsură ce testați aplicația. Acestea vor fi cazuri de testare pentru erorile pe care le-ați întâlnit și pentru care anterior nu existau cazuri de testare scrise. Sau, în timp ce testați, ceva v-a declanșat procesul de gândire și ați mai obținut câteva cazuri de testare pe care veți dori să le adăugați la 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. Un software cu zero bug-uri este un Mit. Puteți doar să vă propuneți să-l apropiați de Zero, dar acest lucru pur și simplu nu se poate întâmpla fără o minte umană care să vizeze în mod continuu același lucru, similar, dar fără a se limita la exemplul de proces pe care l-am văzut mai sus.

Cel puțin până în prezent, nu există un 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ă un astfel de lucru se va întâmpla, a cui minte, gânduri și ochi va imita? A ta sau a mea? Nici noi, oamenii, nu suntem la fel de drepți. Suntem cu toții diferiți. Atunci?

Nevoia de testare manuală atunci când există automatizare:

Testarea automatizată are partea ei de glorie în aceste zile și va avea și mai multă glorie în anii următori, dar, pur și simplu, nu poate înlocui testarea manuală QA (a se citi testarea umană/exploratorie).

Probabil că ați mai auzit înainte – „Nu automatizați testarea, ci automatizați verificarea”. Această propoziție spune multe despre locul în care se află testarea manuală QA cu testarea de automatizare în jur. Multe nume mari din întreaga lume au scris și au vorbit despre acest subiect, așa că nu voi insista prea mult asupra acestui aspect.

Automatizarea nu poate înlocui testarea umană deoarece:

• Este nevoie de judecăți în timp de execuție despre tot ceea ce se întâmplă în fața ochilor tăi (în timp ce testezi) și în câteva cazuri și în spatele scenei.
• Este nevoie de o observație clară și constantă.
• Este nevoie de o interogare.
• Exigă o investigație.
• Exigă un raționament.
• Exigă acțiuni neplanificate, după cum este necesar în timpul testării.

Testările pot fi înlocuite de un instrument/mașină care va fi capabil să absoarbă detaliile, să le proceseze, să comande acțiuni și să le execute ca o minte umană și ca un om, și toate acestea în timpul execuției și în toate contextele posibile. Din nou, acest instrument trebuie să fie ca toți oamenii posibili.

Deci, pe scurt, testarea umană nu poate fi înlocuită. Poate că vreun film SF de la Hollywood, în câțiva ani, se va apropia de asta, dar în viața reală, nu văd așa ceva pentru câteva sute de ani, din câte îmi pot imagina. Nu o voi anula pentru totdeauna, deoarece cred în posibilități nesfârșite.

În altă ordine de idei, chiar dacă se va întâmpla cu adevărat după câteva sute de ani, imaginea pe care mi-o pot imagina este cu siguranță cea a unei lumi înfricoșătoare. Era Transformers. 🙂

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

Cum completează automatizarea testarea manuală?

Am mai spus înainte și o 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 sta degeaba. Trebuie să găsim modalități de a o face.

De cele mai multe ori, desfășurarea a tot mai multă forță de muncă nu ajută pe termen lung la această sarcină. Prin urmare, cel care testează (Test Lead/Arhitect/Manager) trebuie să decidă cu prudență ce trebuie să automatizeze și ce ar trebui în continuare să facă manual.

Devine extrem de important să fie scrise teste/verificări foarte precise, astfel încât acestea să poată fi automatizate fără nicio abatere de la așteptările inițiale și să poată fi utilizate în timpul regresiei produsului ca parte a „testării continue”.

Nota: Cuvântul continuu din termenul ‘Continuous Testing’ este supus unor apeluri condiționate și logice similare cu ceilalți termeni pe care i-am folosit mai sus cu același prefix. Continuu în acest context înseamnă din ce în ce mai des, mai repede decât ieri. În timp ce, în ceea ce privește sensul, poate foarte bine să însemne la fiecare secundă sau nano-secundă.

Fără a avea o potrivire perfectă între testeri umani și verificări automate (teste cu pași preciși, rezultat așteptat și criterii de ieșire ale testului respectiv documentate), realizarea testării continue este foarte dificilă și acest lucru, la rândul său, va face ca integrarea continuă, livrarea continuă și implementarea continuă să fie mai dificile.

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

Exemplu:

Să spunem că există un defect de blocaj în care, nu pot să mă loghez pe Facebook.

Funcționalitatea de logare trebuie să fie atunci prima verificare automatizată și suita dvs. de automatizare nu ar trebui să ruleze următoarea verificare în care logarea este o condiție prealabilă, cum ar fi postarea unui status. Știți foarte bine că este obligatoriu să eșueze. Deci, faceți-o să eșueze mai repede, 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 ar trebui să încercați să automatizați totul.

Selectați cazurile de testare care, dacă sunt automatizate, vor aduce beneficii considerabile pentru testerii umani și au un bun randament al investiției. De altfel, există o regulă generală care spune că ar trebui să încercați să automatizați toate cazurile de testare de prioritate 1 și, dacă este posibil, apoi cele de prioritate 2.

Automatizarea nu este ușor de implementat și necesită mult timp, așa că se recomandă să evitați automatizarea cazurilor de prioritate scăzută cel puțin până în momentul în care ați terminat cu cele de prioritate ridicată. Selectarea a ceea ce trebuie să automatizați și concentrarea pe aceasta îmbunătățește calitatea aplicației atunci când este utilizată și menținută în mod continuu.

Concluzie

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

Acceptarea importanței testării manuale de asigurare a calității și cunoașterea motivelor pentru care este specială, este primul pas pentru a fi un tester manual excelent.

În următoarele noastre tutoriale de testare manuală, vom acoperi o abordare generică pentru a face Testarea Manuală, modul în care aceasta va coexista cu Automatizarea și multe alte aspecte importante, de asemenea.

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