Cum apar problemele in testarea software personalizata

In 2009, la o conferinta dedicata testarii software, am vazut o prezentare denumita „Capcanele testarii software personalizate”. Mi-a placut foarte mult prezentarea dar, din punctul meu de vedere, au lipsit niste lucruri. Astfel ca la conferinta din anul urmator am sustinut si eu o prezentare cu numele “ Cum apar probleme in testarea software personalizata.”

Dar sa incepem cu inceputul.

In prezentarea pe care am vazut-o initial au fost evidentiate trei stereotipuri legate de comportamentul clientilor– lacomie, lene si o lipsa de diplomatie.

Lacomie

Echipa de testare software cere niste timp extra pentru a implementa testele. Insa clientul se opune, spunand ca: “Vreti de fapt doar sa consumati bugetul.”. Motivele pentru care echipa de testare a cerut acest lucru sunt ignorate — numarul crescut de functionalitati, intarzieri in procesul de software development, cerinte neclare si o densitate crescuta a defectelor.

Explicatia persoanei care a sustinut prezentarea este ca acel client nu are o intelegere asupra situatiei, a transparentei procesului si a certitudinii rezultatelor. Si sugereaza ca solutie sa ii explicam clientului care sunt riscurile si ca exista posibilitatea scaderii calitatii solutiei software. Alte optiuni mai sunt prioritizarea ariilor de testare si definirea criteriilor pentru finalizarea testelor si acceptarea lor.

Eu cred ca acel client are tot dreptul sa ridice obiectia de mai sus avand in vedere faptul ca in proiectele anterioare:

• Costurile legate de QA (nu doar de testare software) nu au fost estimate separat
• Un proces mai eficient de software development a dus la o scadere a costurilor legate de testarea software
• Costurile legate de testare (desi erau ridicate) nu au asigurat un nivel acceptabil al calitatii produsului software datorita unei culturi deficitare
• Licitatiile au fost organizate in asa fel incat unul din criteriile de selectie sa fie un cost total justificat al proiectului

Lene

Echipa de testare software nu planuieste sa scrie documentatie legata de testarea produsului. Clientul nu este de acord si spune ca sunt lenesi. Motivele echipei de testare sunt ignorate. Nu am scris test plans si test cases pentru ca nu aveam timp, ci pentru ca nu stabilisem asta. Nu vom scrie un raport legat de test deoarece activitatile nu au fost inregistrate, clientul a vazut asta si a fost de acord.

Explicatia persoanei care a sustinut prezentarea este ca acel client nu are o intelegere asupra situatiei, a transparentei procesului si a certitudinii rezultatelor. Si sugereaza sa ii explicam clientului ca un plan de testare si o strategie de testare ar trebui sa existe si sa fie aprobate de fiecare data. Ar trebui sa avem reprezentanti din partea clientului care sa fie responsabili de anumite parti ale procesului. Ca scenariile ar trebui scrise mereu si ca acel client ar trebui sa fie informat despre risc.

Eu cred ca acel client are tot dreptul sa ridice obiectia de mai sus avand in vedere faptul ca in proiectele anterioare:

• Absenta acelor actiuni / artefacte a dus la esecul proiectului
• Echipa de testare software a fost lenesa si nu a livrat ceea ce a promis si ceea ce a fost platit (planuri de testare spre exemplu)
• Nu a existat o evaluare obiectiva a calitatii proiectului si nici o posibilitate de a controla progresul acestuia
• Licitatiile au fost organizate in asa fel incat unul din criteriile de selectie era legat de gradul de urmarire a proceselor clientului

Lipsa de diplomatie

Echipa de testare software insista ca toti membrii ei sunt experti si ca sa isi pot face treaba bine. Clientul sustine ca nu sunt altceva decat „apasatori de butoane” si vrea sa vada care sunt certificarile lor. Motivele echipei de testare, anume ca testarea software pe un anumit domeniu necesita o anumita expertiza si ca desi nu avem certificari, avem experienta si abilitati, sunt ignorate.

Explicatia persoanei care a sustinut prezentarea este ca acel client nu are o intelegere a situatiei, a transparentei procesului si a certitudinii rezultatelor. Si ne sugereaza sa ii explicam clientului ca trebuie sa creeze test artifacts si sa aiba un portofoliu, si ca testarea manuala este foarte importanta.

Eu cred ca acel client are tot dreptul sa ridice obiectia de mai sus avand in vedere faptul ca in proiectele anterioare:

• In cazul celor care au esuat, echipele care au facut parte din proiect au sustinut si ele ca aveau expertiza si abilitatile necesare
• Experienta si expertiza declarata a echipei nu au fost confirmate de artefacte (rezultatele proiectelor incheiate cu succes)
• Au avut succes cand au lucrat cu o echipa foarte profesionista
• Licitatiile au fost organizate in asa fel incat unul din criteriile de selectie era legat de confirmarea expertizei echipei

Cauze

Pentru toate stereotipurile de mai sus, persoana care a prezentat a evidentiat faptul ca acel client nu are o intelegere asupra situatiei, a transparentei procesului si a certitudinii rezultatelor.

Dar sa incepem cu inceputul

• Intelegerea situatiei — de ce trebuie ca acel client sa o inteleaga?
• Transparenta procesului — de ce trebuie ca acel client sa stie?
• Certitudinea rezultatelor — clientul are motive sa aiba dubii

Pana si modul in care aceste stereotipuri sunt etichetate poate sa fie supus interpretarii:

Lacomie

• Clientul — economii rezonabile
• Echipa de proiect — profitabilitate

Lene

• Clientul — economii legate de efort
• Echipa de proiect — economii la nivel de costuri

Lipsa de diplomatie

• Clientul — nevoia unor garantii
• Echipa de proiect — de ce sa nu obtinem certificari care sa arate experienta si expertiza echipei

Concluzii

• Stereotipurile sunt mai degraba generate de echipele de proiect insesi
• Nu este important sa trecem sau sa depasim aceste stereotipuri ci sa le oprim din a se forma
• Diferite echipe de proiect beneficiaza reciproc unele de altele
• Eforturile ar trebui sa fie coordonate, in special in ceea ce priveste asteptarile clientului
• Nu ar trebui sa aducem vorba de client ci sa lucram la proiecte care sa indeplineasca asteptarile rezonabile ale clientului

Vrei sa incepi o cariera in testare software sau sa iti imbunatatesti abilitatile de testare software? Descopera cursurile noastre.

Alexandr Alexandrov
Software Testing Consultant

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