Cele 7 principii ale testarii software – prima parte
Cele 7 principii ale testarii software – prima parte
Acesta serie de articole se bazeaza pe cartea Foundations of Software Testing: ISTQB Certification de Dorothy Graham, Erik van Veenendaal, Isabel Evans & Rex Black. Cele 7 principii ale testarii apar in multe discutii dar rareori se vorbeste despre ele mai elaborat asa ca vom face asta in aceasta serie de articole.
3 Oct 2016
9337
Other articles
Object-relational Mapping folosind JPA, Hibernate si Spring Data JPA. Persistence cu JPA
Cum sa interogam Kafka Streaming Data?
Procrastinarea. Care sunt avantajele ei?
Object-relational Mapping folosind JPA, Hibernate si Spring Data JPA
Procrastinarea
Cerinte. De ce avem nevoie de ele?
Dezvolta-ti abilitatile cu training-urile noastre
Programarea reactiva Java. Implementari
Testarea software. Intrebari tipice si raspunsuri. Continuare
Testarea software. Intrebari tipice si raspunsuri
Acesta serie de articole se bazeaza pe cartea Foundations of Software Testing: ISTQB Certification de Dorothy Graham, Erik van Veenendaal, Isabel Evans & Rex Black. Cele 7 principii ale testarii apar in multe discutii dar rareori sunt discutate pe indelete asa ca profitam de ocazie si le vom analiza in aceasta serie.
Principiul 1. Testarea arata prezenta defectelor
Testarea poate sa arate prezenta defectelor dar nu poate sa dovedeasca ca nu sunt defecte. Este foarte dificil sa arati ca ceva nu exista – oricat de multe lebede albe am vedea nu putem spune cu certitudine “Toate lebedele sunt albe!”. Insa, in momentul in care vedem o lebada neagra putem spune “Nu toate lebedele sunt albe.”.
La fel, oricat de multe teste avem in care nu gasim bug-uri, nu putem spune ca nu exista alte teste care ar putea sa descopere un bug. In momentul in care gasim cel putin un bug, putem spune “Acest cod are bug-uri.”.
Dar asta nu inseamna ca testarea este lipsita de sens si nu poate creste gradul de certitudine cu privire la calitatea codului. Testarea reduce probabilitatea defectelor nedescoperite care pot fi gasite intr-un soft dar chiar si atunci cand nu gasim defecte acest lucru nu este o dovada a corectitudinii codului.
Principiul 2. Testarea exhaustiva nu este posibila
Acest principiu are legatura cu intrebarea: “Cat de multa testare ar trebui sa facem?”
Ce raspunsuri putem avea la aceasta intrebare? Putem sa alegem: testam tot, nu testam nimic sau testam o parte din software. Un raspuns ideal ar fi sa spunem ca testam totul. Dar trebuie sa ne gandim daca ar trebui sau daca putem sa testam totul.
De cat de multe teste ar fi nevoie ca sa testam complet un camp numeric pentru o singura cifra? Depinde ce intelegem prin testare completa. Exista 10 valori numerice valide dar pe langa aceste valori trebuie sa ne asiguram ca toate valorile care nu sunt valide sunt respinse. Am avea 26 de caractere cu litera mica, 26 de caractere cu litera mare, cel putin 6 semne de punctuatie precum si situatia in care casuta este lasata goala. Rezulta cel putin 68 de teste, fara a mentiona caractere speciale.
Aceasta problema devine si mai grava pe masura ce ne uitam la exemple mai realiste. In practica, sistemele au mai mult de un camp si au dimensiuni variate. Aceste teste sunt in plus pe langa cele necesare pentru a vedea cum ruleaza sistemul in diferite medii. Daca luam un exemplu unde avem 15 campuri, fiecare cu 5 valori posibile, atunci pentru a testa toate combinatiile valide am avea nevoie de 30 517 578 125 (515) teste! Este putin probabil ca deadline-urile vreunui proiect sa permita numarul acesta de teste.
Folosind partitii de echivalenta putem reduce numarul textelor, deoarece testarea campului care are o singura valoare numerica cu valorile 2, 3 si 4 nu ne-ar oferi mai multe informatii fata de testarea cu -3 spre exemplu.
In viata reala, presiunile pe proiect la nivel de timp si buget precum si presiunea de a livra solutii tehnice care sa rezolve nevoile clientului nu permit o testare completa. Clientii si project managerii vor vrea ca testarea sa dureze o perioada de timp care sa ofere un return on investment. Acest lucru include prevenirea esecurilor dupa lansare care sunt mereu costisitoare. Testarea completa – chiar daca clientii si project managerii cer acest lucru – nu este ceva ce isi pot permite.
In loc sa incercam sa testam tot, trebuie sa avem o strategie care ofera nivelul necesar de testare pentru proiect, clienti (si alte parti implicate) si software. Atunci cand decidem nivelul de testare trebuie sa luam in considerare nivelul de risc, inclusiv riscuri tehnice si de business legate de produs sau proiect precum timp si buget. Evaluarea riscului si managementul acestuia sunt unele dintre cele mai importante activitati in orice proiect si acestea ne permit sa variem efortul de testare pe baza riscului.
Mai mult decat atat, testarea ar trebui sa ofere informatii suficiente catre partile implicate pentru a lua decizii informate despre lansarea produselor sau predarea catre clienti.
In cea de-a doua parte a articolului vom analiza urmatoarele doua principii.
Victoria Slinyavchuk
Consultant on Software Testing
Principiul 1. Testarea arata prezenta defectelor
Testarea poate sa arate prezenta defectelor dar nu poate sa dovedeasca ca nu sunt defecte. Este foarte dificil sa arati ca ceva nu exista – oricat de multe lebede albe am vedea nu putem spune cu certitudine “Toate lebedele sunt albe!”. Insa, in momentul in care vedem o lebada neagra putem spune “Nu toate lebedele sunt albe.”.
La fel, oricat de multe teste avem in care nu gasim bug-uri, nu putem spune ca nu exista alte teste care ar putea sa descopere un bug. In momentul in care gasim cel putin un bug, putem spune “Acest cod are bug-uri.”.
Dar asta nu inseamna ca testarea este lipsita de sens si nu poate creste gradul de certitudine cu privire la calitatea codului. Testarea reduce probabilitatea defectelor nedescoperite care pot fi gasite intr-un soft dar chiar si atunci cand nu gasim defecte acest lucru nu este o dovada a corectitudinii codului.
Principiul 2. Testarea exhaustiva nu este posibila
Acest principiu are legatura cu intrebarea: “Cat de multa testare ar trebui sa facem?”
Ce raspunsuri putem avea la aceasta intrebare? Putem sa alegem: testam tot, nu testam nimic sau testam o parte din software. Un raspuns ideal ar fi sa spunem ca testam totul. Dar trebuie sa ne gandim daca ar trebui sau daca putem sa testam totul.
De cat de multe teste ar fi nevoie ca sa testam complet un camp numeric pentru o singura cifra? Depinde ce intelegem prin testare completa. Exista 10 valori numerice valide dar pe langa aceste valori trebuie sa ne asiguram ca toate valorile care nu sunt valide sunt respinse. Am avea 26 de caractere cu litera mica, 26 de caractere cu litera mare, cel putin 6 semne de punctuatie precum si situatia in care casuta este lasata goala. Rezulta cel putin 68 de teste, fara a mentiona caractere speciale. Aceasta problema devine si mai grava pe masura ce ne uitam la exemple mai realiste. In practica, sistemele au mai mult de un camp si au dimensiuni variate. Aceste teste sunt in plus pe langa cele necesare pentru a vedea cum ruleaza sistemul in diferite medii. Daca luam un exemplu unde avem 15 campuri, fiecare cu 5 valori posibile, atunci pentru a testa toate combinatiile valide am avea nevoie de 30 517 578 125 (515) teste! Este putin probabil ca deadline-urile vreunui proiect sa permita numarul acesta de teste.
Folosind partitii de echivalenta putem reduce numarul textelor, deoarece testarea campului care are o singura valoare numerica cu valorile 2, 3 si 4 nu ne-ar oferi mai multe informatii fata de testarea cu -3 spre exemplu.
In viata reala, presiunile pe proiect la nivel de timp si buget precum si presiunea de a livra solutii tehnice care sa rezolve nevoile clientului nu permit o testare completa. Clientii si project managerii vor vrea ca testarea sa dureze o perioada de timp care sa ofere un return on investment. Acest lucru include prevenirea esecurilor dupa lansare care sunt mereu costisitoare. Testarea completa – chiar daca clientii si project managerii cer acest lucru – nu este ceva ce isi pot permite.
In loc sa incercam sa testam tot, trebuie sa avem o strategie care ofera nivelul necesar de testare pentru proiect, clienti (si alte parti implicate) si software. Atunci cand decidem nivelul de testare trebuie sa luam in considerare nivelul de risc, inclusiv riscuri tehnice si de business legate de produs sau proiect precum timp si buget. Evaluarea riscului si managementul acestuia sunt unele dintre cele mai importante activitati in orice proiect si acestea ne permit sa variem efortul de testare pe baza riscului.
Mai mult decat atat, testarea ar trebui sa ofere informatii suficiente catre partile implicate pentru a lua decizii informate despre lansarea produselor sau predarea catre clienti.
In cea de-a doua parte a articolului vom analiza urmatoarele doua principii.
Vrei sa incepi o cariera in testare software? Descopera cursurile noastre.
Victoria Slinyavchuk
Consultant on Software Testing