Handout. Hoe testers de kwaliteit van requirements kunnen beïnvloeden. Slechte requirements zijn overal. Testnet thema-avond Requirements.

Transcriptie

1 Hoe testers de kwaliteit van requirements kunnen beïnvloeden Testnet thema-avond Slechte requirements zijn overal 2 Pagina 1

2 En dan heb je goede requirements 3 proces proces ontwikkeling validatie management - Stakeholders - Behoeften -Eisen - Juistheid - Volledigheid - Realiseerbaarheid - Wijzigingsprocedure - Traceerbaarheid - Verificatie 4 Pagina 2

3 en verantwoordelijkheden ontwikkeling validatie management 100% Verantwoordelijkheid realisatie 50% Verantwoordelijkheid business 0% Start project Einde project 5 in projecten Mate van concreetheid 100% 0% Business requirements Gebruikers requirements Systeem requirements Tijd 6 Pagina 3

4 Das mooi, al die theorie over requirements. Maar hoe kan ik als tester nu zorgen dat de kwaliteit van de requirements goed is? 7 Waar in het proces kan ik wat als tester? proces ontwikkeling validatie management - Stakeholders - Behoeften -Eisen - Juistheid - Volledigheid - Realiseerbaarheid - Wijzigingsprocedure - Traceerbaarheid - Verificatie 8 Pagina 4

5 Waar in het proces kan ik wat als tester? proces ontwikkeling validatie management - Stakeholders - Behoeften -Eisen - Juistheid - Volledigheid - Realiseerbaarheid - Wijzigingsprocedure - Traceerbaarheid - Verificatie 9 validatie Pagina 5

6 Overzicht validatietechnieken Validatietechnieken Correcte requirements Review en inspectie Diagrammen en modellen Voldaan aan gebruikerbehoefte Walkthrough (Use case) scenarios Acceptatietestgevallen opstellen Handleiding maken Prototype Simulatie 11 Eisen aan requirements # Eis Toelichting 1 Geïdentificeerd hebben een identificatienummer, business owner en een prioriteit (MoSCoW) 2 Atomair zijn niet deelbaar 3 Traceerbaar Systeem requirements zijn herleidbaar tot user requirements, die herleidbaar zijn tot de business requirements, die gebaseerd zijn op de bedrijfsdoelstelling 4 Grammaticaal correct zijn geformuleerd in volledige zinnen, hebben een belanghebbende (bv. gebruiker, organisatie, systeem als onderwerp) en een gezegde 5 Bevatten geen verboden woorden Verboden woorden zijn: op zich, zo mogelijk, sommige, optimaal, bijna altijd, deels, meestal, bijna allemaal, weinig, in het algemeen, normaliter, beperkt, in principe, zelden, voldoende, et cetera, vrijwel niet als, eigenlijk 6 Geaccepteerd zijn goedgekeurd door de business owner 7 Meetbaar Van ieder requirement is vast te stellen of het correct geïmplementeerd is 8 Bevat geen ontwerpaspecten Een requirement bevat geen aanwijzingen hoe het geïmplementeerd moet worden 9 10 Uniform gedefinieerd Onderling consistent Bij het opstellen is gebruik gemaakt van de verklarende woordenlijst (glossary) zijn niet strijdig met elkaar 12 Pagina 6

7 Verificatie op basis van requirements Het belang van verificatie Req. Ontwerp Code 14 Pagina 7

8 Essentie van verificatie Tussenproduct 1 Tussenproduct 2 Tussenproduct 3 15 Technieken voor verificatie Management review Inhoudelijke review Inspectie Walkthrough Audit 16 Pagina 8

9 Dus: boeken lezen (of cursus doen) Een mogelijke toekomst? Wens Verwachting Acceptatie tests Functioneel ontwerp Systeem tests Technisch ontwerp Integratie tests Systeem realisatie Programma tests 18 Pagina 9

10 Hoe overtuig jij je projectmanager? Kwaliteit verhogen Tijd besparen Zekerheid Continuïteit Geld besparen Gemak / comfort Veiligheid Status Pagina 10

11 Voorbeeld vermijdbare faalkosten Fase # fouten Factor Pot. besparing Functioneel ontwerp Technisch ontwerp Bouw Bouwtest uur 80 uur 28 Totaal Bij 80,= per uur, bedragen de vermijdbare kosten ,- N.B. we vinden 50% van de fouten bij reviewen / inspecteren, dus in praktijk besparen we ,-. 21 Wat de échte levenskenners ervan vinden 22 Pagina 11

12 De sheets staan op onder publicaties Pagina 12