Ask All Things
Priya asked some great questions:
Hi Joe,
I have been following your blog for quite some time. Lot of good information.
I am reaching out to you to get a third person’s perspective in our current situation-
I work for a product based company’s IT team. We are into our 2nd year of agile practice.
We are a team of 4 QA engineers. We are working very effectively, releasing deliverable with great quality.
We are 4 + 1 manager to cover vast range of applications supporting the company- Finance, HR, Sales, Distribution, Support, Legal..you get it.
We have an automation QA engineer working from India office. At one point we collaborated with him for few apps and came up with regression test scripts. Our apps subsequently were redesigned or upgraded to different versions, which means those scripts were now obsolete. We did not maintained those scripts.
Right now we are under pressure by management to get our hands in automation. Management wants each one of us to come with automation scripts for app. Honestly I have nothing against automation, but I don’t see how automation will help us. Our apps undergo lot of changes in short span- 2 months and upgrade to different product version every year. We cannot stretch our bandwidth.
Also we do not have a mature model of SDLC yet. Dev not doing unit tests , release process to QA env and staging env are battle, getting the requirement written to stories and sizing in some department is challenging. But management seem to ignore these problem and focus only on getting automation up to to speed.
I feel we are fighting a losing battle with them- arguing automation is a full-time job, distracting from what we are focusing on. We are trying to tell them to hire another full-time automation engineer onsite and basically leave us alone.
Do you think our ideas are out-of ordinary that we do not want to automate and deal with hassles? Do you think we are matured enough to automate ?
I would appreciate all inputs from you. Looking forward to hear from you.
Thanks,
Priya
Thanks for reading, Priya! And great questions! But tough to answer without knowing a lot of context about your company and your management. copyrightjoestrazzere
You have a lot going on here - lots of applications being changed frequently, management pushing for automation, prior automation done by a single remote QAer, etc.
Let's tackle some of this, one point at a time.
Automation
I suspect that management doesn't just want "automation". Instead, what they really want is some benefit that they think automation will provide. That benefit could be reduced costs, improved effectiveness, decreased test time, or something else. Automation is usually just the means to an end.
Knowing what is really required, would help your team determine how to most effectively supply it.
If you are really working very effectively, and releasing with great quality, those are great achievements. Hopefully working toward whatever additional benefits are desired won't interfere with the success you have had so far.
Agile
In talking with many QAers, one thing I have learned is that "Agile" doesn't mean the same thing in any two shops. Everyone does it differently - particularly when it comes to QA.
In some shops, all the details of your Agile SDLC are dictated from above. But many shops have more organically-developed practices. In some shops, the Agile teams themselves decide the level of automation they need to succeed, and dedicate time and resources to accomplish that level.
You seem to indicate that your SDLC doesn't yet have all the attributes that you hope for. Hopefully you can improve these processes while still meeting management's other needs.
You have a lot going on here - lots of applications being changed frequently, management pushing for automation, prior automation done by a single remote QAer, etc.
Let's tackle some of this, one point at a time.
Automation
I suspect that management doesn't just want "automation". Instead, what they really want is some benefit that they think automation will provide. That benefit could be reduced costs, improved effectiveness, decreased test time, or something else. Automation is usually just the means to an end.
Knowing what is really required, would help your team determine how to most effectively supply it.
If you are really working very effectively, and releasing with great quality, those are great achievements. Hopefully working toward whatever additional benefits are desired won't interfere with the success you have had so far.
Agile
In talking with many QAers, one thing I have learned is that "Agile" doesn't mean the same thing in any two shops. Everyone does it differently - particularly when it comes to QA.
In some shops, all the details of your Agile SDLC are dictated from above. But many shops have more organically-developed practices. In some shops, the Agile teams themselves decide the level of automation they need to succeed, and dedicate time and resources to accomplish that level.
You seem to indicate that your SDLC doesn't yet have all the attributes that you hope for. Hopefully you can improve these processes while still meeting management's other needs.
Who Automates
You seem to be implying that you can't do automation unless it is a full-time job for someone, presumably someone that isn't one of the four QAers currently on your team.
I disagree that this is the only way to automate. I have been successful in the past with test automation being part of every QAer's role. This approach means that time must be allowed for automation and maintenance within the schedules, and that every QAer must be trained sufficiently. But it is possible.
It's also possible that your automation QA engineer in India could revive and update your automation, perhaps with some help.
Also remember that automation doesn't always mean that QA must be the automators. You are probably assuming that you must do automation at the UI level. But you have likely seen that UI automation is brittle, and quickly becomes obsolete if not constantly maintained in the face of rapidly changing applications. A different approach that some shops use is to automate at lower levels - below the UI. Such automation is often written and maintained by Developers rather than QAers.
What to do
While I understand that you don't feel you have the time to automate, and don't want to "deal with the hassles", I don't get to make that decision, and perhaps you don't get to make that decision, either.
I suggest that you find a time to talk with management. Ask them some great questions, then listen and learn. Try not to jump to conclusions, and try not to be negative.
You want to understand why they are pushing for automation, and what they hope to achieve by doing so. You want to understand how automation fits within your Agile shop, and within your current SDLC. You want to understand what the parameters are for your automation work, if you can actually get more help or even have a different group create and maintain the automation.
While you want to make sure management understands the tasks other than automation that demand your time, you may find out that your options aren't as constrained as think. Then you need to find a way to deliver what your company, and your management, really needs.
I have no way to assess if your team is mature enough for automation or not. But if your assessment tells you that you aren't, you need to think about a process that gets you mature enough as quickly as necessary, and present plan that to management. You might need to start changing parts of your SDLC, your estimates, your scheduling, your workload, etc. Sometimes small steps are the start of a great process.
Great questions, Priya, and good luck! Check back in with us once you've had a chance to discuss this with your management - I'd love to hear how things go.
Do you have questions? Use the new "ASK ALL THINGS" widget over on the right-hand panel. Send me questions about anything:
- about the testing profession
- about test automation
- about bug tracking
- about being a Manager
- about testing and QA jobs
- about quality
- anything!
Ask All Things!
This article originally appeared in my blog: All Things Quality
|
My name is Joe Strazzere and I'm currently a Director of Quality Assurance. I like to lead, to test, and occasionally to write about leading and testing. Find me at http://AllThingsQuality.com/. |
