In most software development initiatives, the general view is that the testing component is the biggest bottleneck that causes the most frustration throughout the entire process. For decades the testing component in software delivery has the spotlight on it because of the importance. That light is not for good reasons most of the time.
In a waterfall development cycle, testing is the last thing done before an organization delivers something to customers. Many things can happen beforehand that shorten the planned time before providing one line of code to the test team. Leadership looks back on these delays as the focus is why testing takes so long.
In an agile framework, things can get dicey as more discipline throughout the team is needed to complete changes at the end of the iteration. If not handled, the bottleneck is even more noticeable and causes issues with stakeholders to think, “this agile stuff doesn’t work.”
In the end, software testing teams get the brunt of the negative feedback. Is there something that teams could be doing to make things better? Of course, there is. Most teams don’t because it is difficult to recognize, change and continue to improve. The culprit? “It is always done this way.”
The main issue that causes delays is over-testing. There are cases where a simple change could end up with hundreds of test cases due to using a broad range of variables that, if a developer wrote the difference in that fashion, a plate of spaghetti would look more organized. The reason? Testers should take the requirements more literally and work with developers’ thoughts and designs to create the change.
Here is a real-life example:
The project was to change the first and last name in a file going to a third party. The file already exists. Here are the particulars:
The file already has a first and last name field, and those fields’ parameters are not changing.
Currently, the population of the fields are from one of two areas: Legal Name and Preferred Name. The Parameters for the allowed content between the two are the same.
The change is to only use the Legal Name for populating the file.
It is to be used for all accounts: Individual, Joint, and Business.
The test case generation from the test team and execution for this change was over 350. The reason for this high number? The test team looked at every account type, with every variation of name location and name preference. What the test team needs to understand to help efficiently write practical test cases is the setup of the code and backend system architecture.
To start asking questions to clarify some assumptions would go a long way.
Does the code care about the account types? This question would create a conversation on how the development team designs the code. There they would find that the module to pull the names is in one call. Regardless of account type, this is the one module that pulls names from the database.
Another thing that could have identified a more efficient number of test cases or narrowed down the number to something manageable while exercising the code was to use orthogonal arrays. Doing an exercise to identify the different variations can eliminate duplication.
During a Root Cause Analysis exercise and using an array, the main discovery was that an adequate number of test cases to exercise the code is 18 test cases. A drastic reduction of almost 95% with a potential savings of a month in testing.
There are plenty of early studies, books and articles that go into detail on when teams work together from the start of an initiative to understand what it is and the planned build; the quality of the product is higher, along with the speed in which the team can deliver. As you read this, you may think this is a “Shift Left” type of work. Here is a secret: “Shift left” is basic Quality Assurance and testing thinking decades older than the introduction of the term.
It is all about communication and collaboration. Regardless of the framework model for software delivery, without a proper collaborative environment where assumptions are brought to everyone’s attention early to be confirmed or disproved, over-testing will continue to create frustration for everyone involved.
