Usually when I meet with a Quality Assurance team that is not practicing Embedded Quality, their first reaction is excitement. They hear the basic concepts and say, "Finally, someone who wants to do it the right way!" I outlined the basic concepts in this blog post:–-building-on-a-solid-foundation.aspx , but as a reminder, 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

However, despite the initial enthusiastic reception that Embedded Quality gets from the Quality Assurance team, they often are reluctant to implement it.

Overcoming Common Concerns

Ultimately, I have found that many people are adverse to change, even when they see that it is a positive change. However, once we discuss their concerns with the change and work together to address those concerns, the Quality Assurance team is ready to start implementation of Embedded Quality.

We Don’t Have Time!

Honestly, Embedded Quality saves time compared to other methodologies; however, many Quality Assurance teams initially see it as something to add to their current process rather than something that replaces their current process. There are a couple specific variations to the "We don’t have time" concern.

  • Our regression test takes 6 weeks to run, and our policy is to run it after every build. How can we possibly take weekly builds?
    • There is no need to run a full regression test for every build when using Embedded Quality. Each build is an interim build that is not actually going to production until later. The goal of testing each build is simply to identify as many issues as early as possible. The goal is not to have a perfect build.
    • When you do reach the time to run a full regression test, it will run much smoother than it did in the past, which means it will take less time. Generally, it’s difficult for me to convince Quality Assurance teams that the final regression test will take less time (the best QA folks tend to be skeptical people). However, I have found that regression testing always takes significantly less time when using Embedded Quality.
  • Even if I don’t run a full regression test for each build, how can I possibly test a build in a week?
    • Keep in mind that when you take a build every week, there is not much new code in each build. I’ve found that I personally can test one week’s worth of work from 3-4 developers in a week. The testing focuses primarily on what is delivered that week.
  • I’m too busy with my current projects to start using Embedded Quality on the new projects.
    • The transition can certainly be a challenge. However, the Quality Assurance efforts at the start of a new project are quite light when using Embedded Quality. Because the developers need to support the bugs reported in the current project before starting the new project, I’ve seen that the Quality Assurance team can keep up with whatever the developers can deliver.
  • My QA tasks already take up all of my time. How can I find time to talk to the developers as well?
    • I’ve found that any time spent talking directly to the developers actually saves time from other tasks. In a typical scenario where teams rely on passing a bug back and forth without talking at all, I have seen bugs commonly go through 3-4 round trips with comments that indicate clear misunderstandings between the developer and tester. A conversation is much more efficient whenever the first message is misunderstood.

Quality Assurance Needs to be Independent and Unbiased!

Some people in Quality Assurance have told me that if QA is part of the core team, they will purposely ignore bugs to help out the developers. These people seem to think that the developers and the Quality Assurance team have conflicting goals. However, the reality is that the goal of all members of the Core Project Team should be in sync. The whole team should have a goal of producing a quality product that meets the needs of the business.

Any good Quality Assurance professional knows that when a developer says, "It’s just a small change. You don’t need to test it," there’s guaranteed to be a bug. Including QA as part of the core team doesn’t change this mentality at all.

The Other Teams Will Never Go Along With Embedded Quality

True, it can be a challenge to get the other parts of the project team to implement Embedded Quality. However, I have successfully implemented it with many new teams. In future posts, I’ll discuss how to overcome the objections of other teams. Once teams experience a project with Embedded Quality, they’re excited about using it on their future projects. Some of the biggest skeptics of Embedded Quality that I’ve worked with now insist that it be used on all of their projects.

Other Concerns?

I’d like to know what concerns you would have in 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.