Tijdens de bouw en zeker tijdens het latere onderhoud van een applicatie worden grotere en kleinere veranderingen aangebracht. Omdat er ondanks alle inspanningen om via 'interfaces' te werken toch allerlei afhankelijkheden bestaan is de kans groot dat op een overwachte plaats in de applicatie fouten ontstaan. Om die meteen op te sporen worden alle tests bij iedere nieuwe build van de applicatie automatisch doorlopen. Het hulpmiddel hierbij in de Java wereld is JUnit. In de termen van Prince2 moet de testbibliotheek dan ook als een verplichte 'deliverable' worden gezien. JUnit en haar pendant in de .NET wereld zijn vooral geschikt om te controleren of de applicatie technisch in orde is en niet of de gewenste functionaliteit wordt geleverd. Voor het testen in het algemeen is de lijdraad in Nederland TMap dat breder van opzet is. Eind 2006 is een nieuwe druk met de naam TMap Next uitgekomen. Deze versie houdt rekening met de veranderde praktijk maar kiest niet noodzakelijk voor een moderne aanpak. De oude procesmethoden zoals de watervalmethode blijft toepasbaar.
Specification by Example beschrijft een moderne opzet om functionele specificaties op te stellen, automatisch te laten verifiëren en als levende documentatie te gebruiken. Waar Junit tests dienen voor het vertrouwen van de ontwikkelaars bij het veranderen van de code dienen deze tests om zeker te stellen dat de applicatie aan de eisen van de business (blijft) voldoen.
"Testing is not about writing tests. It’s about writing testable code." is het onderwerp van deze presentatie van een medewerker van Google. Testen vooraf dwingt de ontwikkelaar tot een betere structuur van de code.
Sinds 2000 wordt een nieuwe trend gemeengoed. Ontwikkel eerst een testbare module, definieer en doorloop alle tests, en voeg de code dan pas toe aan het project.
Het in samenwerking met de business formuleren van acceptatietests is de manier om functionele specificaties in een agile omgeving vast te stellen en te bewaken.