Põhiprobleem testimises

Sissejuhatus

Tere, Habro inimesed. Hiljuti lahendasin QA Lead positsiooni testülesande ühes finantstehnoloogia ettevõttes. Esimene ülesanne, koostada testiplaan koos täieliku kontrollnimekirja ja näidistestjuhtumitega elektrilise veekeetja kontrollimiseks, lahendati triviaalsetel alustel:

• GOST 7400-81. Elektrilised veekeetjad ja elektrilised aurutajad koduseks kasutamiseks. Tehnilised tingimused (muudatustega N 1-8)
• GOST IEC 60335-1-2015 Kodused ja sarnased elektrilised seadmed. Ohutus. Osa 1. Üldnõuded
  Parimat testiplaani koos täieliku kontrollnimekirjaga on raske välja mõelda.

Kuid teine osa osutus küsimuseks: "Kas on olemas mingeid probleeme, mis on ühised kõigile testijatele ja takistavad töötamast suurema efektiivsusega?"

Esimene mõte, mis mulle pähe tuli: loetlege kõik rohkem-või-vähem märgatavad probleemid, millega olen testimise käigus kokku puutunud, kõrvaldage väiksemad mured, ülejäänud üldistada. Kuid kiiresti sain aru, et induktiivne meetod vastab küsimusele, mis ei kehti mitte "kõigile", vaid parimal juhul vaid "enamiku" testijate kohta. Seetõttu otsustasin läheneda teiselt poolt, deduktiivselt, ja see, mis välja tuli.

Mõisted

Esimene asi, mida ma tavaliselt teen, lahendades uut ülesannet, on see, et püüan aru saada, millest see üldse räägib, ja selleks on vaja mõista sõnade tähendust, millega see esitatakse. Peamised sõnad, millega on vaja tutvuda, on järgmised:

• probleem
• testija
• testija töö
• testija töö efektiivsus

Vaatame Wikipedia ja terve mõistuse poole:
Probleem (vanakreeka πρόβλημα) laias tähenduses - keeruline teoreetiline või praktiline küsimus, mis vajab uurimist, lahendamist; teaduses - vastuoluolukord, mis esitab end vastandlike seisukohtadena mingi nähtuse, objekti, protsessi seletamisel ja vajab selle lahendamiseks adekvaatset teooriat; elus on probleem sõnastatud inimestele arusaadaval kujul "tean, et ei tea kuidas", st on teada, mida on vaja saavutada, kuid teadmata, kuidas seda teha. Tuli hilisest ladina keelest problēma, kreekakeelsest πρόβλημα "ette visatud, ette seatud"; προβάλλω "ette viskama, endale esitama; süüdistama."

Tähenduse poolest mitte palju, põhimõtteliselt "probleem" = "mis tahes asi, millega tuleb tegeleda."
Testija — spetsialist (me ei hakka liikideks jagama, kuna meid huvitavad kõik testijad), kes osaleb komponendi või süsteemi testimises, mille tegevuse tulemus on:
Testija töö — testimisele seotud tegevuste kompleks.
Tõhusus (ladina keeles effectivus) — suhe saavutatud tulemuse ja kasutatud ressursside vahel (ISO 9000:2015).
Tulemus — tegevuste (tulemuste) järjepidevuse tagajärg (lõpptulemus) või sündmuste kvaliteetne või kvantitatiivne väljendus. Võimalikud tulemused hõlmavad eeliseid, ebamugavusi, kasu, kaotust, väärtust ja võitu.
Nagu "probleemi" puhul, ei ole tähendus väga palju muud: midagi, mis tuli välja töö tulemusena.
Allikas — kvantitatiivselt mõõdetav inimese või inimeste tegevuse täitmise võimalus; tingimused, mis võimaldavad teatud ümberkujundamiste abil soovitud tulemust saavutada. Testija on inimene, ja vastavalt eluliste ressursside teooriale, on igal inimesel neli majanduslikku aktiviti:
raha (tulu) — ressurss, mis on taastuv;
energia (elujõud) — ressurss, mis on osaliselt taastuv;
aeg — ressurss, mis on fikseeritud ja põhimõtteliselt mitte-taastuv;
teadmised (informatsioon) — ressurss, mis on taastuv, see on osa inimkapitalist, mis võib kasvada ja ka kaduda.[1].

Tahaksin märkida, et tõhususe määratlemine meie puhul ei ole täiesti korrektne, kuna mida rohkem teadmisi me kasutame, seda madalam on tõhusus. Seetõttu ma määratleks seal tõhususe ümber kui „suhe saavutatud tulemuse ja kulutatud ressursside vahel“. Siis on kõik korrektne: teadmisi töö käigus ei kulutata, kuid need vähendavad ainukese põhimõtteliselt mitte-taastuva ressursi testija - tema aega - kulutusi.

Lahendus

Nii et otsime testeijaid puudutavaid globaalseid probleeme, mis halvendavad nende töö tõhusust.
Olulisem ressurss, mis testija tööle kulub, on tema aeg (teised ressursid on mingil moel temaga seostatavad), ja et me saaksime rääkida korrektsetest tõhususe arvutustest, tuleb ka tulemus tuua ajaga seotuks.
Selleks võtame arvesse süsteemi, mille elujõulisust tagab testija oma tööga. Selline süsteem on projekt, mille meeskonnas on testija. Projekti elutsükli võib umbkaudu kujutada järgmisena:

1. Nõuetega töötamine
2. Tehnilise ülesande vormistamine
3. Arendus
4. Testimine
5. Tootmisseviimine
6. Tugi (mine p.1 juurde)

Samas saab kogu projekti rekursiivselt jagada alaprojektideks (näiteks funktsioonideks), millel on sama elutsükkel.
Projekti seisukohalt on selle rakendamise efektiivsus seda suurem, mida vähem aega sellele kulutatakse.
Nii jõuame projekti seisukohalt maksimaalse testija efektiivsuse määratlemiseni — see on projektis selline seisund, kus testimisele kuluv aeg on null. Kuid kõigi testijate ühine probleem on see, et sellele ajale ei ole võimalik jõuda.

Kuidas sellega toime tulla?

Kokkuvõtted on täiesti ilmseid ja neid on juba ammu kasutatud:

1. Arendamine ja testimine peaksid algama ja lõppema peaaegu samaaegselt (sellega tegeleb tavaliselt osakond QA). Ideaalne variant on see, kui kogu arendatav funktsionaalsus on valmisoleku hetkeks juba kaetud automaatsete testidega, mida on korraldatud regressioonitestimiseks (ja kui võimalik, ka eelcommit-testimiseks) mingi CI.
2. Mida rohkem on projektis funktsioone (mida keerukam ta on), seda rohkem aega tuleb kulutada kontrollimiseks, et uus funktsionaalsus ei rikuks vana. Sellega seoses, mida keerukam projekt on, seda enam on vaja automatiseerimist regressioonitestimises.
3. Iga kord, kui lastame vea tootmisse ja kasutaja selle leiab, peame kulutama lisatähtaega projekti elutsükli läbimiseks alates p.1 (Nõuetega töötamine, antud juhul kasutajate jaoks). Kuna vea põhjused on üldjuhul teadmata, on meile jäänud aga üks lahendus — iga kasutajate poolt leitud viga peab olema lisatud regressioonitestimisse, et olla kindel, et see ei ilmne enam.

Allikas: habr.com