Greseli clasice in testarea software

Once upon a time, a very long time ago now, about last Friday, Winnie-the-Pooh lived in a forest all by himself under the name of Sanders. “What does ‘under the name’ mean?” asked Christopher Robin. “It means he had the name over the door in gold letters, and lived under it.”

A. Miln. Winnie-The-Pooh and All, All, All

Undeva prin 1997 Brian Marick a scris un articol intitulat “Classic Testing Mistakes.”. In acest articol a impartit greselile facute in testarea software in mai multe categorii. Categorii pe care le vom discuta in acest articol. In 2009, am reanalizat toate acele greseli prin prisma a ce se intampla in industrie in acel moment, si lucrurile pareau incurajatoare. Acum, 12 ani mai tarziu, am decis sa reiau aceasta analiza.

Dar mai intai sa ne uitam pe lista

Rolul testarii

• Greseli identificate de Brian Marick:
• Echipa de testare este responsabila de asigurarea calitatii
• Scopul testarii este de a gasi bug-uri
• Software testerii nu gasesc bug-urile importante
• Problemele de utilizare nu sunt considerate ca fiind defecte valide
• Nu exista orientare pe estimarea calitatii (si calitatea acelei estimari)
• Raportare defectelor fara a le pune in context
• Inceperea testarii prea tarziu

Planificarea efortului de testare

• Eforturile de testare software inclina catre testarea functionala
• Testarea configuratiei este insuficient evidentiata
• Stress si load testing sunt lasate pe ultima suta de metri
• Documentatia nu este testata
• Procedurile de instalare nu sunt testate
• Se pune prea mult pret pe beta testing
• Finalizarea unei sarcini legate de testare inainte de a trece mai departe catre urmatoarea
• Esecul legat de identificarea corecta a ariilor de risc
• Respectarea cu incapatanare a planului de testare software

Probleme legate de echipa

• Considerarea testarii software ca un rol de tranzitie pentru noii programatori
• Recrutarea testerilor din randul programatorilor ineficienti
• Software testeri care nu sunt experti in domeniul aplicatiei
• Insistenta ca software testerii sa stie si programare
• Construirea unei echipe de testare care nu este diversa
• O separare fizica intre programatori si software testeri
• Programatorii nu isi pot testa propriul cod
• Programatorii nu sunt nici pregatiti si nici motivati sa testeze

Software tester-ul la locul de munca

• Se acorda mai multa atentie rularii de teste in comparatie cu designul de teste
• Artefacte care nu sunt revizuite legate de designul testelor
• Rafinarea excesiva / insuficienta a scenariilor de testare
• Ciudateniile „irelevante” nu sunt observate sau explorate
• Se verifica daca produsul software face ce trebuie sa faca, dar nu si daca nu face ceea ce nu trebuie sa faca
• Test suites sunt intelese doar de cei care le-au facut
• Testarea este facuta doar prin interfata pe care utilizatorul o vede
• Raportarea slaba a defectelor
• Adaugarea doar de regression tests nu este indeajuns pentru a gasi un defect nou
• Nu se iau notite pentru urmatoarele eforturi de testare

Testare Automata

• Incercarea de a automatiza toate testele
• Automatizarea tuturor testelor manuale
• Folosirea instrumentelor de captura / replay GUI
• Asteptarea ca testele de regresie sa gaseasca o proportie cat mai mare de defecte noi

Code Coverage

• Testarea software legata de code coverage are acelasi scop ca testarea legata de cerinte
• Eliminarea testelor din cadrul suitei de regression tests deoarece nu adauga la code coverage
• Folosirea code coverage ca obiectiv de performanta pentru testeri
• Abandonarea coverage in intregime

Ce s-a imbunatatit in 24 de ani?

Din pacate aproape nimic.

Multi oameni inca considera ca:

• Cei care fac testare software sunt responsabili de calitate, desi scopul testarii este de a oferi o evaluare obiectiva a produsului dezvoltat si livrat
• Testele ar trebui sa fie rulate pe baza cerintelor, desi sunt cerinte implicite si au loc erori in aceste cerinte
• Severitatea unui defect poate sa fie determinata prin „acord comun”, dar nu prin intermediul unei clasificari general acceptate
• Testing metrics, static testing, unit testing — putem sa ne descurcam fara
• Daca fiecare functie poate sa fie testata separat, aceste vor functiona bine impreuna
• Nu este nevoie de test documentation; principalul lucru este sa testezi sistemul
• Nu exista riscuri in testarea software
• Oricine poate sa devina un software tester — nu trebuie sa ai anumite abilitati
• Software testerii nu sunt recrutati din cadrul technical writers sau personalului care se ocupa de suport, desi pot sa devina software testeri foarte buni deoarece cunosc foarte bine produsul si nevoile utilizatorilor
• Test suites sunt excesive; cel putin sunt folosite ca check lists
• Atunci cand toate test suites nu mai gasesc bug-uri, acest lucru inseamna ca testarea este completa
• Test suites ar trebui sa fie intelese doar de owneri
• Automatizarea tuturor testelor manuale este foarte cool
• Automatizarea fara test suites este super cool
• Daca automatizezi regressive testing, poti sa gasesti mai multe defecte

Vrei sa descoperi de ce nu este asa?

Participa la cursurile noastre de testare software.

Alexandr Alexandrov
Software Testing Consultant

Originally published at https://www.luxoft-training.ro.