The Demonic Dev/QA Relationship

I received a lot of generous and interesting feedback from my presentation, QA Role in Scrum – Leveraging Agile for Defect Prevention at PNSQC last October.  Some came in the form of written comments on little sheets of paper handed out at the end of the presentations. One that particularly stood out for me was,

“Nice job not demonizing dev.”

I laughed on first reading it.  Why would I demonize dev?  We’re all on the same team; we all want to create a high quality product.  Right?  Right.

But I don’t think the writer was joking.  It’s amazing to me that after 20+ years in software development I still hear about – and personally observe – the age-old tension between QA and dev.  Agile was supposed to fix all that, right?  Even in Scrum teams (where “quality is the responsibility of the entire team”) devs still get unhappy because QA is rewarded for finding their flaws.  QA gets unhappy because dev is unhappy with them for doing what they’re paid to do and doing it well.

How do we fix this?  We redefine QA’s role.  The role of QA should not be “bug finders”, or “debuggers”. Instead, QA should be collaborative developers.  They work with developers before implementation begins, providing input on what will be tested.  They create tests which devs can execute themselves before checking in their code.  This way, QA and dev work together to keep defects from being introduced in the first place.  This puts QA and devs on the same team.  Collaboration keeps the demons away.

Advertisements

2 thoughts on “The Demonic Dev/QA Relationship

  1. I believe you are referring to unit testing code above, and that is always DEV’s responsibility and not QA’s for good reason. Maybe you are thinking TDD (test driven development), but even then QA/QE is not writing the unit tests, DEV is. The collaborative development you are describing sounds great in a presentation, but will never work in practice.

    Like

    • Hi John,

      Thanks for your feedback. I’m referring to a number of test-oriented inputs from QA during dev-QA collaboration. Unit tests are one. Some QA on my team are engineers who do write some unit tests. Some input also comes in the form of discussions and recommendations regarding unit tests. Still other involves input about what tests will be conducted either by other automation, or by manual and exploratory testing. All of this input is valuable to dev in order to write more robust code the first time around.

      One thing I could have added in the post is the cultural shift that needs to occur and exist in a team for this to be accepted and productive for all team members. Even when cultural expectations around this are set and reinforced, it does seem to take time (more for some than others) for team members to embrace the collaborative model. I’m not sure why that is.

      I would have liked to hear more from you on your statement, this “will never work in practice.” In our team it’s working quite well. This will never work, because….?

      Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s