Alternatives to Acceptance Testing
I like the goal of eliminating defects while you’re writing code rather than fix bugs later on.
When it comes to testing, my goal is to eliminate defects. At least the ones that matter. (Netscape 4.01 users, you’re on your own.) And I’d much rather prevent defects than find and fix them days or weeks later.
I think of defects as coming from four sources: programmer errors, design errors, requirements errors, and systemic errors. When trying to eliminate defects, I look for practices that address these four causes.
He lists some solid methods for preventing defects for each of these classes of errors.
Preventing programming errors is done with test-driven development; unit-tests, focused integration tests and end-to-end integration tests.
Preventing design errors is done by having a simple clean design, incrementally improving the design and architecture and constantly refactoring to ensure it continues to be clean.
Preventing requirements errors:
- a whole team is required, cross-functional and able to get what they need to finish the project
- customer examples, using multiple examples can help clarify the general idea of the feature to implement
- customer review, get the programmers to walk through the new functionality with customer, kinda like the client UAT (User Acceptance Tests) we do at work.
- push testers to help in the build process rather than relying on them after releases are made. They can work with the customer to figure out requirements or set up automated regression testing (most companies rely on manual regression testing which eats up a lot of time)
This whole article is very good and Mr Shore is an excellent writer. I’d recommend getting his book too, The Art of Agile Development.
Image may be NSFW.
Clik here to view.
Image may be NSFW.Clik here to view.
