There is a legend that says that professional developers test their code. But testing is not just writing a few unit or acceptance tests. Writing these tests is a good thing, of course, but is far from sufficient. What every professional development team needs is a good testing strategy. Some simple general rules I try to follow are:
- Identify the main functions of my code. I Don’t waste my time trying to reach high code coverage testing things that are unlikely to fail (believe me: There are people who creates unit tests for getters and setters just to improve code coverage).
- Test boundary conditions (bugs like to live in between software boundaries).
- Test exhaustively functions that a bug was found. Bugs tend to nest and live together.
What is the problem with these three simple bullet points? The problem is that we as developers tend to deviate a little bit from this direction.
- We tend to be too optimistic regarding software behavior and do not cover properly what is really important.
- Sometimes we do not identify boundaries clearly, and by doing that, do not not cover the function with proper test strategy.
- And ultimately, we create tests that covers only the bug found or the happy-path scenario (in most cases doesn’t even create test to ensure that this bug won’t happen again…).
In some companies, a professional with Quality Assurance (QA) role is part of the team and ideally his/her goal is to find nothing wrong. Of course, it’s not likely that this goal will be constantly achieved. After all, when you have a group of smart people focused and determined to find all the flaws and deficits in a system, they are likely going to find some. Still, every time a QA finds something the development team should react in horror. They should ask themselves how it happened and take steps to prevent it in the future.
It might seem that QA and developers are at odds with each other, that their relationship is adversarial. This is not the intent. Rather, QA and developers should be working together to ensure the quality of the system. The best role for the QA part of the team is to act as specifiers. Just one more time: They are our allies.
In a perfect world, the QA role is not just to execute manual tests to find bugs, but is to spend more and more time creating automated business acceptance tests that become the true specification and requirements document for the system. Iteration by iteration they gather the requirements from business and translate them into tests that describes how the system should behave.
As more as the QA spends time close to the business to clarify requirements instead of finding bugs that could be covered by some layer of test, more mature your development is.
One of the most common issue in a development project is the communication (or lack of) between business and development. Between these two corners a QA could be very beneficial. They are there to help us to improve the quality of the system in order to deliver a product more stable, robust and according to business’s expectations.
In general, the business writes the happy-path scenarios, while QA writes the corner, upside down, impossible, boundary, and unhappy-path tests.
Well, that’s it. A tiny drop of my opinion about QA people 🙂
—
Bibliography:
Clean Coder, Robert C. Martin
https://martinfowler.com/articles/practical-test-pyramid.html
Sales Lopes 