When you are a small and lean software development shop it seems you can’t always do things the ideal way. The processes and tooling you adopt are associated with an immediate challenge, and can seldom look past an immediate release. Quality Assurance is one of those processes that many small dev teams consider something that they will do when they are large. And what a huge mistake that is.
I know how it feels; you need to get a product out the door now! And anything that slows that down is the enemy. Avoiding end-to-end testing very often does not impact small development teams. Not only because they can respond quickly to issues, but because their application adoption has not hit critical mass. Bugs are controllable enough when issues do make it to production. and do not have a terrible impact on the current user base.
Errors in production seem like a scary thing, but even scarier is when it’s time to “Cross The Chasm” and you don’t have the tools to do it.
When a company grows to a point where they need to accelerate, they have two options when it comes to their processes.
1) Re-evaluate the processes and design them to fit future demands
2) Keep chugging along with what they’ve got
It is no stretch of the imagination to realize that the second option is by far the most common. And often it’s thought that the team can slipstream new elements to their processes that are needed such as analytics, and QA. But this is almost never sustainable. And the reason for that is it’s not holistic, so the kludgy additions impact all the old processes in a way where you have to stack kludge on kludge.
Option one is not good either. If you take this option then you need to stop everything, probably spend 3 months or so to re-define what your development processes, and tooling are. When you come out of it you will have a dream setup that fits all the needs of your current business and future, but you will see how far behind your results have become – and sometimes you can never recover from that lag.
As you can see, the only way to avoid these problems is to introduce the right culture, processes, and tooling early on. When you jump into development, create a small filter that asks:
- “Does what we are doing make sense?”
- “Is it scalable?”
- “How will it break as we grow?”
- “Are we missing out on something that others have?”
Missing out on great analytics from your existing applications is another huge problem. There is historical data about software quality that could benefit you months, even years, down the road. But if you are not going through the process to get this information or critical milestones you will never know.
- Is QA infrastructure overloaded resulting in slower releases an and test runs
- Is the test coverage more or less than expected
- Which test cases are running the fastest
- How many tests did you run in the last release versus previous releases
- What is the trend of bugs over-time
- How did the number of bugs relate to the size of backlog
When you are in “guerrilla get things done” stage, it’s never easy to take a step back and look at the big picture of your companies and application growth. QA is one of those things that you might think you can avoid early on, but if you don’t consider it from day one, it will cost you dramatically in the future. And not only are you losing out on software quality, but also on analytics, and the opportunity cost of not having a complete development team and process where your competitors do.
Stop considering QA as a drain, and think of it more as insurance, to make sure as you’re minimal viable product picks up steam: you can support future demand, you do not get called out on poor software quality, and you are not stuck when the team grows.
Chris Riley is a technologist. Helping organizations make the transition from traditional development practices to a modern set of culture, tooling, and processes that increase the release frequency and quality of software. He is an O’Reilly author, speaker, and subject matter expert in the area of DevOps Strategy, Machine Learning, and Information Management.