that it is something developers should learn to do well so we testers can concentrate on more important and complex behavioral tests. That said, however, don't look a gift horse in the mouth. If you have access to the source code, use it.
But, use it as a tester should, not as a developer would. My interest in source code is many fold and too involved to discuss all the issues here. But I think there is much to be learned from reading the source. Top of my list is looking for error-handling code and the dialog boxes that will indicate to us that the error code is executing. Error handlers are the hardest code to see or get to from the user interface. Understanding what error handlers have been written and what inputs it takes to trigger them is time well spent.
Indeed, there are many such clues we can glean from the source that give us insight into tests that need to be performed. We should not be shy about asking for and using the source code.
So that's the commandments. By the way, there is a reason there are nine instead of ten. We might assume that just because they are "commandments," there have to be ten of them. Since we know the assumption to be true (because that's the nature of an assumption) then we convince ourselves that there is no need to ever bother checking whether the assumption may become false.
Assumptions are a very bad thing for software testers. Assumptions can reduce productivity and undermine an otherwise good project. Assumptions can even undermine a career. Good testers can never assume anything. In fact, the reason we are called testers is that we test assumptions for a living. No assumption is true until we test and verify that it is true. No assumption is false until we test that it is false.
Any tester who assumes anything about anything should consider taking up development for a career. After all, what tester hasn't heard a developer say "Well, we assumed the user would never do that!" Assumptions must always be tested. I once heard a test consultant give the advice: "Expect the unexpected." With this I disagree; instead, expect nothing, only then will you find what you seek.
I hope you have enjoyed this series as much as I have. Bon Appetite!
- Massive scale random testing is a sub discipline of model-based testing. Learn more about both at www.model-based-testing.org.
- Test Oracles are elusive, but there is help out there. My very favorite article on the subject is from long time testing guru Elaine Weyuker. The paper is called "On Testing Non-testable Programs", The Computer Journal, Vol. 25, No. 4 (1982), pp. 465- 470. Sure it's an old paper, but I consider it a classic.
- Random Testing and 'App Compat': The Ten Commandments of Software Testing, Part 1
- Oracles, Failures, Models, and Sins: The Ten Commandments of Software Testing, Part 2