There is one thing in software development that any developer should remember at all times: test, retest and test again. Any true Agile project revolves around testing. Test your code, screens, databases and test whether your user stories actually work. Nothing is left to chance and testing is done before everything else and after your done and your code will undergo regression testing when you’re long gone. Pretty obvious, you might say, but some parts of testing are more obvious than others. Unit tests are pretty much covered, there are dozens of tools and frameworks for that, the same goes for screen testing. But one thing that still feels like new ground is functional testing (or acceptance testing).
In Agile projects there are a two constraints that apply to the ‘traditional’ way acceptance tests are performed: test first and agile (flexible) test cases. When working with dedicated testers, the developers need to work together with them as a single team. Using the ‘test-first’ approach, you need the input from the tester before you can start coding, otherwise you won’t know when your work does what it needs to. One other problem that both developers and testers face is responding to changes. When the customer wants a new feature, you can’t reply: “It was never build to do that!”. We’re agile, so we’ll refactor the code if needed. Changes also apply to tests, requirements change and the software changes (database changes, user interface changes, etc.). So the tester needs to be able to deal with those changes.
There are a few things we can tackle. The magic word here is ‘Fitnesse’. Fitnesse allows you to combine test case specification and execution on one page. This allows for very smart test cases, you could have something as simple as:
My test data:
Read more →