Did you hear the story about the developer that built a software application without any bugs? No, I didn’t either. Why? Because bugs and code go hand in hand.
Now don’t get me wrong. I’m not saying that developers are sloppy, on the contrary. Any developer worth his or her salt will take pride in the work they do. It’s their name on it and they will always want to produce the best work they can. So this being the case why do we still get bugs?
There are a lot of factors that go into building software and so the answer to this question breaks down into three categories:
- All developers are human and by design human beings make mistakes.
- Computer code is very complex and if you are writing code on top of code, things can and often do go amiss.
- Outside influences can have an impact, especially in time-sensitive projects. We’ve all heard the PM ask the dev ‘is it ready yet?’
Add these three elements together and you have a perfect storm, ready to cook up some bugs that will scuttle out from the dark recesses of the lines and lines of written code. How do we combat these little creepy crawlies? Two letters – Q and A.
When setting up a project for success it is paramount that you have the right amount of QA resource. The role is as important as any other member of the development team and unfortunately, it is the first role that gets dropped or cut in a price sensitive project. In my career, I’ve seen it many times on software projects and it’s not a practice CA would condone.
Of course, developers should show an element of due diligence when writing their code, but it’s the QA’s responsibly to test it with every possible outcome, including edge cases.
In addition, UAT and QA should never be mentioned in the same breath. UAT must be undertaken by real end users to prove that the software is fit for purpose. QA is the guy bending the software to straining point to see if it will crack. If a client is new to software development we help educate them on the need for QA resource, as it can be the difference between a product being delivered on time or functioning correctly.
Now you have got the right amount of QA resource on a project, how do you get the best out of it?
It’s very easy for a software project to be depicted like a conveyor belt.
Think of your Jira board with its swim lanes.
It’s set up in way that makes you think of your team stood at their individual stations waiting for bits of work to come rolling down in front of them. The developers happily get to work and towards the last couple of days of the sprint the work starts to land on the QA’s lap.
If this is true in your case, then your project has a high chance it will fail.
Why? Because it silos each team member.
Now try and think of your team sitting in a circle where whatever they are working on can be passed in any direction. Your team in no longer linear but multi-stream and things can move backwards and forward between the team with ease.
To achieve this, a couple of things need to happen: