One of the biggest misconceptions that people have about testing is that Software QA is all about hiring testers. As always, with most processes that look simple from outside, testing a software and ensuring quality is not as simple as it looks.
In this article we’ll outline some of the ways in which teams and product managers misunderstand testing and implement the process wrongly resulting in more headaches than effective delivery, along with suggestions on how to work more effectively.
Objective of testing
FIrst things first, lets define what we want to get out of testing. We want Software QA to finally end in
- Better software quality
- Better software reliability across releases
- Improved developer productivity
Here are some of the ways in which things could end up being implemented wrongly
1. Trying to fix all bugs
This one really hurts you software development process. So first things first, lets clear up one big confusion about this. There is no software in the world that does not have bugs. Its simply impossible to achieve a bug-free software. Its the kind of stuff that rookie product managers get obsessed about until reality hits them hard on the head. Don’t try to fix all the bugs, just fix the ones that prevent customers from achieving what they need to from your software. Leave perfection for days when there are truly less important things to achieve, which, by the way, should ideally be never.
2. Testing insignificant things
Pragmatism is the thing that makes testing effective. You want to ensure that you test just enough – not more, not less. Instead, what you’ll end up doing is reading about all the different kinds of testing, figuring out where each one fits into your releases, and then you’ll try to integrate all of this into your development process. Result? Your testing effort becomes too large and cumbersome, and worse, in many cases it gets slower than development. Before you know it, you’ll end up throwing out the whole concept. Instead of going through this journey, save yourself the effort, and start with the most critical functionality, defining simple ways to ensure that it doesn’t break, then work your way towards smaller, less important items, stopping at the point where testing becomes cumbersome.
Another problem you’ll often run into is that with frequently changing software, tests need to be changed too. The best way to deal with this beast is to ensure that you only do a broad test of the resulting expected functionality and not worry about the smaller details. That way, whats expected of the product will always be delivered, while the internals are allowed to change without affecting your tests.
Sometimes it just gets to you – you feel really irritated that your developers are delivering such lousy software and you just pile all the bugs on them. What you’re ending up doing is just looking inhumane, and what the developers will end up doing is start covering up issues to deliver features that look great on the surface to you, but have deep issues on the inside, which leads to long term trouble. Solution: give developers their space, they really do need to think things through before developing effective solutions. Pushing them hard will create negative impact down the road.
We’ve all been there. There’s really no time, and we have to get this fancy new feature out ASAP. But, take a deep breath, and save yourself the rush. A hastily delivered feature is guaranteed to lack quality. Not testing it is worse than testing your software in all other circumstances. The whole point of testing is to ensure that you don’t screw up when you release software. When you break that rule, you end up breaking the process itself.
Second problem, you’ll also end up having to deal with a badly written feature in production, thats technical debt, and that won’t go away so easily.
Take your time, breathe, test and release software, and work with your management to help them understand that this is a good move in the long run.
Writing very long and descriptive documents make it very hard for a fast-paced team to focus on and work effectively with. In this fast-paced world of hours, this usually just results in a pile of documentation thats left collecting dust.
Keep documentation brief, concise and to the point. This helps developers write great software, and testers understand what to test better. Save their time, and they’ll save yours.
6. Trying to build your own testing framework
Don’t even try. Plain and simple. Many times teams will crib about testing software out there not being good enough, and that to really do it well, a framework needs to be created. Trust me, this will take a very, very long time to implement correctly. Don’t fall for it. Avoid it as much as possible. Your teams should be focussed on delivering business value, not creaating a test framework(unless thats your business).
7. Not covering your critical use-cases in tests
If you approach testing by creating a laundry list of modules and then working through them, you’ll need a lot of effort before your testing becomes effective. Try not to do this, instead, prioritize your functionality by criticality, then start from the top and work your way to the bottom. This way you end up with effective testing for your product very quickly.
8. Hiring testers at the wrong time
When is the right time to hire testers? Hint: Not when you desperately need them. Plan ahead, and get your testers in early, especially the initial testers since you don’t yet have a process for testing your software.
Get your QA process in order well before you scale, and once you get it right, then start hiring testers as quickly as you need them.
9. Using testers as end users
Don’t just throw software at testers and ask them to find issues. Tell them about whats changed, what features you’ve added and what impacts you think the updates may have. Testing the whole product involves far more effort than testing a specific feature or update. Also, new functionality is most likely to be missed since your testers are familiar with your product and are used to its patterns of usage. Focussed testing will yield far better results than spray-and-pray techniques. Ensure that you talk about dependencies too. Third party tools that have changed etc.
10. Poor team spirit
The wrong culture to work towards is that “developers make features, and testers find issues with them”. Lots of product managers pit the developers against the testers. This just ends up creating a war, and in a war people like to win, not learn. Build consensus between your dev and testing teams right from the beginning and ensure that they work together to release great software.Thats the real win. Bugs should help developers learn how to code better, and testers should learn standards that result in great software.