There are lessons to be learned from failure, if only we are willing to find an examine them. This is a guide on how to fail at testing.
Software testing is used everywhere and its importance is becoming more required to ensure released products are working as expected. More and more companies are coming to understand the benefits that can be derived from testing, including high-performing systems, rapid product development, better use of resources and many more. Statisa shows the proportion of IT budget that is going into testing is increasing every year, from 18% in 2012 to of 26% in 2017.
In the neverending quest for improvement, the use of different techniques and experience in work plays a crucial role in becoming more effective. Improvement is a double-eged sword, consisting of positive and negative consequences. We must understand that with our failures, we gain wisdom by finding out what works and what does not.
Why bother with failure? There are specific lessons to be learned and the information used will be valuable data for future projects. We don’t want what’s happened in the past to happen in the future, that would be insanity. How can we expect different results when we keep doing the same thing?
Ignore your stakeholders
One of the best ways to guarantee failure is to manage it without considering your stakeholders, including those project stakeholders who are actually going to use the features that your team will build. Stakeholders you need to consider include clients, the marketing department, sales department, management, and the team building the product.
Consider the case my team has experienced before. A new API integration was required to pull certain data that is needed by the clients. The ticket was spec’d out, added to the sprint and the developer was given the job to do. The ticket made sense and it was all fine and dandy.
When it got to the testing phase of the software development cycle. The piece of functionality that was built was the incorrect one to be built. With further investigation post-project, we found that yes, there was communication between the product manager and the client team as to what should be built. Nonetheless, there was not a form of verification to make sure that the specification drawn up was the one the team needed.
This is one example of the problems that can occur when projects forget the true users or assume they know more than the stakeholder groups. One clear message that come through for every single project is prior to the “let’s build this” decision, one must consider the importance of verification of requirements with the people who are actually going to use that feature.
Leave all the testing at the end
New features means new risks. Sometimes, there’s a lot of resources allocated to the development stage and once that’s done, the allure of releasing as soon as it’s possible is almost unquenchable. This results in companies to cut corners on testing, perform more risk-based testing, and make product quality trade-offs. In the end, some of these decisions come back to haunt the firm’s decision makers, sometimes with tragic results of a user finding a critical function not working.
Take the Tacoma Narrows Bridge, which employed a well-understood technology with unique special characteristics built over a natural wind tunnel site. The result was a catastrophic failure, the whole project was a bust.
This new functionality you’re building may offer a leg-up against the competition. Unfortunately, in the rush to push it as soon as possible, there is a likelihood of inadequate testing that can result in a disaster. As a tester, you need to let your stakeholders know the necessary items that require testing to ensure that the product will perform as expected.
When a project is developed too rapidly, to the point which there are potential questions regarding its performance, it poses a threat to society and hence cannot be considered a quality offering - Genichi Taguchi
Never conduct post project reviews
Your project ran smoothly, the process went well, no extra time was required on the project. Hooray! What can we possibly learn from a project that went so well? When there are no lessons to be learned after a project, there is something wrong. Maybe there was a slight hiccup on the project that wasn’t reported or the team was required to work overtime and this information was quietly swept under the rug. Is there never really learning in a project?
In a project, there is always learning to be had. Mistakes are a natural side of many projects and just moving on from a project can sound appealing, However, I disagree with this attitude. There might be a time when certain mock-ups or requirements were not finalised for the developers and they started developing, did you mention this?
Great team members are the ones who can walk the team through failure of the a process to see where the wheels fell off the cart. They do not accuse, they offer solutions on how things can never happen again.
Consider this: Ignore everything you’ve learned in past testing and treat each situation as a challenge you’ve not had before. The results are simple, you will see more failures and they will happen again and again.
Make sure testing is ran by a non-tester
Projects, if left to their own devices, tend to be chaotic and disordered rather than running logically and realistically. In the case of a testing project ran by a non-tester to keep the testing on track, most projects begin to experience the hole of indecisiveness and aimlessness. In the end, resources and time are wasted and productivity plummets, all because there is no tester.
The key is the tester’s perspective. This is the person who makes the project succeed by knowing what to test, negotiating resources with stakeholders, giving information to stakeholders on the status of the project, being the light headlights of the project, and keeping the mission close at hand: completing the project successfully.
The tester’s role in a successful project is always visible, they talked to the stakeholders, they questioned the requirements, they find issues quickly. In the opposite way, when projects fail, the tester was invisible to the team members.
In the end, what conclusions can we draw from these cases on how to make sure testing fails? Failure is another product of every project, often involving forcing the release of a product as soon as possible to get a leg-up and ignoring the project environment and how they will be affected by the release. The second is that past failure or ‘success’ should encourage us to gain wisdom to push onto more successful projects in the future.
How to fail at testing?
- Ignore the project environment and its stakeholders
- Leave all the testing at the end
- Never conduct post project reviews
- Make sure testing is ran by a non-tester