Quality assurance in small developer teams

Do you use any Software Development Methodology, like e.g. Scrum? Scrum is one nice Agile way of working, but there are other good processes too.

We use Scrum. This is a good way to make our teams efficient, but it is also a good way of introducing rules to the way we develop software. Like you - I'm part of a small team. Unfortunatelly we're not blessed with a QA department or any dedicated QA people. Work done during the Sprint should be potentially shipable, so the developers in the team needs to handle the QA job.

In Scrum and e.g. Kanban you use a Task Board to keep track of the current Sprint, and these boards often have a column for tasks awaiting approval by QA. What we do is that when a task is done we move it to "Ready for verification". And then another developer on the team does the QA job. He will:

• Assure that the new functionality does what it is expected to do/bug has been fixes/etc.
• Verify that there are sufficient unit tests
• Do a quick code review to check that the code looks clean and understandable

If there is something not satisfactory in the review he will move the task back to start, and it needs to be fixed before it can enter another QA session.

None of us really have any knowledge about QA, but we experienced a lift in code quality after introducing the verification.

Sounds like you are doing lots of things right and asking the right questions.

For the last three years I've worked on 2-4 person development teams without any formal QA. We have very satisfied clients and low bug counts.

This works for us because:

• Everyone's priority is quality software. We don't pass around a QA role, but all do it all the time. We want our code to look good. And all the developers are eager to write both unit and integration tests, and there's team pressure to make sure the tests are there.
• We pair program extensively. This small overhead improves quality significantly, and has all sorts of advantages. You develop are shared understanding of what "quality" means, and answer the questions yourself.
• We have regular "retrospectives" where we ask what we can improve. Related to that, if we have quality problems, the team figures out what needs to change to address this (5 Whys analysis). We have instigated such rules as "two eyes on any checkin" to address problems.

All that being said, quality is ultimately about satisfied users. I try to bring people back to that when discussing quality in the abstract (and arguing about variable names). Ultimately it should be about how the software solves users problems, and not crashing is only the first step.

As a start, if you haven't done so already I would strongly recommend setting up an automated build that also runs the unit tests, preferably with code coverage to check if there are areas that need more unit test coverage. I'm not a massive fan of requiring 100% code coverage but anything that only has about 60%-80% probably needs looking into.

I've worked in teams where the daily build was done manually and the developer doing the build had to perform the integration work too, as all too often the check-in criteria were "it builds on my machine". Getting an automated build going that gets kicked off either on every checkin or at least once every hour and requiring the developer whose checkin broke the build to fix it is a massive step in the right direction and will (hopefully) ensure improve quality over time.

Code cleanliness is something that I find hard to impress on a team from the outside. In a sense this sounds what you're doing - the QA role cleaning up the code? - but maybe I got this wrong. If I didn't get this wrong I think you'll need to change that. Quality isn't something you can or should bolt on as an afterthought, the people working on the code should strive to achieve the quality goals and code reviews should highlight areas where the original developer needs to improve the code, but not have a "QA person" come in and clean it up. Apologies if I have misunderstood this, but if this is part of your process this needs changing right now because you're doing the equivalent of mum cleaning up the messy teenager's bedroom.