Testuotojai Turi Buti Itraukiami Pradzioje

Testuotojai turi būti įtraukiami pradžioje Testuotojai turi būti įtraukiami pačioje projekto gyvavimo ciklo pradžioje, kad jie galėtų tiksliai suprasti, ką jie testuoja, ir kad galėtų dirbti su kitais suinteresuotais asmenimis, kad sukurti ištestuojamus (testable) reikalavimus. Defektų prevencija (defect prevention) – technikų ir procesų naudojimas, kurie gali padėti susekti (detect) ir išvengti (avoid) klaidų (errors) prieš tai, kol jos nepasidaugino (propagate) vėlesnėse kūrimo fazėse. Defektų prevencija yra efektyviausia reikalavimų fazės metu, kai pakeitimo, kai reikia ištaisyti defektą, įtaka yra maža. Pakeitimai (modifications) bus tiktai reikalavimų dokumentacijoje ir galbūt testavimo plane, kurie šioje fazėje yra vystomi. Jeigu testuotojai (kartu su kitais suinteresuotais asmenimis) yra įtraukiami kūrimo gyvavimo ciklo pradžioje, jie gali padėti nustatyti tai, kas praleista (omissions), atpažinti prieštaravimus/neatitikimus (discrepancies), dviprasmiškumus (ambiguities) ir kitas problemas, kurios gali paveikti reikalavimų ištestuojamumą, teisingumą ir kitas savybes. Reikalavimas gali būti ištestuojamas, jeigu yra įmanoma sukurti procedūrą, kurioje testuojamas funkcionalumas gali būti įvykdytas, žinomi laukiami rezultatai/išvestys (expected output), kurie gali būti programiškai arba vizualiai patikrinti. Testuotojai turi turėti tvirtą(solid) supratimą apie produktą, kad jie galėtų sugalvoti geresnius ir labiau užbaigtus testavimo planus (plans), projektus (designs), procedūras ir atvejus. Ankstyvas testavimo komandos įtraukimas gali pašalinti netvarką/painiavą funkcijų elgesyje, galinčią atsirasti vėlesniu projekto gyvavimo ciklo metu. Taip pat, ankstyvas įtraukimas testavimo komandai leidžia išmokti prieš laiką, to pasekoje jie turi kritiškesnį žvilgsnį į programą (application), tokį kaip galutiniai naudotojai ir žvilgsnį į aukščiausios rizikos elementus. Šios žinios padeda testuotojams pirmiausia susitelkti į svarbiausias programos dalis. Kai kurios organizacijos atsižvelgia į testuotojus griežtai, kaip reikalavimų ir kitų PĮ kūrimo darbo produktų vartotojus (consumers), kurie turi patys išmokti kaip naudotis programa (application) ir , tik tada kai sukuriama PĮ, tada yra pristatoma testuotojams, vietoj to, kad juos įtraukti anksčiausioje fazėje. Tai gali būti priimtina mažuose projektuose, bet sudėtingose aplinkose yra nerealu tikėtis iš testuotojų surasti visus didžiulius defektus, kurie yra palikti (exposure) programoje poto, kai jie jau buvo reikalavimų, analizės, projektavimo ir kituose PĮ vykdymuose. Dar daugiau, kad tik suprasti PĮ „įvestis ir išvestis“, testuotojams reikia gilesnių žinių, kurias gali įgyti per proceso supratimą naudojant specifikacijoje aprašytą produkto funkcionalumą. Toks supratimas ne tik padidina kuriamų testavimo procedūrų kokybę ir gylį, bet taip pat leidžia testuotojams sukurti atsiliepimus (feedback) apie reikalavimus. Kuo anksčiau gyvavimo cikle defektai atrandami, tuo pigiau kainuos juos pataisyti. Lentelėje pateikiamas kainos ištaisyti defektą ir gyvavimo ciklo fazės (stage), kuriame defektas surandamas, ryšys: Fazė Apibrėžimas Aukšto lygio planas Žemo lygio planas Kodas

Susijusi defekto ištaisymo kaina ($) 1 2 5 10 1

Vieneto testavimas Integracijos testavimas Sistemos testavimas Po pateikimo (post-delivery)

15 22 50 100+

2

Nuadota literatūra: „Effective software testing : 50 specific ways to improve your testing“ Elfriede Dustin

3