- Find out it was a mistake you made, help you isolate it, and fix it (or have a great test page for asking for help)
- Discover a true bug, and arm you with the perfect demo to present to the people responsible.
Reduced test cases are the absolute, no doubt about it, number one way to troubleshoot bugs. In fact, some people contribute to open source projects simply by turning bug reports into reduced test cases for more experienced developers to explore. Here is how you might get started creating one from your problems...
1. Make it static
If it's a front-end issue, make the page static instead of dynamically built from the server (like if you are using a CMS of some kind). That is, view the source on the problem page, copy and paste it into a new document, and start there with your reduced test case. Put that document into a new directory just for your test case.
2. Make it isolated
3. Reduce, reduce, reduce!
4. Document it
If there are bits in the code that you suspect may be the problem, put comments in the code there. Every single web language has some way to insert comments that don't affect the code.
5. Put it online
If you are working locally, put up your reduced test case online somewhere. I've seen people use the free Dropbox to host a quick example. This will make it easier for you to share the problem with others who may be able to help out.
But I don't know what the problem is! They need to see everything!
You do know what the problem is. It is whatever the problem is. Showing someone "everything" is often overwhelming to them and makes it harder for them to get their heads around. That's how I feel, anyway. If someone is asking for help and they paste 1000 lines of CSS code in the forums, my eyes usually glaze over and I just skip it. A reduced test case however, is often intriguing and begs to be looked at.
WebKit on Test Case Reduction
Know of any other good discussions on this topic? Let me know I'll link them up.
CodePen is a good app for creating reduced test cases.