Fundamentaalne probleem testimisel

Sissejuhatus

Tere päevast, habrovtšanned. Viimasel ajal lahendasin ma siin QA juhi ametikoha testülesannet ühes fintech ettevõttes. Esimene ülesanne, koostada testplaan koos täieliku kontrollnimekirjaga ja testjuhtumite näidetega elektrilise veekeetja kontrollimiseks, lahendati lihtsalt:

• GOST 7400-81. Elektrilised veekeetjad ja elektrilised imur-staadionid koduseks kasutamiseks. Tehnilised tingimused (muudatustega nr 1-8)
• GOST IEC 60335-1-2015 Kodused ja sarnased elektriseadmed. Ohutus. Osa 1. Üldnõuded
  Parimat testplaani koos täieliku kontrollnimekirjaga on keeruline välja mõelda.

Kuid teine osa osutus küsimuseks: "Kas on olemas mingeid probleeme, mis takistavad kõigi testijate tõhusamat töötamist?".

Esimene mõte, mis pähe tuli: loetleda kõik enam-vähem märgatavad probleemid, millega olen testimise käigus kokku puutunud, ja kõrvaldada väikesed probleemid, globaalsemad keskenduda. Kuid mõistsin kiiresti, et induktiivne meetod vastab küsimusele, mis ei puuduta "kõiki", vaid parimal juhul "enamiku" testijate olukorda. Seetõttu otsustasin läheneda teisele poole, deduktiivsele, ja siin on, mis välja tuli.

Defineeringud

Esimene asi, mille tavaliselt uue ülesande lahendamisel teen, on proovida mõista, millest see üldse räägib, ja selleks pean arvestama sõnade tähendust, millega see esitatud on. Olulised sõnad, millega tuleb tutvuda, on järgmised:

• probleem
• testija
• testija töö
• testija töö tõhusus

Vaatame, mida ütleb vikipeedia ja mõistus:
Probleem (vana-kreeka πρόβλημα) laiemas mõttes - keeruline teoreetiline või praktiline küsimus, mis nõuab uurimist, lahendamist; teaduses - vastuoluline olukord, mis esitab vastandlikke seisukohti mingi nähtuse, objekti, protsessi selgitamisel ja vajab selle lahendamiseks sobivat teooriat; elus on probleem formuleeritud arusaadavas inimkeeles kui 'tean, mis on, ei tea, kuidas', s.t. on teada, mida on vaja saavutada, kuid ei teata, kuidas seda teha. Tuleneb hilisloomulikust lat. problēma, kreeka πρόβλημα 'ette visatud, esitatud ees'; dari προβάλλω 'ette viskama, enda ette seadma; süüdistama'.

Mõtet ei ole palju, põhimõtteliselt on “probleem” = “mis tahes, millega tuleb tegeleda”.
Testija — spetsialist (me ei jaga tüüpe, kuna meid huvitavad kõik testerid), kes osaleb komponendi või süsteemi testimises, mille tegevuse tulemuseks on:
Testija töö — testimisega seotud tegevuste kogum.
Tõhusus (ladina k. effectivus) — suhe saavutatud tulemuse ja kasutatud ressursside vahel (ISO 9000:2015).
Tulemus — tulemusi, mis tulenevad tegevuste (protsesside) ahelast (kokkuvõte) või sündmustest, väljendatuna kvalitatiivselt või kvantitatiivselt. Võimalikud tulemused hõlmavad eelist, ebamugavust, kasu, kadu, väärtust ja võitu.
Nagu ka „probleemiga”, on mõte vähe: midagi, mis on saadud töö tulemusena.
Ressurss — kvantitatiivselt mõõdetav võimekus täita mingit tegevust inimese või inimeste poolt; tingimused, mis võimaldavad teatud muutuste kaudu saavutada soovitud tulemust. Testija on inimene ja vastavalt elutähtsate ressursside teooriale on igal inimesel neli majanduslikku aktiivset vara:
rahalised vahendid (tulu) — taastuv ressurss;
energia (elujõud) — osaliselt taastuv ressurss;
aeg — piiratud ja põhimõtteliselt mitteuuendatav ressurss;
teadmised (info) — uuendatav ressurss, see on osa inimkapitalist, mis võib kasvada ja laguneda;[1].

Soovin märkida, et efektiivsuse määratlemine meie puhul ei ole täiesti korrektne, kuna mida rohkem teadmisi me kasutame, seda madalam on efektiivsus. Seetõttu määratleksin efektiivsuse kui "saavutatud tulemuse ja kulutatud ressursside suhe". Siis on kõik korrektne: teadmisi ei kulutata töö käigus, kuid need vähendavad ainukese põhimõtteliselt mitteuuendatava ressursi — testija aega — kulu.

Lahendus

Nii et otsime globaalsetele probleemidele testijate seas, mis halvendavad nende töö efektiivsust.
Oluline ressurss, mis kulutatakse testija tööle, on tema aeg (teised ressursid on kas või mingil viisil sellele viidud), ja et saaksime rääkida efektiivsuse õigesti arvutamisest, tuleb ka tulemus viia aja juurde.
Selleks vaatame süsteemi, mille elujõulisust tagab testija oma tööga. Selline süsteem on projekt, mille meeskonnas on testija. Projekti elutsüklit võib umbkaudu kujutada järgmise algoritmina:

1. Töö nõudmistega
2. Tehnilise ülesande koostamine
3. Arendus
4. Testimine
5. Tootmisse väljalaskmine
6. Tugi (mine p.1 juurde)

Samuti saab kogu projekti rekursiivselt jagada alaprojektideks (funktsioonideks), millel on sama elutsükkel.
Projektist lähtuvalt on selle rakendamise efektiivsus seda suurem, mida vähem aega sellele kulutatakse.
Nii jõuame projektide kontekstis maksimaalse võimaliku efektiivsuse määratlemiseni testija jaoks — see on selline projekti seisund, kus testimiseks kulutatud aeg on null. Üheks peamiseks probleemiks kõigile testijatele on see, et seda aega pole võimalik saavutada.

Kuidas sellega olla?

Järeldused on täiesti ilmsed ja paljusid neist on pikka aega kasutatud:

1. Arendus ja testimine peaksid algama ja lõppema praktiliselt samaaegselt (sellega tegeleb tavaliselt osakond QA). Ideaalne variant on, kui kogu arendatav funktsionaalsus on valmimise hetkeks juba kaetud automaattestidega, mis on korraldatud regressioonitestimise (ja kui võimalik, siis ka enne commiti) abil mõne CI.
2. Mida rohkem on projektis funktsioone (mida keerulisem see on), seda rohkem aega tuleb kulutada selle kontrollimiseks, et uus funktsionaalsus ei rikuks vana. Seetõttu, mida keerulisem projekt — seda rohkem on vaja automatiseerimist regressioonitestimiseks.
3. Iga kord, kui jätame vea tootmisse ja kasutaja selle leiab, peame kulutama täiendavat aega, et minna läbi projekti elutsüklist, alustades punktist 1 (Töö nõudmistega, antud juhul kasutajatega). Kuna vead, mida me jätame, on üldjuhul teadmata, jääb meile ainult üks võimalus optimeerimiseks — iga kasutajate leitud viga tuleb kaasata regressioonitestimisse, et olla kindel, et see enam ei teki.

Allikas: habr.com