Seeing a test-process as a test-system

The term process is something that can be used in factory-like organizations. What we fail to see is that software development is not a factory-like activity. It is a service oriented engineering activity.
What will happen if we stop looking at the test process as a process and start looking at it as a system?
Let's take software testing process diagram. In my case I made a diagram loosely based on TMAp (Test Management Approach).
I've taken that process diagram and changed it to a system model.
I've used simple rules.
Black arrows are a positive feed. You can see it as:
If A gets better, than B gets better too.
If A gets worse, than B gets worst too.

Red dotted arrows are negative feed. You can see it as:
If A gets better, then B gets worse.
If A gets worse, than B gets better.

What is that model telling us?
well…follow the rules:

If the assignment is better, the planning gets better too.
If the planning is better, the preparation gets better too.
If preparation is better, the test specifications are getting better too.
If the specifications are better, the test execution is getting better too.
If the test execution is better the #issues decreases. (is not increasing that much)

If there is an error/fault/bug in the assignment, the planning gets worse, and the preparation gets worse, and the specifications are getting worse, etc.

If there is an error/fault/bug in the object under test, the object under test is getting worse, the test execution is getting worse, the #issues increases, test rapports are getting worse, and the decision making is also getting worse, etc.

With the number of issues increasing the need to fix is also increasing.
The fix in this system has a feedback function.
What we can learn from the control theory is that feedback function can help the systems to regulate. The danger is that if the system is not properly adjusted to the feedback, the whole system can get instable with eventual collapse as the end.
One of the goals of testing is to find errors/faults/bugs.
Each found fault can increase the need to fix which, if not properly adjusted (controlled), it can interrupt the balance of the testing system to the point of possible total collapse.
I will use this model to explain why is testing always taking so much time.
Is testing is a self-exterminating occupation?

No comments: