Do you have a ‘QA’ bottleneck?

Do you have a ‘QA’ bottleneck?  Is it really getting you down? You know, holding you back from being really productive. Well, your in luck.  If you follow some simple steps you will be well on your way to highly productive sprints and even higher quality product releases.  But first, a short read to make it easier to visualize.  If you have ants in your pants, go ahead and skip to the end to see the summary.  Jeez, some people  can be so impatient.  Okay, now we have this ‘QA’ bottleneck, right?

First, your problem is probably your misunderstanding of what quality assurance is.  Don’t worry, there are a lot of people out there who think like you, you are not alone.  You probably think that because you have a group called ‘QA’ that they are solely responsible for quality.  I mean come on, it says ‘Quality’ in the name so it must be true.  But this thinking is part of the problem, you’ve been institutionalized to think that quality is the responsibility of one group, but…wait for it…here it comes…it isn’t.  If you change the mentality such that everyone has a role to play in quality, you have begun a cultural transformation and are thinking differently already about how to solve your testing challenges.

Now, even if you believe the first statement, how does that help you?  Changing the way we think is great and all, but you need results.  You might get the warm and fuzzy from this change, but it in itself won’t produce the results you are looking for and it won’t unless you put some meat on the bone,  some grease on the skids, some uhh…what you really want is some action right?  So, imagine the scenario where you are at sprint planning and your scrum team is choosing their work, the tester says “Wait…i can’t take on anymore work, i’m all full”, but the developers are saying “We have more capacity, we can do more”.  What the team decides to do from this point will define them.  The successful teams will dive into why this gap exists and work on engineering productivity tasks that over time chip away at these gaps.  The less successful teams will just complain about it, because that’s a whole lot easier than actually fixing it.  When this happens, they usually want someone else to fix the problem for them.  Where’s that damn QA Manager at?

Here’s another common scenario, this happens near the very end of the sprint, when all of the ‘development’ work is done, but only the testing tasks remains.  Now we are really in big do do.  What are we gonna do now, huh?  Well, it’s obvious that your testers suck because the developers are all done with their tasks and only testing is remaining.  Agreed?  I mean, what’s the problem dude?  Get it together, seriously.  But, what’s not so obvious is that there were some delays in delivery, you know software is a creative process right, it’s not completely predictable, oh and by the way it takes just way too long to set up your environments and data.  But setting up environments is not testing, and setting up data isn’t testing either…what gives?  What we have here, is a failure to automate.  One of the growing issues is not just with your testing gap, but your setup and configuration gap.  If you spend the time fixing that, you are well on your way to removing your bottleneck and being awesome.  You seem like the type of person that likes being awesome so keep reading, i have some more ideas on how you can be awesome.

When you get to the point where you are analyzing your delivery pipeline and seeing inefficiencies not just with your people, but with your processes and infrastructure you have elevated your thinking to another level.  The ‘old’ ways of thinking are distant memories and you are starting to think like a real Engineer now.  When you build software that can be installed and configured easily, when you can spin up your environments quickly and predictably, when your data is reused and not having to be recreated from scratch each time, and when your whole team is writing automated tests and reviewing the failures when they break you have created an infrastructure that supports your processes.  Sounds great doesn’t it?  Then why the hell are you not doing it?  That’s simple, it’s much easier to complain about these things than to make the investments to improve them, which leads me to a final point…

The folks you hire and train should be smart, creative and highly motivated people.  When your testers understand how to read and write code, they gain the respect of their team members, when they can write code they can create tools that make them more productive.  When developers test their software and write automated functional tests, they gain the respect of their team members and they are able to jump in to help test near the end of the sprint and still maintain the expected quality levels for your product.  So, at this point, you either already knew this, or have heard this before…but if you are not doing this on your scrum team, then you may need to question how smart, creative or motivated you and your team members are.  Don’t worry, if that sounds harsh, I apply my team and team members to the same criteria so what’s fair is fair.

So kids, in summary, what we learned today was:

1.  Chip away at the culture of ‘QA” being some other teams responsibility

2.  Identify your true bottlenecks, not just the stage where the bottleneck exposes itself.

3.  Create an infrastructure that supports your processes

4.  Hire and train smart, motivated and creative people

5.  Profit?

Oh, and if you have tried all of the above and you still have issues, fire your ‘QA’ Manager because he probably sucks and is not convincing enough…

Note:  No scrum teams were harmed in the making of this blog post.

Advertisements
  1. #1 by randymelder (@randymelder) on December 17, 2013 - 9:31 am

    Mishmash of thoughts on this:
    Every house has a different circumstance, but testing starts with requirements. If it’s not documented, how do you know if the feature is complete? I think that QA needs to take responsibility for thinking of testing patterns that aren’t orthodox and aren’t obvious. Developers think in terms of functionality and performance, so it’s difficult to inject usability and user experience. This relationship between developers and QA needs to be a partnership where more knowledge is shared to improve the product. At the end of the day, who gets the credit or blame is irrelevant. Just make the product awesomely great.

  2. #2 by donottestme on February 13, 2014 - 11:05 am

    I agree with most of what you are saying, especially the part about each house having a different circumstance. However, after working in this field for nearly 10 years, i’m surprised how similar the houses are 🙂 human nature I suppose?
    Not only does testing start with requirements, i think Development and Test starts with expectations and conversations. Ideally this turns into something that can be demonstrated for feedback and clarification as soon as reasonable. If your testers are good at what they do, then they begin to play a facilitation role as well as an efficiency role, and are not necessarily doing ALL of the testing.
    However, i’m pretty biased with my approach. I think it works great in MOST scenarios.
    Cheers!

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

%d bloggers like this: