You are never taught how to build quality software

Have you ever been in on a software project that is missing vital quality assurance measures? You are not alone. This happens to a mind-blowing amount of companies and projects. Even if they know that there is this thing called QA and that we should do it, all efforts typically result in the big QA sprint right before the release. Stressful times that only make the software barely work. All of this chaos repeats in the next release cycle of course. No improvements.

What uni Teaches You

The thing is, if you study computer science you don't learn how to ensure quality standards in software. Most of the time is spent on algorithmic, how a computer works, the history of some languages and concepts, etc. In addition, at least in my studies, there was a semester about project management approaches and scrum. All of which is great, but QA is missing completely. Neglecting QA is a shame because 90%+ of all students work in a company context after they finish their degrees. It will be necessary to deliver software without bugs in time.

How companies deliver barely on time

I have seen it countless times. QA standards and measures are the ones to be cut out of the project because of budget reasons first. It's oftentimes planned during the end of the project, but if development takes longer (which it often does) or scope creep comes in (which always happens), there is not enough time for QA anymore. We end up with an absolute minimum of unstructured testing and ship a digital house of cards with brittle walls.

In some companies or teams, there are certain QA standards in place. Commonly it's a senior member of a team who is enforcing them for the rest of the group. Most likely they learned the hard way that without QA everything will just become so much harder along the way. Unfortunately even having standards in place is not enough. It happens time and again that teams simply write tests to satisfy project management metrics.

How to get out of the hamster wheel

It took me years to build the experience and confidence to speak up about missing QA measures in projects. Arguing with managers, living through crunch-time around releases, dealing with failing production systems and looking for missing monitoring. It's not fun. The situations are similar for other improvements of the code base or project which are not directly visible to managers like Refactorings for example. But for QA it was always particularly difficult because if we didn't implement any measures, we also never learned how to do it properly.

When your unit test passes but integration test doesn't.

Only speaking up and raising the discussion again and again will help to find the first steps out of the hamster wheel.

Speak about money

At some point, I realized that I wasn't using the right arguments either. Explaining that the software will be 'more stable' or 'make maintenance much easier' is not palpable for someone who doesn't work in the codebase themselves. We need to speak about money. As developers, we need to speak about the cost of not doing QA. This is the language of business and managers in general. By now, I always try to frame QA measures with examples like: 'If we don't do it now, development efforts (and therefore also costs) will be up 15% in 4 months.' or 'We need to implement unit tests for all features or our release stabilization phases will take longer and longer each time. Directly related to all the features that we build, because we need to test all side effects manually each time. This will result in us making less progress each release.'

In my experience, this switch helps to bring the point home. In the end, your efforts on this will make everyone's life better. Not everyone knows it yet though.

Minimal effective dose

To be realistic, it's important to not over-engineer QA measures with a big upfront investment. We shouldn't block progress of the project as a whole and neither will we get the necessary buy-in from all stakeholders with this approach. I suggest always to look for the most vital parts of the application. Normally, there is a certain use case, feature or something that the whole application is built around. Some core-functionality which must work correctly in order for the software to be of value to a customer. Test that. Come up with measures and ways to ensure this is always working as expected.

I like the term 'minimal effective dose' (MED). The smallest dose that will produce the desired outcome. In QA this can be a manual testing plan, automated tests in the pipeline or something different. It's the right place to start. If the core features are ensured, you can gradually expand stability. I.e. for all new features, you add a unit test. Additionally, think about sources of information that you can't control. Like external APIs or user inputs. Find ways to validate them as well as these are more obvious places in which your software can crash because of misuse. Iterate and increment. Also on QA.

Things I look out for

For each new project that I start or join I look out for a QA concept. However small it might be, the team should have thought about it.

• What are we shipping?
• What do we need to ensure is working?
• How do we do that?
• Out of which measures do we deliberately opt-out and why?

Having a written document about this plus perhaps a testing plan is a great foundation on which software can progress. It shows that we as a team thought about how we proceed. Again, thinking in terms of MED. Additionally, I suggest to review the chosen approaches regularly. I.e. once a quarter.

When writing new code, I am not using TDD, but I strongly recommend writing tests as you write the software. It's the right moment in time, to write the test. If you write the tests as you implement the feature you have the benefit that your code has to be structured in a way that is actually testable. Writing tests for existing software often reveals that a given code is way too interdependent or that single responsibility principles have been violated. Through the tests you, describe that you understood the desired behavior and made sure everything works as expected too. It's even a form of code documentation if you will.

Project benefits

When you speak up, people around you will realize that you care for the project. Raising discussions around quality and suggesting possible solutions even extends your reach as a developer. It can benefit you personally as well as the project. Quality of life for developers and managers will increase. It certainly will be noticed.

Only with QA measures can a project grow at a healthy pace.

Changing projects for the better

Are you already using QA measures in your project or is everything super brittle? Do you want to expand your developer skills and be someone to be known for writing quality software?

Start small. Think about the MED in your project. Take ownership and be the voice in your team to change things for the better. Not everyone needs to be a QA ambassador, but you can teach the people around you the approaches necessary by leading by example. Spark the discussion.

Just do it.

Cheers,
Flo