Framework for Integrated Test
Het Framework for Integrated Test (of FIT) is een concept in het ontwikkelen en testen van computerprogramma's ontwikkeld door Ward Cunningham, Rick Mugridge en andere medewerkers van het Amerikaanse consultantcy-bedrijf Object Mentor.
Het basisconcept van FIT is dat het ontwikkelen en testen van een computerprogramma binnen de software engineering voornamelijk afhankelijk is van de mate van communicatie binnen de ontwikkelgroep voor het programma. Specifiek moet er intensieve communicatie plaatsvinden tussen alle verschillende actoren binnen een softwareproject, ongeacht hun rol.
Een groot probleem hierbij is echter dat er een aantal verschillende rollen zijn binnen ieder softwareproject, die allemaal anders tegen het project aankijken. De FIT-groep spreekt in principe van drie rollen (de klanten, de testers en de programmeurs). Al deze rollen hebben hun eigen kijk op het project, een eigen belang bij het succesvol afronden van het project. Maar omdat ze allemaal een eigen kijk hebben op het leven en het project, is het moeilijk om een diepgaande communicatie tot stand te brengen tussen actoren met een verschillende rol. Een "klant" bijvoorbeeld heeft een functionele kijk op het project, weet waar het project past in het zakelijke landschap, wat er functioneel van het op te leveren programma verwacht wordt. Een "programmeur" daarentegen kijkt er op een technische manier tegenaan, weet hoe de software gebouwd wordt, welke bibliotheken gebruikt worden, enzovoorts.
FIT is bedoeld als softwaretool om communicatie tussen al deze rollen tot stand te brengen.
Theorie
De theorie achter FIT borduurt voort op de theorie achter domein-gestuurd ontwerp, zoals beschreven in Domain-Driven Design van Eric Evans. Een van de belangrijkste ideeën die gepresenteerd worden in dat boek is dat een softwareproject alleen kans van slagen heeft als er vloeiende communicatie is tussen alle belanghebbenden (en:stakeholders) bij het project. De belanghebbenden worden in hun communicatie echter gehinderd door het feit dat zij allemaal vanuit een eigen perspectief tegen het project aankijken en een eigen soort belang bij het project hebben; ze spelen allemaal een eigen rol bij het project. Dientengevolge spreekt iedere belanghebbende ook een eigen taal, een eigen jargon dat is toegesneden op zijn perspectief op het project.
Domein-gestuurd ontwerpen is gebaseerd op het idee dat belanghebbenden in iedere rol in het project samen moeten komen tot een gemeenschappelijke taal waarin ze kunnen spreken over het project. Door het opzetten van een gemeenschappelijke taal kunnen alle actoren (medewerkers) in het project samen spreken over het project op een manier die iedereen begrijpt en ook voor zich kan doorvertalen naar het eigen jargon om te zien of wat er gezegd wordt ook echt klopt.
FIT is een versimpelde uitvoering van dit proces, gespecialiseerd op het opbouwen en testen van de op te leveren software (domein-gestuurd ontwerpen heeft ook een weerslag buiten de software en beïnvloedt de hele projectstructuur, het project management, enzovoorts). FIT forceert een gemeenschappelijke taal die belanghebbenden van iedere rol kunnen gebruiken om samen te bepalen wanneer de software naar behoren werkt en wanneer niet.
Rollen
De bedenkers van FIT onderscheiden zelf drie rollen (Klant, Tester en Programmeur) binnen het softwareproject die van belang zijn voor de op te leveren software. FIT is echter gebaseerd op Extreme Programming en andere Agile methoden en laat het softwareproject dus vrij om de definities aan te passen.
- Klant
- De Klant is de rol binnen het project die sturend is voor het project. De Klant is er de reden van dat het project gestart is, de Klant is degene die het project bekostigt (en die dus verwachtingen uit mag spreken ten aanzien van de software) en de Klant is ook nog eens degene die functioneel weet wat de software moet doen (dat wil zeggen: hij weet welke functies de eindgebruikers van de software zullen verwachten). En uiteraard heeft de klant ook kennis van de niet-functionele eisen die aan de software gesteld worden, zoals eisen aan "performance" (hoe de Klant dat ook definieert), systeemomgeving, enzovoorts.
- Tester
- De Tester is de rol binnen het project die verantwoordelijk is om erop toe te zien dat de opgeleverde software voldoet aan de eisen van de Klant. De Tester heeft daartoe zowel functioneel inzicht (hij is bekend met het probleemdomein van de software) als technisch inzicht (hij weet meer over het functioneren van de software, weet naast wat het doet ook hoe hij de software moet bedienen, of er praktische problemen of limieten aan de software zijn, et cetera). De Tester is bijvoorbeeld in staat om specifieke instanties en voorbeelden van de functionele eisen van de Klant op te leveren; als de Klant zegt "de software moet rente berekenen", dan kan de Tester dat vertalen in "als ik er dit en dit getal in stop, moet er dit getal uitkomen".
- Programmeur
- De Programmeur is de rol beinnen het project die verantwoordelijk is voor het echte bouwen van de software aan de hand van een specificatie. De Programmeur heeft voornamelijk technische kennis van de software: hij weet hoe de code gebouwd is, welke datastructuren er gebruikt zijn, welke API's er gebruikt zijn, dat soort dingen. De Programmeur bouwt gaandeweg uiteraard enige functionele kennis op van de software, maar heeft over het algemeen geen overzicht over het hele systeem of hoe zijn software precies past in het systeemlandschap.
Gemeenschappelijke taal
FIT voert een gemeenschappelijke taal voor alle rollen en belanghebbenden in om te gebruiken bij het testen van software. Om dit mogelijk te maken en tegelijkertijd simpel te houden, beschouwt FIT een te testen stuk software als een black box waarbij het testteam alleen controle heeft over de in- en uitvoer van de software. Het FIT-raamwerk bestaat uit een redelijk simpel mechanisme waarmee de Klant, de Tester en de Programmeur samen en interactief een batterij tests voor software kunnen opstellen en uitvoeren.
Een test van een stuk software in het FIT-raamwerk bestaat uit een tabel waarin de invoer voor een test is opgenomen en daarbij de verwachte uitvoer. Het raamwerk zelf bestaat uit software die de tabel inleest, de invoerwaarden eruit haalt en de te testen software afspeelt met die invoer. De eigenlijke uitvoer wordt dan vergeleken met de verwachte waarden uit de tabel. Tenslotte geeft het raamwerk de oorspronkelijke tabel opnieuw weer, aangevuld met enige kleurcodering: als de verwachte waarde overeenkomt met het echte resultaat wordt de verwachte waarde in het groen weergegeven, anders in het rood. Het achterliggende idee is dat de taal van in- en uitvoerparen en groen of rood simpel genoeg is dat actoren in iedere rol die taal kunnen volgen en spreken.
Een belangrijk onderdeel van het FIT-raamwerk is de mogelijkheid voor alle rollen om snel tests op te kunnen stellen, uit te kunnen voeren, aan te kunnen passen of in te kunnen zien. Dat vereist een stuk stuk software dat het makkelijk maakt voor alle soorten actoren om tabellen op te stellen en te wijzigen en ook om de tests uit te voeren. Dat zijn zwaardere eisen dan in eerste instantie lijkt; bedenk maar eens dat de meeste mensen het al moeilijk vinden om in HTML een tabel op te bouwen. Daarnaast moet het natuurlijk ook niet alleen mogelijk zijn om test op te stellen en te wijzigen, een nuttig tool moet ook veranderingen terug kunnen draaien (want fouten komen zeker voor). Opgestelde tests moeten opgeslagen kunnen worden en makkelijk teruggevonden kunnen worden (een tool waarin je 150 testtabellen inklopt die weg zijn als je de computer uitzet, wordt gewoon niet gebruikt). Het liefst moet het mogelijk zijn om tests te kopiëren, om andere tests te maken die lijken op de gekopieerde tests. En ook de mogelijkheid om toelichtende tekst toe te voegen aan de testtabel is zeker wenselijk. En ook het testen zelf moet makkelijk zijn: het moet net zo makkelijk zijn om een batterij van 1000 tests uit te voeren als het is om een enkele test uit te voeren. Of een selectie uit die 1000 tests.
Het zal duidelijk zijn dat gebruiksgemak bij FIT de eerste prioriteit heeft: het bewerkings- en testtool moet laagdrempelig zijn en de gebruiker in alles ondersteunen. Het FIT-team van Object Mentor raadt makers van FIT-implementaties erg aan om als bewerkingstool een wikitool te gebruiken en dat om te bouwen zodat de tests direct vanuit de Wiki uitgevoerd kunnen worden.