Testavimas – tai įrankis kokybei pamatuoti. Norint, kad atrastos problemos būtų pašalintos, apie jas visų pirma turi būti pranešta. Iš kitos pusės testavimas yra susijęs su rizikos valdymu, o mes negalime valdyti rizikos neturėdami duomenų. Todėl kyla poreikis atrastus defektus ne tik komunikuoti, bet ir valdyti juos.
|
Defekto ataskaita yra priemonė, leidžianti įvertinti, ar įmonei yra verta leisti savo laiką ir pinigus klaidos ištaisymui. – Cem Kaner |
|---|
Testavimas – tai įrankis kokybei pamatuoti. Jo metu mes siekiame įvertinti, ar programinė įranga atitinka apibrėžtus kokybės kriterijus ir nustatyti problemas (defektus), dėl kurių sistema negali atitikti vartotojo lūkesčių.
Norint, kad atrastos problemos būtų pašalintos, apie jas visų pirma turi būti pranešta. Iš kitos pusės testavimas yra susijęs su rizikos valdymu, o mes negalime valdyti rizikos neturėdami duomenų. Todėl kyla poreikis atrastus defektus ne tik komunikuoti, bet ir valdyti juos. Defektų valdymui visų pirma reikalingas jų dokumentavimas. Tokiu būdu defektų komunikavimas ir valdymas tampa būtina testavimo proceso dalimi, o defekto ataskaita – technine dokumentacija, aprašančia defekto simptomus, kai sistema elgiasi ne taip, kaip turėtų.
Kodėl defektų komunikavimo ir raportavimo procesas yra toks svarbus? Defektų ataskaita yra ne tik aprašomi klaidos simptomai, bet ir:
- Įvertinama rizika, kad klaidą pastebės tipinis sistemos vartotojas.
- Nurodoma žala, kurią klaida daro vartotojui ir sistemai.
- Izoliuojant defektą padedama tiksliau nustatyti klaidos ištaisymo kaštus ir riziką.
Ši defektų ataskaitose pateikta informacija padeda tiksliau nustatyti testuojamo produkto kokybės lygį, įvertinti reikalingų pataisymų kiekį ir su jais susijusius kaštus.
Defektų raportavimo procesas
|
Geriausias testuotojas yra ne tas, kuris atranda daugiausia defektų. Geriausias testuotojas yra tas, kurio atrastų defektų yra daugiausia ištaisoma. – Cem Kaner |
|---|
Defekto ataskaita visų pirma yra komunikacijos priemonė tarp kokybės inžinieriaus ir kitų projekto narių. Kuo aiškiau ir tiksliau bus aprašyta klaida, tuo didesnė tikimybė, kad ji greičiau bus ištaisyta. Deja, dažnai defektų raportavimas yra suprantamas kaip elementari ir nereikalaujanti įgūdžių veikla. Dėl neefektyvių defektų ataskaitų didelė dalis defektų yra grąžinami kaip nepakartojami. Rezultatas – gaištamas laikas defekto ataskaitos taisymui, ilgėja defekto ištaisymo ciklas, prastėja santykiai tarp kokybės inžinieriaus ir programuotojo.
UAB „Baltijos programinė įranga“ klaidų ataskaitų rašymas yra laikomas techninės dokumentacijos kūrimu: defektų raportavimo procesas yra apibrėžtas įmonės ir projektų lygiuose, nustatytas defekto ataskaitos šablonas, sukurtas defektų ataskaitų rašymo stiliaus rekomendacijų dokumentas. Įmonėje defekto raportavimo procesą sudaro šios veiklos:
1. Pakartojimas
Lietuvių liaudies patarlė sako: „Devynis kartus matuok, dešimtą kirpk“. Prieš rašant defekto ataskaitą, klaidinga situacija turi būti pakartota bent keletą kartų. Bet ką daryti, jei defekto nepavyksta pakartoti kiekvieną kartą? UAB „Baltijos programinės įranga“ defektų ataskaitos stiliaus rekomendacijose tokiu atveju į defekto ataskaitą yra siūloma įtraukti papildomą informaciją apie defekto pakartojamumą. Pavyzdžiui, „Jei nepavyko pakartoti defekto, nukopijuok tekstą ir pakartok testavimo žingsnius iš naujo“.
2. Perteklinių žingsnių pašalinimas
Kokybės inžinieriaus tikslas yra kuo tiksliau programuotojui pateikti informaciją apie rastą defektą. Tiksliai aprašyti defekto simptomai padeda programuotojui greitai atrasti ir pašalinti defekto priežastį. Defekto ataskaitoje turi būti palikti tik tie žingsniai, kurie yra tiesiogiai susiję su klaida. Perteklinių žingsnių pašalinimas atliekamas defekto kartojimo metu naudojant skirtingas žingsnių kombinacijas, taip pat paeiliui šalinant žingsnius ir stebint, ar jie turėjo įtakos defekto atsiradimui.
3. Apibendrinimas
Dažnai klaidos simptomai, kuriuos stebi kokybės inžinierius konkrečiu atveju iš tiesų yra bendros problemos dalis. Tarkime, kokybės inžinierius atranda problemą, kad lentelės sukūrimui naudojamas spartusis klavišas Ctrl+Shift-1 neveikia, jei skaičius įvedamas naudojant klaviatūros skaitmenų sritį. Atlikus papildomą testavimą paaiškėja, kad visi naudojantys skaičius spartieji klavišai neveikia, jei skaičių įvedimui naudojama klaviatūros skaitmenų sritis. Defekto apibendrinimas padeda tiksliau įvertinti klaidos poveikį sistemą ir įvertinti jos ištaisymo svarbą.
4. Dviprasmiškumo panaikinimas
Ištrauka iš defekto ataskaitos: „Prisijungimo lange įvesk ilgą vartotojo vardą“. Kas yra ilgas vartotojo vardas: 6, 10, ar 100 simbolių? Aiškumas yra kokybiškos defekto ataskaitos pagrindas. Defekto ataskaitoje neturi būti vartojami žodžiai ar frazės, kuriuos perskaičius kiltų klausimas: ką tiksliai kokybės inžinierius norėjo pasakyti?
5. Defekto prioriteto ir poveikį įvertinimas
Vienas iš testavimo principų sako: „Ne visi rasti defektai bus ištaisyti“. Kaip pasirinkti, kokius defektus taisyti, o kokius ne? Nėra programinės įrangos, kuri neturėtų defektų. Tiesiog gera programinė įranga yra ta, kurioje yra atrasti ir ištaisyti tie defektai, kuriuos pastebėtų didžioji dalis sistemos vartotojų. Todėl kiekvieną rastą defektą mes turime įvertinti dviem aspektais: 1) kokia tikimybė, kad sistemos tipinis vartotojas pastebės defektą ir tokiu būdu nustatyti jo prioritetą; 2) kokią žalą defektas daro sistemai ir vartotojui ir taip nustatyti jo poveikį.
| UAB „Baltijos programinė įranga“ prioriteto ir poveikio reikšmės gali būti apibrėžtos kiekvienam projektui atskirai. „MagicDraw“ projekte defektai gali būti A, B arba C prioriteto ir daryti kritinį, didelį, blokuojantį, mažą, trivialų arba kosmetinį poveikį sistemai. |
|---|
6. Papildoma informacija
Be defekto simptomų aprašymų, poveikio ir prioriteto nustatymo defektų valdymui yra svarbi defektą papildanti informaciją: kas rado defektą, kada jis buvo rastas, kokiame sistemos modulyje, kokioje testuojamos sistemos versijoje ir pan. UAB „Baltijos programinė įranga“ defektų ataskaitų įvedimui yra naudojama defektų valdymo sistema (paveikslas Nr. 1).
7. Santrauka
Defekto ataskaitos santrauka yra trumpas klaidos apibūdinimas vienu sakiniu. Trumpa defekto santrauka padeda greitai suprasti, kurioje produkto dalyje yra klaida ir koks jos poveikis sistemai. Pavyzdžiui, defekto santrauka „Stereotipo piktograma nėra rodoma diagramoje“ yra žymiai aiškesnė nei „Stereotipo pikrogramos rodymas“.
Geros defekto ataskaitos santraukos parašymui gali prireikti daugiau įgūdžių nei atrodytų iš pirmo žvilgsnio. Trumpam ir aiškiam tekstui parašyti dažnai reikia skirti daug laiko. Thom Jefferson kartą ilgą laišką užbaigė sakiniu: „Būčiau parašęs trumpesnį laišką, bet neturėjau laiko“.
8. Peržiūra
Projekto artefaktų peržiūros padeda anksti atrasti defektus ir taip sumažinti jų ištaisymo kaštus. Defekto ataskaita taip pat yra techninis dokumentas, kuriam turi būti taikoma peržiūra. UAB „Baltijos programinė įranga“ defektų ataskaitų peržiūras priklausomai nuo projekto dydžio atlieka kokybės grupės vadovas arba projekto vadovas.
1 pav. Defekto ataskaitos įvedimo forma
Programinės įrangos defektų valdymo sistemos
Kiekviena defekto ataskaita turi savo gyvavimo ciklą: ji yra sukuriama, defektas išsprendžiamas, patikrinamas ir uždaromas. Periodo nuo defekto ataskaitos sukūrimo iki uždarymo trukmė priklauso nuo pasirinkto programinės įrangos kūrimo proceso, o taip pat nuo defektų valdymo efektyvumo.
UAB „Baltijos programinė įranga“ defektai yra valdomi naudojant defektų valdymo sistemą. Kodėl defektų valdymui buvo pasirinktas įrankis? Defektų valdymo sistemos naudojimas teikia įvairiapusę naudą projektui:
1. Aiškesnė komunikacija
Remiantis apibrėžta forma sukurtos defektų ataskaitos yra suprantamos kur kas aiškiau nei žodžiu perduota ar laisva forma parašyta informacija apie klaidą.
2. Defekto gyvavimo ciklo valdymas
Defektų ataskaitos yra valdomos nuo jų sukūrimo momento iki galutinio uždarymo. Defektų valdymo įrankiai paprastai jau turi įdiegtą defekto gyvavimo ciklą, tačiau jis gali būti modifikuojamas ir pritaikomas pagal projekto poreikius. UAB „Baltijos programinė įranga“ yra apibrėžtas defektų valdymo ciklas (paveikslas Nr. 2):
- Naują defekto ataskaitą projekto vadovas priskiria programuotojui.
- Programuotojas analizuoja naujo defekto ataskaitą ir, jei ištaiso klaidą, pažymi defekto ataskaitą kaip ištaisytą. Jei programuotojas negali ištaisyti klaidos, defekto ataskaitai yra nurodoma viena iš standartinių žymių, rodančių, kad defektas bus taisomas vėliau ar nebus taisomas iš viso.
- Kokybės inžinierius tikrina išspręstą defekto ataskaitą ir patvirtina jos išsprendimą, jeigu klaida ištaisyta tinkamai, arba atmeta išsprendimą, jeigu klaida yra neištaisyta, ištaisyta netinkamai ar tik dalinai. Atmetus išsprendimą, defekto ataskaita vėl yra laikoma nauja.
- Patvirtintos defekto ataskaitos gali būti uždaromas arba naudojamos pakartotinio testavimo metu. Jei defektas, kurio simptomai aprašyti jau uždarytoje defekto ataskaitoje, atsinaujina, defekto ataskaita yra pakartotinai atidaroma.
2 pav. Defekto gyvavimo ciklas
3. Ataskaitų generavimo funkcijos
Defektų valdymo sistemoje yra saugoma visa informacija apie testuojamos programinės įrangos defektus. Duomenų analizės ir ataskaitų generavimo priemonės padeda projekto vadovui įvertinti ir stebėti testuojamos sistemos kokybę.
4. Defekto ataskaitos istorijos saugojimas
Defekto ataskaitai pereinant iš vieno gyvavimo ciklo etapo į kitą vis daugiau informacijos yra sužinoma apie defekto atsiradimo priežastį. Defektų valdymo sistemos turi komentarų rašymo ir pokyčių istorijos saugojimo funkcijas, kurios suteikia vertingos informacijos apie defekto būseną ir jo vienokio ar kitokio išsprendimo priežastis.
5. Skirtingos vartotojų grupės
Defektų valdymo sistema yra naudojama visų projekto funkcinių grupių: kokybės inžinierius kuria naujas defektų ataskaitas ir tikrina ištaisytus defektus; programuotojas dirba tik su naujomis defektų ataskaitomis; analitikas peržiūri pasiūlymus; projekto vadovas priskiria defektų ataskaitas programuotojams, o taip pat seka defektų kitimo tendencijas. Defektų valdymo sistemose gali būti sukuriamos vartotojų grupės, suformuotos atsižvelgiant į projekto funkcines grupes ir jų dažniausiai atliekamas veiklas.
6. Užklausų galimybės
Defektų valdymo sistemą naudoja vartotojų grupės, kurioms svarbi skirtinga informacija. Jei programuotojas paprastai dirba su jam priskirtomis naujomis defektų ataskaitomis, tai kokybės inžinieriui testuojančiam konkrečią sistemos dalį yra svarbūs visi su ta dalimi susiję duomenys. Defektų valdymo sistemos turi užklausų formavimo galimybes, kurios leidžia efektyviai filtruoti duomenis ir matyti tik tą informaciją, kuri yra reikalinga.
Defektų valdymo sistemą galima įdiegti keliais būdais: 1) nusipirkti; 2) nusipirkti ir pritaikyti pagal savo poreikius; 3) sukurti naują defektų valdymo sistemą patiems. Pasirinkimo būdą gali įtakoti tai, ar įmonė jau vykdo defektų valdymą. Jei defektų valdymo procesas yra jau apibrėžtas, įmonei verta kurti savo defektų valdymo sistemą arba pirkti pritaikomą individualiam procesui įrankį. UAB „Baltijos programinė įranga“ taip pat naudoja savo sukurtą defektų valdymo sistemą.
Programinės įrangos defektų analizė naudojant metrikas
|
Rakštis gali būti ištraukta, tik jei žinai, kur ji yra. – Rabindranath Tagore |
|---|
Programinės įrangos defektų valdymo sistemos ne tik padeda sutrumpinti ir valdyti defektų gyvavimo ciklą. Duomenų apie defektus analizė gali mums padėti įvertinti testuojamos sistemos kokybės lygį ar jos tinkamumą atiduoti vartotojui. Vienas iš testavimo tikslų yra defektų prevencija – priemonių, padedančių sumažinti klaidų kiekį vėlesniuose programinės įrangos etapuose, paieška ir taikymas. Analizuodami defektų valdymo sistemoje užregistruotus defektus, mes galime suprasti klaidų atsiradimo priežastis, o tai leidžia sumažinti tokių pačių klaidų pasikartojimą ateityje.
Defektų duomenų analizė yra atliekama naudojant metrikas – kiekybinius matus, parodančius, kiek sistema ar jos komponentas atitinka nustatytus atributus. Projektuose gali būti naudojamos standartinės programinės įrangos defektų metrikos (pavyzdžiui, defektų tankis – defektų skaičiaus ir kodo eilučių kiekio santykis) arba sukurti individualūs, pritaikyti projektui arba įmonės procesui matavimai.
Metrikos yra naudojamos ir UAB „Baltijos programinė įranga“, kuriant „MagicDraw“ produktą. Remiantis matavimais yra sekamas produkto kokybės lygis testavimo etapų metu, taip pat nustatoma, ar produktas atitinka išleidimo kriterijus. Sprendimus apie produkto kokybės lygį padeda priimti duomenys apie sukurtų, ištaisytų ir patikrintų defektų santykį ir jų kitimą. Informacija yra pateikiama naudojant grafikus (paveikslas Nr. 3), kurie yra puiki komunikacijos priemonė, kalbant apie produkto kokybę su kitais projekto nariais.
3 pav. Raportuotų ir ištaisytų defektų santykio sekimo grafiko pavyzdys
Tam, kad matavimai būtų tikslūs, defektų valdymo sistemos duomenys yra suderinami su informacija iš darbuotojų laiko valdymo sistemos.
Baigiamasis žodis
Natūralu, kad testavimo metu yra atrandami defektai. Norėdami, kad jie būtų ištaisyti, mes turime apie juos pranešti kitiems projekto nariams. Norėdami taisyti defektus efektyviai, mes turime juos valdyti. Norėdami tiksliai įvertinti testuojamos sistemos kokybę arba nebekartoti tokių pačių klaidų ateityje, naudodami įvairius matavimus mes turime analizuoti duomenis apie defektus. UAB „Baltijos programinė įranga“ visos šios veiklos yra vykdomos ir matoma jų teikiama nauda. Mes tikimės, kad šiame straipsnyje pateikta informacija Jums buvo aktuali ir naudinga.
