First let me say that I am not a tester, let alone a test manager or a testing guru.   What I’m writing here is the out-of-scope ramblings of a developer.

I’ve been on my new project for about a month now and I’m seeing some shocking trends.  The most egregious is that past releases of the code have gone straight from the hands of developers to UAT (business users in our case).  Now, towards the end of the first major phase (not the first iteration by any stretch) of the application’s development, management on the project and from the client is quite concerned about the quality of the software being released.  My first reaction to this was “Well, wft do you expect?”.  Now that I’ve had a few weeks to think about it, here’s where I’m at.

We all know that software developers (or programmers or whatever the hell you want to call yourself today) are notoriously horrible testers.  We’re far to close to the technical implementation to be able to clearly see the application in the same light as an end user.  Because of this every developer will miss things that a business user would do the first time they sat down and used the system.  Because I’m not actually coding anything on this project yet, I consider myself, and the couple guys I have working with me (all of us have less than one month with the project), to be business users of the existing application.  We were tasked this week past with doing what I’ll call usability testing for the majority of the application.  Like true business users, we jumped in head first and within minutes our pod was buzzing with conversation about what we, the business users, felt were blatantly obvious application faults, system inconsistencies and flat out confusion incurred by the way the system interacted with us.  The most frustrating thing for me was that this system had been in UAT for months (I don’t know for sure, but my guess is 6 or more months) and we were still having these problems. 

Why hadn’t they been found and fixed by the developers?  They’re too close to the code to use it like we did.  Also, they’ve been told to prioritize on a small subset of the application and fix all the Critical and High defects, while we were testing the areas of the application that they weren’t focused on.

Why hadn’t they been found by the UAT team?  I’m not sure how big the team is, but I have a feeling that they’re swamped with the size of the application and the volume of retesting because of defects that they are raising.

Great, I’ve figured out that the application’s quality is substandard and that the client has every right to be pissed at the team.  How do you fix it?  I think that there are a number of ways, and to the credit of my team’s management, some were being implemented prior to my arrival. 

First, I believe that you need a dedicated test team to stop the obvious defects from being shipped to the client.  Often this group is called QA because their job is to ensure that a certain level of system quality is met prior to the business users working with it.  Test/QA teams are an insurance policy on the goodwill that you need, and hopefully have, between the development team and the client.  Like other kinds of insurance, the cost of insurance goes up when the size of the object, in this case the application development effort, increases.  This means that tester-developer ratio is important.  If you measure success based on some metric involving the number of defects raised by the business, the most successful project I’ve worked on, at it’s peak staffing, had a ratio of approximately 1:4.  The project I’m on now currently has a ratio of approximately 1:8.  My mathematical way of thinking says that my QA insurance is only going to be half as effective on my current project.  Ratio isn’t everything though.  I could try to staff a team with a 1:1 ratio and it may not offer any more benefit than if I’d staffed it with a 1:4 ratio.  There is a point of diminishing returns and a project needs to figure out where that point lies for them.  If you’re completely swamped defects, your ratio probably isn’t high enough.

Well, now I’ve put all the pressure for the success and quality of the product, along with the responsibility for the goodwill between the team and the client, on the QA team.  It’s time to take some of it off their shoulders.  I’m a Lead Developer on this project.  My job description says that I’m partially responsible for, and I’ll paraphrase here, the project being on time, on budget and quality.  Even if this weren’t written in stone (we use MS ShareRock v1.0 – it’s buggy, but I think that we just need to upgrade to a better chisel), I’d still be preaching these three points.  The one that is most important for this conversation is quality, and if I’m partially responsible for it, I need to take steps to increase the quality and decrease the defects and defect churn.

From what I can tell, the project I’m starting on hasn’t had any concern with quality at the developer level.  Instead they’ve worked with the mantra that “bugs come in, developers fix them and ship them out to UAT”.  As a Lead Developer, I have the responsibility to ensure that the work being done by the other developers is being effective.  This means that I need to do checks, or, as they’re better known, code/functionality reviews before anything, defect, new coding or otherwise, makes it to any level of testing.  For me, the question isn’t if you should be doing code/functionality reviews, but instead how often are they necessary.  If your project is completely swamped with defects, you need to increase the frequency of code/functionality reviews at the Lead Developer level immediately.  Don’t be like my current project has been doing in the past.  Their definition of a code review was a once a month meeting of all the developers where one developer picked a single piece of code that they’d written and presented it.  So the project is swimming in a sea of defects, some of which are continually churning, but code reviews are held extremely infrequently.  It doesn’t make sense to me.

Every Lead and Senior Developer out there is fuming right now because I said that they may need to be spending more of their time reviewing and testing the code of other developers and, ultimately, spend less time coding themselves.  You have an incentive to change that…increase the quality being turned out by the team you’re working with.  Instead of spending that one meeting a month on a code review with the whole team, spend it on a training session for the whole team.  Work on increasing the skills of your team everyday.  That may include everything from a formalized training session to a solid pair-programming experience.  Take every opportunity to teach the team and you will start to see quality of their work increase.  The other, and in my mind more important, way of increasing quality at the developer level (this includes lead and senior devs too) is to instill a culture that focuses on quality.  The first thing that every developer on your team should think about is quality.  This is one of the things that I’m working on right now with my team.  Everything time I talk about what we are or will be doing, I emphasis the importance of quality to it.  I want my team to have such a high pride of ownership in their individual code and the overall application that they are collectively embarrassed by defects and motivated to resolve them. 

I’m currently seeing an attempt by my team’s management to reward people for fixing defects.  There are numerous reasons that this backfires.  The one that I’m most worried about is the fact that it emphasizes individual quality instead of team quality.  I have my ways that I’m going to fight this, but in the end it will be my team that gets the congratulations, rewards and attention if we do a good job on quality.  It won’t be me for leading them.  It won’t be Joe for fixing the most defects.  Quality is a team effort and thus should be recognized in that way.

So, to wrap up this rather long bit of rambling, I’ll list the things that I think are important for improving the quality of the application that you release to your clients.

• Developers don’t make good testers.  Because of this, don’t rely on them to do your only testing.
• Think of QA as insurance for the goodwill between you and your client.  Make sure you have adequate insurance.
• Quality should be a way of life for developers of all levels.  Make an effort to help them increase their quality.
• Quality is a team sport.