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.