Prepare your QA’s for Continuous Delivery transition

Continuous Delivery (CD) as a concept has been there for several years now, many enterprises are trying to adopt Continuous Delivery and offer that competitive advantage to the business. Wondering what’s the competivie advantage provided to the business? Take a look at this short post to understand the difference between CI vs. CD vs. CD. In essence, Continuous Delivery attempts to keep the code production ready with every single change and expect business to PULL the latest business value addition that their engineering has been working so hard. It’s a Blessing In Disguise, if both product and technology can understand and implement.

In this journey, your whole team will go thru variety of cultural and technical changes. One of the most critical rejig should be around the Quality side of the house and this post is an effort to share some of my exposure, experience about preparing and transitioning your QA’s to be Agile Team members.

I’m positive everyone started practicing Scrum or whatever works for them. However, look closely and see how the work is getting done. Meaning, how a story is developed and delivered.

How many streams of work happens here?

How many teams does it span across?

How different stream of work is being backlogged and managed?

does it look something like this ..?

Separate Quality teams

If we carefully look at the above picture, there are atleast 4 streams of work (Development, Test Automation, Perf Automation, Security testing and Ops). Streams of work is not the problem. But many organizations would have either outsourced parts of these to some other service provider or created internal Center Of Excellence to help product teams. Product teams consider themselves as just “developers”. This might have helped the business until yesterday, but wouldn’t work for future.

Given the situation, these streams of work is possibly managed by different parts of the organization. Perhaps, each organization involved here might have adopted Agile, running sprints, backlogs, daily standups, retro etc but not as ONE team from user story thru release. This could potentially cause several issues, specifically, development team would throw the bits over the wall and move on. Automation team wouldn’t have enough context to verify the change in the most efficient manner. Sometimes, build might wait for QA’s availability and similar concerns with Performance and Security. Overall, it would slow down the progress, quality would suffer, lots of back and forth between these teams etc. If we want to keep every single change production ready, all the necessary streams of work has to happen part of the story without any delay. Everyone must march towards the same goal.

This is one of the remarkable changes to happen. Seperate Quality teams (Functional test automation, performance automation, security etc) must go away and cross functional teams should be nurtured. No doubt that every stream of work is a specialty job, driven by passion. Can’t expect an iOS developer to be an automation guy to puppteize our environment creation. Can’t expect the automated tester to be an equvalant developer and so on..However, having essential experts part of the team is essential to derliver the work. Everyone will be driving towards one sprint goal including Quality experts.

  • Ex.QAs are equal team members passionate about Quality just like the other JavaScript enthusiast in the team.
  • Should participate in all team ceremonies and act as the Quality evangielist for the product.
    • Especially, play the vital role in sprint planning, fight for necessary quality work part of the story, extend the DoD and hence work towards true DONEness of each story.
    • Pair with the developer and help identifying bugs before the build is out.
    • Follow BDD (or anyother approach), help covering all possible business scenarios thru appropriate automation (unit testing, api testing, gui testing)
  • With increased understanding about the product development and background, minimize number of automated test cases, maximize automation reliability and coverage
  • Integrate automation with Continuous Delivery pipeline and enable fastest possible feedback for everyone in the team
  • Continuously refactor automation and keep up the value
  • Mentor and educate other team members on quality principles and motivate everyone

Things to avoid

  • Separate Automation backlog
  • Separate QA, Perf work, org structure
  • Separate QA tools. Go with developer friendly tools to gain help, guidance from other team members and also motivate other team members to participate and drive automation
  • Running automation separate from pipeline (nightly, weekly, from tester’s laptop..)
  • Filing bugs. When something doesn’t work as expected, go the extra mile, learn to analyze and and work with the PO to place them appropriately in the backlog. May be, submit a pull request with a fix. Trust me, your team mates will respect PR more than the bug.

Overall, QAs could become more prominent than the past by adapting the change, being part of the product development end-end and quality evagelist. Overtime, every user story will contain all necessary tasks including manual and automated test to complete the story and keep it production ready. Overtime, transition might look like this but long term commitment is necessary for success.

Advertisements

4 thoughts on “Prepare your QA’s for Continuous Delivery transition

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