Rainbows

In my thirty plus years of teaching, I used a lot of analogies to explain different ideas and concepts. By using an analogy, I hoped to explain a new and unknown idea in terms of things the students already knew. Like most teachers, I taught certain classes over and over (and over and over) again. That let me fine tune my presentations and analogies and focus on those that worked best.

For several years while I was in IBM Technical Education I taught courses on software testing. That didn’t stop when I moved on to a later stage in my career and I found myself in the front of a classroom or a TV camera teaching principles of testing right up until I retired.

An important concept in testing is the various levels. These are times or stages during the development process where testing occurs. (Of course you start the testing process at the beginning of the development cycle if you want to be most effective. But you can’t run (or execute) test cases until you have code to test.)

The very first phase of testing is most often called “Unit Testing” (or "Component Testing") and it is done to individual units or modules and most often executed by the original developer or "author." There are several phases following Unit Test with different names from "Function Test" to "Integration Test" and others. These tests are performed as the software parts are integrated to make the complete system.

This is most often followed by "System Test" as well as "Beta Test," "Acceptance Test" and other tests of the complete software running in a full operational environment. These levels of testing are most often performed by individuals with the "tester" job code and not by the code developers.

Each phase of testing has a certain purpose and motivation. These are discrete steps or phases, yet the overall purpose remained the same: to find bugs. So how to explain the concept of phases of testing … what was the same and what was different?

I used the rainbow as an analogy. First I’d ask how many colors in the rainbow? There are really two correct answers. Some will say “seven.”

Yes, there are seven: Red, Orange, Yellow, Green, Blue, Indigo, Violet. Sure, you can look at a rainbow and observe and name each color, but INDIGO?!? Where did that come from?

Simple, the ancients — who first recorded these colors — were superstitious and numerologists. They considered seven as a number representing completeness. (See the days of the week or the Bible’s Genesis account.) They added Indigo to the other common colors to reach the "magic" number seven. So, are there really seven?

Well no. Color is related to the frequency of light, and the rainbow shows all frequencies in the visible band from deepest red to the highest blue (which we call purple). So a more scientific answer is that the colors of the rainbow are a continuum of colors from infra-red to ultra-violet.

And that is true of testing too. It is a bit of continuous transition that we break into nameable parts or phases from Unit Test to System Test and many other names for specific purposed tests.

One of the best ways to explain the engineering concepts is through a model — another form of analogy. This diagram shows the connection between the software development phases or stages and the test phases. This picture shows the connection through planning, but there is also a connection between the phases via inspections. Unit Testers should inspect or review units of code and system testers should be involved in requirements design reviews.

Also the developers should be there at test plan and test design inspections. This process is an important part of an overall quality effort.

The V-diagram is applicable in all process models from waterfall to iterative and spiral to Agile. No matter what the development plan is, you have to have requirements and designs before you have code and integration, and you need code before you can run a test case. All development models include the same basic steps.

Depending on your organization, your education, and the type of industry you work in, these names may be different, but the concept is the same. It is the concepts that need to be focused on, not the terms.

So there you have a couple of analogies to assist you in understanding these fundamental process steps. If you aren’t a programmer or tester, then you may not know what I’m talking about. But, if you are a software developer, then these models, pictures, and analogies might help your understanding. It worked for a lot of students in my classes.