Oplossingen voor het testen van objectgeoriënteerde software

Transcriptie

1 Oplossingen voor het testen van objectgeoriënteerde software Pieter van den Hombergh Fontys Hogeschool voor Techniek en Logistiek Software Engineering 14 maart 2013 HOM/FHTeL Oplossingen voor het testen van objectgeoriënteerde software 14 maart /21

2 Oplossingen voor het testen van objectgeoriënteerde software Pieter van den Hombergh Fontys Hogeschool voor Techniek en Logistiek Software Engineering 14 maart 2013 HOM/FHTeL Oplossingen voor het testen van objectgeoriënteerde software 14 maart /21

3 Overzicht 1 Processen Proces: Waterval of iteraties? V-Model 2 How concrete can you get? Priorities Timeboxing Altijd de tests automatiseren? 3 XP proces en proces stappen. En vergeet dit volgende niet. Test driven design HOM/FHTeL Oplossingen voor het testen van objectgeoriënteerde software 14 maart /21

4 Processen Proces: Waterval of iteraties? V-Model Test driven design: Processen en uitzonderingen Aanpak aanpassen aan project De test driven aanpak is niet een star patroon maar kan individueel op ieder project toegesneden worden. Belangrijk hierbij is dat van meet af aan een unittest-infrastructuur wordt opgebouwd die een eventueel noodzakelijke uitbreiding eenvoudig toelaat. We krijgen zo een hoge mate van flexibiliteit en kunnen heel gericht prioriteiten toekennen. HOM/FHTeL Oplossingen voor het testen van objectgeoriënteerde software 14 maart /21

5 Wat is een project Processen Proces: Waterval of iteraties? V-Model Eenmalige gebeurtenis: Een project is altijd iets bijzonders dat we eerder zo nog niet hebben uitgevoerd. Risico Een project is altijd blootgesteld aan het gevaar dat het kan mislukken. Daarom is een expliciet risicomanagement onvermijdelijk. Projectstructuren: Er is een opdrachtgever, projectleider, projectteam, projectopdracht, stuurgroep enz. Beperkingen: Een project vindt plaats binnen het kader van gedefinieerde grenzen. We hebben gelimiteerde resources en een vast budget. Projectmanagement heeft dus altijd iets van het beheren van tekorten. HOM/FHTeL Oplossingen voor het testen van objectgeoriënteerde software 14 maart /21

6 Het watervalmodel Processen Proces: Waterval of iteraties? V-Model HOM/FHTeL Oplossingen voor het testen van objectgeoriënteerde software 14 maart /21

7 Stagewise models Processen Proces: Waterval of iteraties? V-Model Het oorspronkelijke werkwijzemodel van Walker Royce breidde de stagewise models uit met terugkoppelingslussen (in de figuur links). HOM/FHTeL Oplossingen voor het testen van objectgeoriënteerde software 14 maart /21

8 Processen Proces: Waterval of iteraties? V-Model Het V-model uitbreiding op het watervalmodel HOM/FHTeL Oplossingen voor het testen van objectgeoriënteerde software 14 maart /21

9 (RUP) How concrete can you get? Priorities Timeboxing Altijd de tests automatiseren? Een incrementeel- iteratief geleid project valt in twee lagen uiteen, de chronologische, in fases onderverdeelde horizontale laag en de aan de hand van taken resp. disciplines onderverdeelde laag. HOM/FHTeL Oplossingen voor het testen van objectgeoriënteerde software 14 maart /21

10 How concrete can you get? Priorities Timeboxing Altijd de tests automatiseren? Incrementeel iteratieve werkwijze, schematisch Een huis in eigenbouw HOM/FHTeL Oplossingen voor het testen van objectgeoriënteerde software 14 maart /21

11 How concrete can you get? Priorities Timeboxing Altijd de tests automatiseren? Vaststellen en verdelen van prioriteiten HOM/FHTeL Oplossingen voor het testen van objectgeoriënteerde software 14 maart /21

12 De reserves in een timebox inplannen How concrete can you get? Priorities Timeboxing Altijd de tests automatiseren? HOM/FHTeL Oplossingen voor het testen van objectgeoriënteerde software 14 maart /21

13 structuur van een iteratie, timebox How concrete can you get? Priorities Timeboxing Altijd de tests automatiseren? Een iteratie heeft een tweeledige structuur: Implementatiegedeelte en een integratie- en reviewgedeelte. HOM/FHTeL Oplossingen voor het testen van objectgeoriënteerde software 14 maart /21

14 Wanneer tests automatiseren? How concrete can you get? Priorities Timeboxing Altijd de tests automatiseren? Of automatisering lonend is, hangt van verschillende omstandigheden af. Er moeten voldoende herhalingen van een onveranderde stabiele test uitgevoerd worden. Testautomatisering is een eigen softwareproject en krijgt pas zijn waarde na vijf tot tien herhalingen. De tests moeten over een langere tijd stabiel verlopen. Gebeurt de automatisering via de GUI van het projectproduct of andere vaste systeeminterfaces dan is dat meestal het geval. Moet ik de geautomatiseerde test echter na iedere verandering aanpassen, dan is automatisering veeleer niet lonend. Er zijn tests die ik alleen geautomatiseerd kan uitvoeren zoals bijvoorbeeld lasttests of test van componenten zonder GUI. Dan mag de test niet weggelaten worden maar moet juist automatisch draaien ook wanneer de bovengenoemde criteria misschien niet gelden. HOM/FHTeL Oplossingen voor het testen van objectgeoriënteerde software 14 maart /21

15 XP proces en proces stappen. En vergeet dit volgende niet. Test driven design Aannamen over kosten van veranderingen HOM/FHTeL Oplossingen voor het testen van objectgeoriënteerde software 14 maart /21

16 XP proces en proces stappen. En vergeet dit volgende niet. Test driven design Extreme programming is not yust programming I Planningsspel: Sterke en duurzame integratie van de opdrachtgever(s). Snel vastleggen van de omvang van de volgende versie. Dit houdt vaak het actualiseren van de planning in. Korte releasecycli: Het tijdsbestek tussen het onderkennen van een eis en de omzetting ervan moet zo kort mogelijk houden worden Metafoor: De communicatie en oriëntatie van het team gebeurt aan de hand van goed gekozen metaforen die de manier van functioneren van het systeem aanschouwelijk maken. HOM/FHTeL Oplossingen voor het testen van objectgeoriënteerde software 14 maart /21

17 XP proces en proces stappen. En vergeet dit volgende niet. Test driven design Extreme programming is not yust programming II Eenvoudig ontwerp: Om op ieder tijdstip en daarmee ook later in het projectverloop eenvoudig en daarmee voordelig veranderingen te kunnen doorvoeren, moet het gekozen design zo eenvoudig mogelijk gestructureerd zijn. Onnodige complexe structuren dienen vermeden te worden. Testen: De ontwikkelaars schrijven voortdurend en van begin af aan geautomatiseerde unit-tests. De klanten ontwikkelen op hun beurt de opleveringstests die tegelijkertijd ook als eis gelden. HOM/FHTeL Oplossingen voor het testen van objectgeoriënteerde software 14 maart /21

18 XP proces en proces stappen. En vergeet dit volgende niet. Test driven design Extreme programming is not yust programming III Refactoring: Op grond van eenvoudige designs en automatische unit-tests kunnen naar behoefte relatief eenvoudig en veilig designveranderingen plaatsvinden om tot een meer adequaat design te komen. Refactoring betekent dat geen gedragsveranderingen geprogrammeerd worden, maar alleen het design veranderd wordt om op deze nieuwe basis beter verder te kunnen ontwikkelen. Pair programming: De productcode wordt paargewijs geprogrammeerd. Er zitten dus altijd twee programmeurs aan de terminal, waarbij de ene codeert en de andere controleert. De beide rollen worden dan van tijd tot tijd verwisseld. HOM/FHTeL Oplossingen voor het testen van objectgeoriënteerde software 14 maart /21

19 XP proces en proces stappen. En vergeet dit volgende niet. Test driven design Extreme programming is not yust programming IV Collectief code-eigendom: Iedereen mag te allen tijde de hele code veranderen. Alle programmeurs dragen de verantwoordelijkheid voor de gehele code. Voortdurende integratie: Het systeem wordt gecompileerd, gelinkt en geïntegreerd zodra een taak uitgevoerd is, dus meerdere keren per dag. 40-uren-week: Overuren dienen vermeden te worden en worden niet langer dan een week gedaan Voortdurend, direct klantencontact: Er is minstens een vertegenwoordiger van de gebruiker resp. van de opdrachtgever permanent als aanspreekpartner voor het projectteam beschikbaar. Programmeerstandaards: De standaards dienen de communicatie via de code te vergemakkelijken en alle ontwikkelaars dienen zich eraan te houden. HOM/FHTeL Oplossingen voor het testen van objectgeoriënteerde software 14 maart /21

20 Test driven design XP proces en proces stappen. En vergeet dit volgende niet. Test driven design Klassiek Analyse Design Coördinatie Test test driven analyse testcases maken codering test refactoring HOM/FHTeL Oplossingen voor het testen van objectgeoriënteerde software 14 maart /21

21 Test driven design XP proces en proces stappen. En vergeet dit volgende niet. Test driven design HOM/FHTeL Oplossingen voor het testen van objectgeoriënteerde software 14 maart /21