Agile toetsplan - het ons regtig een nodig?

Het ons 'n Agile toetsplan dokument nodig?

Toetsbeplanning is 'n belangrike aktiwiteit van 'n toetsproses en dit verg nie net die toetsbestuurder (wat gewoonlik verantwoordelik is vir die opstel van die toetsplan) nie, maar ook alle lede van die toetsspan en produkontwikkelingsbestuurder.

Sommige mense glo dat dit die belangrikste deel van die toetsproses is (ek dink persoonlik is toetsontwerp en abstrakte denke die belangrikste) en spandeer baie ure en moeite om 'n wonderlike toetsplan uit te dink.

Handboeke wy 'n hele afdeling met betrekking tot toetsbeplanning, hoe om een ​​te skryf en wat om in 'n toetsplan op te neem, terwyl sommige beheerliggame en regulerende organisasies soos die FDA 'n omvattende toetsplan benodig om 'n produk goed te keur.

In die regte wêreld, in 'n watervalomgewing, is die toetsplandokument gereeld een waarna daar gedurende die lewensiklus van die produk amper nooit gekyk word nie. Die aktiwiteit van 'Toetsbeplanning en -monitering' moet 'n deurlopende aktiwiteit gedurende die lewensiklus van die projek wees, dit moet bygewerk word volgens die veranderinge aan die projek, maar in die meeste gevalle is dit nie die geval nie; toetsplan word óf nie bygewerk nie, óf veranderinge is terugwerkend, wat die dokument van die toetsplan die minste waardevolle neweproduk maak.

Terwyl toetsbeplanning byna altyd beskou word as 'n moet-hê-produk in 'n watervalprojek, het ons regtig 'n toetsplan nodig vir 'n behendige projek? dws voeg dit regtig waarde toe aan wat die hele span probeer bereik?

Die rats manifes bevoordeel duidelik werk sagteware oor omvattende dokumentasie en reageer op verandering oor 'n plan te volg.

In 'n ratse omgewing word die inhoud van 'n vrystelling (die items) voor die sprint bespreek, sodat die toetsspan vooraf weet wat die omvang is en wat getoets moet word.

In die 'beplanningspookspel' word die beramings bespreek, sodat die toetsspan weet hoe lank dit sal duur om 'n funksie te toets (dit sluit in die opstel van die omgewing, scenario's, outomatisering, verkennendheid, prestasie, ens.).

In 'n storieskryf-sessie 'waar die besonderhede van elke funksie goed deurdink word, begin die toetsspan al scenario's skryf om die verhale te toets waarop verhale getoets kan word - dit is die waardevolste aktiwiteit van die span.

Gedurende die sprint toets QA voortdurend nuwe kode / funksie. Toetsbeplanning word 'n dinamiese aktiwiteit namate die prioriteite vir die dag verander. Toetsing is gebaseer op die aktiwiteit van die dag en die uitslag van die vorige dag.

Dit is duidelik dat die toetsplan nie gebreke openbaar nie, maar wel die toetse. Die poging moet verskuif word na die skep van beter scenario's as om 'n toetsplan te skep.

Wat regtig nodig is, is kort ratse toetsstrategiedokument wat die prosesse uiteensit wat van toepassing is op sprints , dit wil sê afdelings oor Sprintbeplanning, spesifikasieswerkswinkels, handleiding QA, outomatisering, toetsdekking, toetsverslaggewing, toetsomgewings, opvoering, ens.… Dit is prosesse en aktiwiteite wat van toepassing is op elke sprint, maar natuurlik afgelei deur die onderneming se visie.

Dus, met dit alles in gedagte, is die toetsplan-dokument of uitgebreide toetsstrategieë regtig iets van die verlede? Het ons regtig 'n Agile Toetsplan nodig?