Testen in de traditionele zin heeft z’n langste tijd wel gehad: specialistische testers die de software wel even komen doorzagen en goed zijn voor ruim 30% van het projectbudget lijken gaan het afleggen tegen inhoudsdeskundigen die veel minder testspecialist zijn, maar wel heel goed weten wat ze voor hun werk nodig hebben. Of tegen ontwikkelaars, die hun neus ophalen voor het schrijven van documentatie, maar vooral heel veel verstand hebben van code, services en frameworks en met het grootste gemak geautomatiseerde tests desnoods iedere milliseconde herhalen.
Er zouden toch manieren moeten zijn om de sterke kanten te verbinden en tegelijkertijd, door minder overhead, een forste testreductie te bewerkstelligen? Het zijn deze vraagstukken waar de testwijzer blog antwoorden op geeft.
Blog posts
- De testbasis is een klavertje vier: informatiebronnen om je testen op te baseren - In het softwaretestproces wordt het feitelijk gedrag van een systeem bij bepaalde invoer en bediening vergeleken met het gewenste gedrag van dat systeem. Verschillen in gedrag worden als bevinding gerapporteerd: "er is een verschil tussen mijn verwachting en wat het systeem doet". Sinds de beginjaren van TMap hebben testers zichzelf aangeleerd dat de kwaliteit van hun testen afhankelijk is van de kwaliteit van de documentatie: geen goede documentatie betekent geen goede testen. En dat is geen goede ontwikkeling geweest.