The 8 Most Common Crimes Against Software Quality

Bad software quality leads users to frustration, rage, disappointment. They uninstall the application or change their software provider. It also despairs developers, making them to lose interest in the product they are building. They can get outraged when having to work on certain parts of the code, which are not very testable or not even tested at all.

Software development industry has discussed ad nauseam about development cycles, model to follow, processes, etc. However, despite all this discussion we can see quite often situations where quality is forgotten. Specially in startups which are measuring with care if their product will be the right one or if they need to pivot already.

1.- Not having engineers focused on quality

If nobody is focused on software quality, taking care of quality becomes a shared responsibility, making it be reduced and ignored.

The idea is, developers coding without a security harness are responsible of their code and therefore it has better quality. I guess that behind this statement it is implicit that they have to add automated tests to check their code. Making them a kind of part-time test automators.

However, a developer is always responsible for his code whether there are quality engineers or not. Having them would only benefit his work.

Software developers don’t test their code as a QA engineer does. Like all activities, testing skills improve with experience. Their own tests wouldn’t be so evil, they would be afraid of breaking their work. Happens the same with automation of most complex tests. Software test automation requires time and training. Besides unit tests, a developer would have to invest a lot of time to make automated tests. All that time invested developers wouldn’t be focused on learning about development or on improving directly the product.

Hire QA engineers or see your ships wreck



2.- Postpone hiring quality engineers because the project has just started

Not having QA engineers in the early development phases can lead to hardly automatable  products. They can make software architecture mistakes being a burden for the project indefinitely. Actually it is at the beginning of the projects where a QA engineer can prevent against incoming problems. Trying to minimize the matrix of pain, chasing that every part of the system were automatable and improving all development processes in general.

Is it really necessary to create minimum viable products with a massive technical debt?


3.- Not preparing automated tests

If tests are not automated, they would have to be run manually or assume that the published product will be a can of worms. This can be achieved hiring an army of manual software testers to verify every part of the system in every new release. Of course this army of testers would get frustrated after passing so many regression test plans.

Preparing automated tests is an investment in the project. They are a mechanism to monitor the system under test. Being able to have everything automatically tested under control. It also is a source of documentation for the project as they describe use case scenarios of the product.

Test automation is the key to accomplish continuous delivery, if we want to follow that methodology.

Having an automated test suite is the best regression test plan for a product. Allowing developers to refactor code without fear to break anything, contributing to reduce technical debt of projects.

No automated tests


4.- Eliminate manual testing

On the other side of the coin we find the crime about removing all manual testing expecting that automation covers everything. Automated testing has many many benefits, but it won’t have common sense. Only a human can understand users. User experience is something which machines will have troubles testing (at least in the coming years).

Manual testing should be exploratory, analyzing the tested app, having in mind the different use cases which customers may have.

These tests allow us to have an extensive knowledge about the product. They help to suggest enhancement ideas requiring much creativity. While more complete is the automated test suite, more creativity could be used for this kind of testing, “breaking” the product in diverse ways, researching and better analyzing the results.

A trending in companies with a high number of users, is to use an specific percentage of users to get real feedback about the behaviour of the new product version or feature. This is leaving this kind of testing to final users, who will see the app before being really finished, making them guinea pigs. This model can only work if you have lots of users and if you don’t care if some find usability issues. But anyway somebody should manage all those issues, that feedback from the final users. What better than a QA engineer to handle that?

Manual testers are not monkeys


5.- Not having unit tests

This is usually an exclusively developer’s task. But without it, bugs become an infestation.

Unit tests are the first protection barrier against potential bugs. They are the essence of the test driven development, if we were wanting to follow that process. They make more agile the job allowing to change parts of the code and check potential failures quickly. Also they are examples for the new developers starting in the project.

Some ideas against unit tests say that a good design or a good planning prevents much more future problems than the ones detected by this type of tests. Software design and planning can be fantastic, but you cannot assure the code is working fine without these tests and you’ll be relying on higher level tests.

Please add unit tests

6.- Not having integration tests

Integration tests are the ones which can really check if the system is working correctly.  They join parts of the system verifying how they behave together. They are the basis of behaviour driven development together with functional tests. Unit tests doesn’t cover elements so important as database accesses or network requests, they are just not enough to check if the behaviour is the expected.

Thanks to this type of tests we can find bugs directly in the pull requests without the need of running regression test plans related with that part of the product. Having this kind of tests makes trustable some components, allowing us to know if they’ll behave as we expect when interacting with other parts of the system. This way they make the system reliable and protect development teams against unpleasant surprises from other components which will interact with their code.

When using a language like gherkin to write this type of tests we can get also extra documentation about how the system under test works. Enabling us to know quickly what is covered by tests and what isn’t.


Integration tests are essential


7.- Not having functional tests

Having them is going a step further of integration tests. They check the system like a user would do. Here is included specially graphic interface automation. This kind of tests have important tradeoffs, they are very time consuming, requiring much maintenance and hardware resources, being slow to run. A team shouldn’t use these tests excessively as they can find bugs hard to debug. It is better to have more unit and integration tests.

Nevertheless, the benefits are similar to the other types of tests. They protect against failing graphical interfaces and reduce significantly the manual regression testing time. They are specially useful when being set up to run across all environments where the app is distributed or where it runs. For example the different browsers when testing a system with a web UI.


8.- Not having QA managers

The QA manager or as Google names it, the testing engineering manager, is someone who understands the product deeply. Knowing its biggest risks, its weaknesses and improvement opportunities. The person on this role is the one who knows better where to focus the testing efforts, where to use manual testing and where to add automated tests.

The most common reason to obviate this role is the use of agileor post-agile methodologies. assuming that to achieve high quality is a responsibility of the entire team. Still, someone has to make decision and in this situation they are made by development leaders.

Removing QA managers remembering on waterfall methodology is a mistake. It should be a different role, someone which has a bird sight over the product, being the leader of a virtual QA department to improve the product as a whole.

In agile environments it is needed to be flexible, being ready for change and being able to introduce enhancements in the processes. It is precisely where this role shines. Freeing developers of making decisions related with testing (not unit testing) and interacting with them to take the proper decisions.

Someone has to choose what tools would be used to automate tests, how to prepare test environments, tracking bugs and so on. If every part of  a system uses different tools it would be harder to make engineers work in another part. Also having a specific set of tools focus the training efforts.

Without a QA manager, nobody would have enough power to refute development leaders from the point of view of quality. Quality engineers would be left at the mercy of developers, focusing on immediate problems instead of bigger risks. Creating the situation of developers with security harness which I mentioned at the beginning of this post.


Too many decisions to be made

It is said that Leonardo Da Vinci in his deathbed said: “I have offended God and mankind because my work didn’t reach the quality it should have”. You can avoid feeling this way.

Related posts:


Unit Tests in JavaScript with Sinon


Fast and natural Continuous Integration with GitLab CI


Leave a Comment

By completing the form you agree to the Privacy Policy