When I’ve introduced Embedded Quality to the developers on a project, a common reaction is fear and loathing.  They often have a visceral, negative reaction to the words “Quality Assurance,” and the idea of working more closely with the Quality Assurance team instills a feeling of dread in them.

As a reminder, I originally outlined the basic concepts of Embedded Quality in this blog post.  The concepts are:

• Quality Assurance starts on Day 1
• Quality Assurance is part of the Core Project Team
• Quality Assurance is performed by qualified experts
• General User Acceptance Testing does not begin until Core Project Team QA is complete
• Strong Foundation – No code is “Complete” until it is tested and works correctly

Although the developers I’ve worked with generally have a negative first reaction to the concept of Embedded Quality, once they’ve experienced it, they almost always request it on their next project.  The question is, “how can we convince developers to try Embedded Quality the first time?”

Overcoming Common Concerns

I’ve found that it’s typically harder to overcome the developers’ concerns than the Quality Assurance team’s concerns because the developers usually start with the mindset that they don’t want to use Embedded Quality.  However, there are ways to address their concerns.

The Code Isn’t Ready to Test

The developers will often say that the code really isn’t ready to test until very close to the end of the project.  However, there are some good reasons why this should not be the case.

• The project schedule generally shows sections of code being completed before the end of the project.  If a developer says that the code is complete, it’s difficult to imagine why it can’t be tested.
• It’s much easier to identify and fix bugs in small portions of code.
• Finding and fixing bugs early means that new code is built on a solid foundation.

Having the Quality Assurance team test code early in the process is analogous to having a building inspector view various portions of a building before it is complete.  It makes a lot of sense for the inspector to check the foundation, the electrical, the plumbing, and the HVAC system before the building is anywhere near complete.  Fixing these items after the building is complete is much more costly and difficult than fixing them earlier.

It Will Take Too Much of My Time

Another concern that developers have is that they will have to spend too much time explaining things to the testers.  Because the code isn’t complete, they are afraid that the testers will report bugs for items that are simply not yet finished.  Also, they will have to spend more time explaining how to test certain items when the complete UI may not be available.

These concerns are legitimate and show the need for having a test team of qualified experts.  The testers should have a mindset of collaboration with the developers rather than antagonism.  The testers will work closely with the developers to understand what code can be tested and what code is not ready.  Of course, any code that is not ready cannot be considered complete for project planning purposes. 

It is also true that the developer will have to spend more time explaining how to test some incomplete code.  However, if the Quality Assurance team is qualified and experienced, they should be able to quickly learn any tools needed for testing.  In my experience, any extra time that the developers spend helping the Quality Assurance team is saved many times over by finding the problems early.

I Don’t Need the Extra Pressure of Someone Looking Over My Shoulder

Many developers have had bad experiences working with testers who take delight in pointing out the flaws of others.  These types of testers tend to make comments like, “I don’t know what those developers were thinking,” when they chat with each other in the break-room.  This attitude really does put unnecessary pressure on the developers and contributes to a hostile relationship between developers and testers.

This is why it’s critical to ensure that the Quality Assurance team is made up of true professionals.  I always remind the developers that Quality Assurance is part of the core team, which means that our goal is to ensure that the project gives a good impression to everyone outside of the team.  I tell the developers that I know that they’re good developers and that bugs are a normal part of the process.  The developers shouldn’t feel bad if the Quality Assurance team finds bugs.  In fact, they should be happy because every bug that is found by the Quality Assurance team is one not found by the project sponsor or the end users.  The project sponsor and the end users are the people who are generally the harshest critics of the development team.

Other Concerns?

I’d like to know what concerns you would have introducing Embedded Quality into your organization.  What concerns would you anticipate from others?  I’ll do my best to address those concerns in future posts.