The Context Inflation

Forget everything you know about testing and when you do, try defining it from the scratch. No matter what, you will always end up enforcing your definitions with the words such as “Requirements”, “Verification”, and “Validation”. 

Thing is, we don’t have a way around it.

Testing embeds itself as an encapsulated activity. If we see testing in a three dimensional format, ideally it form the shape of a sphere and the core of this sphere will be always be Requirements.

For testers working with conventional mindsets of requirement analysis, test case formation, and execution of test cycles, placing the requirements within the center of the core works fine. It justifies their efforts and time – we cannot deny this, as most of the information solution industry works that way.

But the question is, to what extent we can rely on the requirements? For developers it will be a time eater if they are asked to go around the context and then start their development.

For testers, testing the software without adding the spice of context is a game half played.

The context changes everything here. Once the application is out from the developers’ domain and out in the open, the strong stimulus of User Experience, business rules, behavior, test results, and technology will change what the code is all about. Bugs are raised this way.

We need to grasp the reality that the software written perfectly on the basis of some written requirements is on the first foundation stone of the solution.

We must understand that the real users are not bounded to use these application in any form of “Best Practices”. They will do with it whatever they want to do, and they will complain.

We must also understand that the tools and technologies are there to support us when this inflation of context happens. It is a disruption which is mandatory. It will happen – we need to be ready.

No matter how many test cases we write in that limited time we have, we will never make sure of the coverage we need. This de facto effect of context inflation changes the game board rule.

The key thing here is to make something sturdy out of the first set of requirements. Something which is flexible enough to take on the pressure of inflation. Most of the software application fail just because of the stiffness in the requirement implementation at the start of the projects. Don’t be like that.

Once a good foundation is laid down, the changes in the designs are easier – your test cases should be flexible enough to take care of this effect. If you increase the number of cases you will be in trouble. So concentrate on Smoke and Sanity, and then go for the regression side.

Your test cycles should concentrate on the workable application – so let the happy test pass, remember, your first cycles should not put developers at unease.

Once everything is in the stable mode, move to the negative testing. This will address context inflations. This will also take care of the tacit requirements, the needs and wishes which the user never mentioned in the SRS.

Testers need to develop a POV (Point of view) of the application as a factory product, but is open to change as the user needs it to be.

I may write more on this.

Till then

Ciao

Arslan