Q is for Quality, A is for Assurance
Did you hear the story about the developer that built a software application without any bugs? No, I didn’t either. Why? Because unfortunately, 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 CAF 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:
1. Your developers and QAs need to sit next to or in close proximity of each other. If they have to shout to ask a question then they are too far apart.
You also need to break down the 'them and us' mentality and get everyone working as a unified team. By doing this you quickly deal with the issues of QAs who may feel reticent about questioning the functionality of a dev’s code for fear of offending them. This upfront approach doesn't suit everyone so if you have a developer that is very guarded or sensitive to criticism, you need to ask yourself if they are the right fit for your team.
2. The QAs need to continuously review and test rather than waiting for everything to drop into the “Ready for Test” bucket in one go.
One technique that I have seen work very well is having the QAs involved in the Pull Requests process. This is a great way to make sure that what ends up being merged into the trunk is as good as it can possibly be and also means you are continuously testing throughout the sprint and not just on the last couple of days. This way when they come to test the develop branch at the end it shouldn’t be more than a smoke test to make sure everything is hanging together.
Project completed and your app is out in the big bad world. What happens if a critical or major bug is found?
Do you shoot the QA? He must have missed it, right?
Well, yes and no. If there is a bug that has been missed it is best to have a look at some of the reasons why. Remember at the beginning of this blog when I said that any developer worth his salt will take pride in their work, the same applies to the QA.
Frameworks such as Scrum and Kanban were invented to improve efficiency and to spot issues when they arise. In Scrum the retro is the perfect place to review the process and fix what is broken. For example, is there enough time at the end of the sprint for testing? If not, why not? Do you have too many points, are we implementing a code freeze? Is the delivery timeline unrealistic and are we rushing to get the work out the door? These are all questions that should be asked first before you execute the QA guy for a drop in quality. Quality is a responsibility of every team member not just the guys at the end of the line.
As I mentioned at the beginning - bugs and code go hand in hand. It’s a fact of life. But if you follow the process, make quality the priority and look out for your QAs you will deliver a great product to market, and a great product means happy customers.
If you'd like to find out more about our processes and methodologies for delivery at CAF why not drop in for a cup of tea at our Farringdon studio? Or send us an email to firstname.lastname@example.org