Sissejuhatus
Tere pärastlõunast, Habrovski elanikud. Just praegu lahendasin fintech-ettevõtte QA Lead vaba töökoha testülesannet. Esimest ülesannet – koostada katseplaan koos täieliku kontrollnimekirja ja elektriveekeetja testimise katsejuhtumite näidetega – saab lahendada triviaalselt:
Täieliku kontrollnimekirjaga paremat testiplaani on raske välja mõelda.
Kuid teine osa osutus küsimuseks: "Kas kõigil testijatel on ühiseid probleeme, mis takistavad neil tõhusamalt töötada?"
Esimese asjana tuli meelde, et loetlesin üles kõik enam-vähem märgatavad probleemid, millega testimise käigus kokku puutusin, pisiasjad välja rookisin ja ülejäänu kokkuvõtteks. Kuid mõistsin kiiresti, et induktiivne meetod vastab küsimusele, mis ei kehti "kõigi", vaid parimal juhul ainult "enamiku" testijate kohta. Seetõttu otsustasin läheneda asjale teisest küljest, deduktiivselt ja nii see juhtus.
Mõisted
Esimene asi, mida ma tavaliselt uue probleemi lahendamisel teen, on püüda aru saada, millega see kõik on seotud, ja selleks pean mõistma seda esitavate sõnade tähendust. Võtmesõnad, mida mõista, on järgmised:
- probleem
- tester
- testija töö
- testeri efektiivsus
Pöördume Vikipeedia ja terve mõistuse poole:
(vanakreeka πρόβλημα) laiemas tähenduses - keeruline teoreetiline või praktiline küsimus, mis nõuab uurimist ja lahendamist; teaduses - vastuoluline olukord, mis ilmneb vastandlike seisukohtade kujul mis tahes nähtuste, objektide, protsesside selgitamisel ja nõuab selle lahendamiseks adekvaatset teooriat; elus sõnastatakse probleem inimestele arusaadavas vormis: “tean mida, ei tea kuidas” ehk on teada, mida on vaja hankida, aga ei teata, kuidas seda teha. . Pärineb hilja. lat. probleem kreeka keelest. πρόβλημα “visatakse ette, asetatakse ette”; sõnast προβάλλω “viska ette, pane enda ette; süüdistada".
Sellel pole palju mõtet, tegelikult "probleem" = "kõik, millega tuleb tegeleda".
- spetsialist (tüüpi me ei jaga, kuna oleme huvitatud kõigist testijatest), kes osaleb komponendi või süsteemi testimises, mille tulemus on:
— testimisega seotud tegevuste kogum.
(lat. Effectivus) - saavutatud tulemuse ja kasutatud ressursside suhe (: 2015).
- toimingute (tulemuse) või sündmuste ahela (seeria) tagajärg, väljendatuna kvalitatiivselt või kvantitatiivselt. Võimalike tulemuste hulka kuuluvad eelised, puudused, kasu, kaotus, väärtus ja võit.
Nagu ka "probleemil", on sellel vähe tähendust: midagi, mis tuli välja töö tulemusena.
- inimese või inimeste mis tahes tegevuse teostamise kvantitatiivselt mõõdetav võimalus; tingimused, mis võimaldavad soovitud tulemuse saavutamiseks kasutada teatud teisendusi. Testija on inimene ja elutähtsate ressursside teooria kohaselt on iga inimene nelja majandusvara omanik:
raha (sissetulek) on taastuv ressurss;
energia (elujõud) on osaliselt taastuv ressurss;
aeg on püsiv ja põhimõtteliselt taastumatu ressurss;
teadmised (informatsioon) on taastuv ressurss, see on osa inimkapitalist, mis võib kasvada ja hävida.
Tahaksin märkida, et efektiivsuse määratlus meie puhul ei ole täiesti õige, kuna mida rohkem teadmisi kasutame, seda madalam on efektiivsus. Seetõttu defineeriksin tõhususe ümber kui "saavutatud tulemuste ja kulutatud ressursside suhe". Siis on kõik õige: teadmisi ei raisata töö käigus, vaid see vähendab testija ainsa põhimõtteliselt taastumatu ressursi - tema aja - kulusid.
otsus
Seega otsime testijate globaalseid probleeme, mis vähendavad nende töö efektiivsust.
Kõige olulisem ressurss, mis testija tööle kulub, on tema aeg (ülejäänu võib nii või teisiti sellele taandada) ja selleks, et saaksime rääkida õigest efektiivsuse arvutamisest, tuleb ka tulemus ajaliselt taandada. .
Selleks kaaluge süsteemi, mille elujõulisuse testija oma tööga tagab. Selline süsteem on projekt, mille meeskonda kuulub testija. Projekti elutsüklit saab ligikaudu esitada järgmise algoritmiga:
- Nõuetega töötamine
- Tehniliste kirjelduste kujundamine
- Areng
- Katsetamine
- Tootmisse vabastamine
- Tugi (liiku üksusesse 1)
Sel juhul saab kogu projekti rekursiivselt jagada sama elutsükliga alamprojektideks (funktsioonideks).
Projekti seisukohast on nii, et mida vähem aega sellele kulub, seda tulemuslikum on selle elluviimine.
Seega jõuame testija maksimaalse võimaliku efektiivsuse määratluseni projekti seisukohalt - see on projekti seis, kui testimise aeg on null. Kõigi testijate ühine probleem on suutmatus seda aega saavutada.
Kuidas sellega toime tulla?
Järeldused on üsna ilmsed ja paljud on neid juba pikka aega kasutanud:
- Arendus ja testimine peaksid algama ja lõppema peaaegu samaaegselt (seda teeb tavaliselt osakond ). Ideaalne variant on see, kui kogu arendatav funktsionaalsus on selleks ajaks, kui see on valmis, juba kaetud automaattestidega, mis on organiseeritud regressioonitestideks (ja võimalusel ka eeltestimiseks), kasutades selleks mingisugust .
- Mida rohkem funktsioone projektil on (seda keerulisem see on), seda rohkem aega tuleb kulutada kontrollimisele, et uus funktsionaalsus ei lõhuks vana. Seega, mida keerulisem on projekt, seda rohkem on vaja automatiseerimist .
- Iga kord, kui jätame tootmises vea vahele ja kasutaja selle leiab, peame kulutama lisaaega projekti elutsükli läbimiseks alates punktist 1 (Nõuetega töötamine, antud juhul kasutajad). Kuna vea puudumise põhjused on üldjuhul teadmata, siis jääb meil üle vaid üks optimeerimistee – iga kasutajate leitud viga tuleb regressioonitestidesse kaasata, et olla kindel, et see enam ei ilmu.
Allikas: www.habr.com