One of the things I learned during the AST course: “Black Box Testing – Foundations” is that we can not test everything, all the possible variations, all the possible inputs, all the possible paths in the code. etc. we have to test are just too many to execute even with the most sophisticated and powerful computers he have nowadays and if you add money and time to the equation this could be a task of epic proportions.
So we have to pick the test cases or test scenarios to execute that help us to find the most of the bugs. But how do we pick? For someone with experience in the product it would be easier than someone who is testing it for the first time but even if you have experience maybe you are testing a part of the product you never tested before.
I’m going through Gerald Weinberg’s “An Introduction to General Systems Thinking” and he writes about something called “The Square Law of Computation” which basically explains how systems are more complex as long as we keep adding elements to them but if we use the Mechanistic thinking we can reduce them for better understanding if we eliminate the parts which have no significant effect in the general behavior, so if we follow this concept in testing, we could prioritize our test scope in the elements which have the most of the effects/impact in the expectations of the stakeholders or final users
This sounds great but.. how do we know what are the elements which causes major impact?, well, we start doing our research, we can talk with developers about what functions or flows are more recurrent in the execution of the feature we are testing, what interfaces are more affected with the new implementation, what subsystem is mostly in charge of the logic and decisions.
Once we identify the most affected parts of the system we can take a look at the trouble report database to get information about the current state of this parts, are there many TR’s open in this subsystems? could some of them impact the part of the code that will be modified with the introduction of the new feature?
And finally we can look at the documentation and find the motivation of this change, is this a change requested by the customer? Is it fixing an problem they had? Is it introduced to be aligned with the standard?
All this could give us several good ideas on how to test the new feature just keep in mind that the mechanistic thinking is a tool to simplify systems in order to understand them better and we can use it to guide our research but keep in mind that there is a chance that we could disregard something in the system that actually has a big impact but we just don’t see it at the beginning of our research.