Ynlieding
Goeiemiddei, ynwenners fan Khabrovsk. Krekt no wie ik it oplossen fan in testtaak foar in QA Lead fakatuere foar in fintech bedriuw. De earste taak, it meitsjen fan in testplan mei in folsleine checklist en foarbylden fan testgefallen foar it testen fan in elektryske tsjettel, kin triviaal oplost wurde:
It is lestich om te tinken oan in better testplan mei in folsleine checklist.
Mar it twadde diel blykte in fraach te wêzen: "Binne d'r problemen mienskiplik foar alle testers dy't foarkomme dat se effisjinter wurkje?"
It earste ding dat yn 't sin kaam wie om alle min of mear opfallende problemen op te listjen dy't ik tsjinkaam by testen, de lytse dingen útwreidzje en de rest gearfetsje. Mar ik realisearre gau dat de induktive metoade in fraach soe beäntwurdzje dy't net fan tapassing wie op "allegear", mar, op syn bêst, allinich foar "de mearderheid" fan testers. Dêrom besleat ik it fan 'e oare kant te benaderjen, deduktyf, en dit is wat bard.
Definysjes
It earste wat ik normaal doch by it oplossen fan in nij probleem is om te besykjen te begripen wêr't it oer giet, en om dit te dwaan moat ik de betsjutting fan 'e wurden begripe dy't it foarstelle. De kaaiwurden om te begripen binne de folgjende:
- in probleem
- tester
- tester baan
- tester effisjinsje
Litte wy nei Wikipedia en sûn ferstân gean:
(Aldgryksk πρόβλημα) yn brede sin - in komplekse teoretyske of praktyske kwestje dy't stúdzje en resolúsje fereasket; yn 'e wittenskip - in tsjinstridige situaasje dy't ferskynt yn' e foarm fan tsjinoerstelde posysjes yn 'e ferklearring fan alle ferskynsels, objekten, prosessen en fereasket in adekwate teory om it op te lossen; yn it libben wurdt it probleem formulearre yn in foarm dy't foar minsken begryplik is: "Ik wit wat, ik wit net hoe," dat wol sizze, it is bekend wat te krijen is, mar it is net bekend hoe't it moat . Komt fan let. lat. probleem, út Gryksk. πρόβλημα "foarút smiten, foaroan pleatst"; fan προβάλλω “foaroer goaie, foar dy sette; skuld".
It makket net folle sin, yn feite, "probleem" = "alles dat moat wurde behannele."
- in spesjalist (wy sille net ferdiele yn soarten, om't wy binne ynteressearre yn alle testers) dy't dielnimme oan it testen fan in komponint of systeem, wêrfan it resultaat is:
- in set fan aktiviteiten yn ferbân mei testen.
(lat. effectivus) - de relaasje tusken it berikke resultaat en de brûkte middels (: 2015).
- in gefolch fan in keatling (rige) aksjes (resultaat) of eveneminten, kwalitatyf of kwantitatyf útdrukt. Mooglike útkomsten omfetsje foardiel, neidiel, winst, ferlies, wearde en oerwinning.
Lykas by it "probleem" is der net folle betsjutting: eat dat útkaam as gefolch fan wurk.
- de kwantitatyf mjitbere mooglikheid om elke aktiviteit fan in persoan of folk út te fieren; betingsten dy't it brûken fan bepaalde transformaasjes tastean om it winske resultaat te krijen. De tester is in persoan, en yn oerienstimming mei de teory fan fitale boarnen, elke persoan is de eigner fan fjouwer ekonomyske aktiva:
cash (ynkommen) is in duorsume boarne;
enerzjy (libbenskrêft) is in foar in part duorsume boarne;
tiid is in fêste en yn prinsipe net-duorsume boarne;
kennis (ynformaasje) is in duorsume boarne, it is in part fan minsklik kapitaal dat kin groeie en wurde ferneatige.
Ik wol opmerke dat de definysje fan effisjinsje yn ús gefal net hielendal korrekt is, om't de mear kennis wy brûke, hoe leger de effisjinsje. Dêrom soe ik effisjinsje opnij definiearje as "de ferhâlding tusken de berikte resultaten en de bestege boarnen." Dan is alles korrekt: kennis wurdt net fergriemd yn wurk, mar it ferleget de kosten fan de tester syn ienige fûnemintele net-duorsume boarne - syn tiid.
beslút
Dat, wy sykje wrâldwide problemen fan testers dy't de effektiviteit fan har wurk beynfloedzje.
De meast wichtige boarne dy't wurdt bestege oan it wurk fan in tester is syn tiid (de rest kin op ien of oare manier wurde redusearre), en om te praten oer de krekte berekkening fan effisjinsje, moat it resultaat ek wurde fermindere ta tiid .
Om dit te dwaan, beskôgje in systeem wêrfan de leefberens de tester soarget troch syn wurk. Sa'n systeem is in projekt wêrfan it team in tester befettet. De libbenssyklus fan it projekt kin rûchwei wurde fertsjintwurdige troch it folgjende algoritme:
- Wurkje mei Requirements
- Formaasje fan technyske spesifikaasjes
- Untwikkeling
- Testing
- Release yn produksje
- Stipe (gean nei item 1)
Yn dit gefal kin it hiele projekt rekursyf ferdield wurde yn subprojekten (funksjes), mei deselde libbenssyklus.
Ut it eachpunt fan it projekt, de minder tiid bestege oan it, hoe effektiver de útfiering is.
Sa komme wy by de definysje fan 'e maksimale mooglike effisjinsje fan in tester út it eachpunt fan it projekt - dit is de steat fan it projekt as de tiid foar testen nul is. In mienskiplik probleem foar alle testers is it ûnfermogen om dizze tiid te berikken.
Hoe om te gean mei dit?
De konklúzjes binne frij dúdlik en binne troch in protte brûkt foar in lange tiid:
- Untwikkeling en testen moatte hast tagelyk begjinne en einigje (dit wurdt normaal dien troch de ôfdieling ). De ideale opsje is as alle funksjonaliteit dy't ûntwikkele wurdt al bedutsen troch autotests op 'e tiid dat it klear is, organisearre yn regression (en, as mooglik, pre-commit) testen mei in soarte fan .
- Hoe mear funksjes in projekt hat (hoe komplekser it is), hoe mear tiid sil moatte wurde bestege oan it kontrolearjen dat de nije funksjonaliteit de âlde net brekt. Dêrom, hoe komplekser it projekt, hoe mear automatisearring nedich is .
- Elke kear as wy in brek misse yn produksje en in brûker fynt it, moatte wy ekstra tiid besteegje oan it projektlibbenssyklus fan punt 1 (Wurkje mei easken, yn dit gefal brûkers). Om't de redenen foar it missen fan in brek oer it algemien ûnbekend binne, bliuwe wy oer mei mar ien optimalisaasjepaad - elke brek dy't troch brûkers fûn wurdt moat opnommen wurde yn regressjetesten om der wis fan te wêzen dat it net wer sil ferskine.
Boarne: www.habr.com