How can you reduce risk when implementing agile development in your SDLC?
A quick recap:
You probably see where we’re going with this: even if you have 100% code-coverage and a massive set of unit tests, these won't let you know that users and potential customers can’t find the "Buy Now" button, that your CSS layout explodes in a rotated iPad2, or that users expect the download link to download an image and not a word document. Does that mean you should pick black box testing only?
These two approaches are complementary: your software engineers should definitely be practicing good development habits with unit, integration, and regression tests. Black box testing isn’t a substitute for these. But having human testers doesn’t absolve your team from having to write their own tests either.
In the grand scheme of things, black box testing is often neglected. Product managers are under pressure to ship fast and ship often. Programmers make the mistake of thinking: “All my unit tests are green, this software must do what it should.”
In the end, only real, unbiased testers can tell you if your software is good or not. If you want to save time, effort, and money - make sure both black box and white box testing are integral parts of your development process.