RBCS COVID-19 response: All of our public training courses through May will be run virtually (view details).
The following is an excerpt from Chapter 2 of the new edition of Advanced Software Testing: Volume 3, by Jamie Mitchell and Rex Black. Jamie is the primary author of the material in this chapter.
Structure-based testing uses the internal structure of the system as a test basis for deriving dynamic test cases. In other words, we are going to use information about how the system is designed and built to derive our tests.
The question that should come to mind is why. We have all kinds of specification-based (black-box) testing methods to choose from. Why do we need more? We don’t have time or resources to spare for extra testing, do we?
Well, consider a world-class, outstanding system test team using all black-box and experience-based techniques. Suppose they go through all of their testing, using decision tables, state-based tests, boundary analysis, and equivalence classes. They do exploratory and attack-based testing and error guessing and use checklist-based methods. After all that, have they done enough testing? Perhaps for some. But research has shown, that even with all of that testing, and all of that effort, they may have missed a few things.
There is a really good possibility that as much as 70 percent of all of the code that makes up the system might never have been executed once! Not once!
How can that be? Well, a good system is going to have a lot of code that is only there to handle the unusual, exceptional conditions that may occur. The happy path is often fairly straightforward to build—and test. And, if every user were an expert, and no one ever made mistakes, and everyone followed the happy path without deviation, we would not need to worry so much about testing the rest. If systems did not sometimes go down, and networks sometimes fail, and databases get busy and stuff didn’t happen...
Read this article → (PDF 495 kB)
Category: Test Design