It seems like each company has a different approach to making sure their software is high quality. Some demand that developers do all of their own testing, completely eliminating their need for a quality assurance department. Some swing hard in the opposite direction, and require each and every code change to pass through a quality assurance department for approval before releasing anything. In environments like this companies run the risk of making their quality assurance department a crutch, slowing down development, when in reality qa should be accelerating the companies abilities.
To start, crutches are not a bad thing. People use them all the time as an aid to get better. What you don’t often see is people using crutches with two perfectly functional legs, indeed, doing so will actually make things worse in the long run; once healthy legs will start to wither with disuse.
So how does qa become an unneeded crutch? How do you know when to stop? Can the damage of over-reliance on qa be cured?
How does qa become an unneeded crutch?
In my experience small startups decide it’s time to hire a qa engineer when the developer approach “move fast and break things” stops being viable. They have paying customers, people are relying on their software, and consistent breaks are beginning to adversely affect future growth potential.
So a company makes its first quality assurance hire to figure out the fastest way to stabilize their development process. Right away it will probably be clear that there are some issues that need to be fixed, and the qa engineer will start to make changes. To make sure those changes are happening they’ll be double checking everything: Are commits being code reviewed? Are new features being audited by PM/UX before going live? Have all of the user stories been tested? And so forth.
As time goes on, product stability will start to improve, because the process has been improved with careful observation and extra cautious testing.
This is the tipping point.
The most difficult part of the process is reducing that observation and extra testing, and just like a person healing from a broken leg doesn’t run a marathon the day their cast is removed, it’s unreasonable to expect a dev team to have solved all of the problems they were having in the first place. Part of becoming a great qa engineer is knowing when it’s time to allow for a little failure, and when extra support is needed. It’s really easy to see bad patterns re-emerging right after a reduction in testing and feel the pull to put all of those safeguards back in place. Which leads us to:
How do you know when to stop?
Unfortunately knowing when a team has been healed of their bad habits isn’t as simple as an x-ray to see if it’s still broken. The art of removing safeguards is its own, slow process, and it requires allowing failures to happen, something that goes against the general nature of a qa professional. To illustrate this I’ll share an experience I had:
While working with a dev team to reduce the frequency of critical bugs on production we decided that each critical issue would get its own retro meeting. We sat down with the engineers involved in introducing the issue, the ones that solved the issue, myself, and the team leads. The first few meetings were uncomfortable, I was responsible for running the meeting, and while I knew the goals of the meeting I didn’t know the best way to accomplish them.
Eventually we got better at the meetings, and we came out of every critical retro with clear goals to avoid the same issues happening again with tickets for the long term fixes created and prioritized.
After doing this for a few months a critical issue arose, and the engineers involved sent a slack message that basically said: “We know what the issue is, and here are the tickets needed to get the fix done. [team lead] please prioritize them.”
From that point on, I became much more relaxed about ensuring every critical issue had its own retro. Critical issues were happening with less frequency, fixes were being properly executed, and the meetings became more of a formality. Yes, there were still mistakes, but we knew the path toward fixing them.
Can the damage of over-reliance on qa be cured?
The short answer is yes. The reality is that it is difficult to break the habits that have been picked up that lead to an over-reliance on qa, and breaking those habits will almost always be met with rejection and fear. Questions of “Why do we need to change this?” “Our process is working, do we really want to risk making things worse?” and others will arise.
The reality is that it’s easier to continue on with bad habits, but to go back to our broken leg analogy: continuing to use crutches after the leg is healed will lead to an atrophied appendage that slows everything down, and hinders a person from fulfilling their potential. Relying too much on qa to make sure that everything is as perfect as possible before delivery slows everything down, and in the end, slow just doesn’t cut it in today’s software world.
Top comments (0)