Imagine a project, in which code quality is not the biggest priority. What is then, you’d ask. The top five are usually:
The first problem
As I wrote in my previous post, all of the above come first until the first major system malfunction. What comes next: revenue losses, reputation losses, long outages, and significant decrease of trust.
At this point companies tend to stop, look around and come up with this brilliant idea: “Let’s hire a Tester“. When the concept itself it’s not so bad, there is usually more to be fixed than just a staffing issue.
The problem is, that the companies, who have never paid much attention to their product quality, focusing on new feature releases, assume that hiring one person will solve all the quality problems in the organization.
My project experience proves that a single Tester will not leverage the quality of your product.
How to produce good software
Let’s stop here for a moment. What is a software product? I’m generalizing here: – it’s a concept, the code, and a blend of marketing. I assume, that when a company wishes to advertise and sell the product, this product needs to be good. Not only well promoted but also based on some good coding.
The code that is considered good when:
- Does what it should.
- Follows a consistent style.
- It is easy to understand.
- Has been well-documented.
- Can be tested.
As you can see, the act of testing is just a piece of the puzzle.
Good coding makes a good app. That’s why the companies hire best Software Engineers, pay them good salaries and benefit from their knowledge.
It doesn’t mean that when the company empoys great Developers – your project doeasn’t need Testers. It probably does.
The biggest blocker for project quality is not lack of Testers. It’s the unwillingness of learning. Continuous learning requires feedback loops, where testing plays a key part of it.
A Tester, Quality Engineer, Quality Assurance Specialist, or however you name the role can point you in the right direction. Emphasize the flaws in the process, argue with bad practices and embrace some positive changes. Unfortunately, it will only happen when you allow the quality into the project. When you employ a single Junior Tester to save money and count on the spectacular results, you may be surprised.
I like this saying: “if good testing is expensive – try bad testing”.
I do not think of Tester’s salary (which, in my opinion, shall not differ from the Developer’s one) only. Good quality is expensive because it takes time. Good software quality helps the project to run in the correct direction, and avoid major system malfunctions, but it is expensive.
When quality goes first:
- developers spend more time on coding because they discuss potential good solutions – they don’t chase who pushes code first into production without testing
- there are Unit Tests beside the application code
- there is an infrastructure that allows testing before pushing to production
- there is room for improvement
- developers pair to catch the obvious mistakes on the fly and learn from one another
- TEAMS ESTIMATE tasks, taking quality and risks into account
- potential risks in the systems ARE MINIMIZED – not left alone
and finally – the application is tested – not only by one automated or manual test – but by the set of different functional and non-functional test scenarios. The tests are regulrarly reviewed, adjusted, and observed.
Sounds idyllic – right?
So when I hear “let’s hire a Tester to improve the quality of our product” – I do understand and don’t understand at the same time.
I shall repeat over and over again – quality is the whole team’s responsibility.
Quality takes time – AND THAT’S OK.