How to Reorg Your Testing Team Through an Agile Transformation

The pace of business is moving faster than ever and in order to keep up with the speed, software developers have been forced to shift their methodology. The traditional “waterfall” method is being displaced by “agile.” According to VersionOne’s State of Agile survey, 95% of companies reported that their organizations practice some form of agile. Which means they’re working and releasing software at a faster pace than ever before.

This move to agile has created some significant challenges for software testers who need to balance speed with quality. How can we deliver software faster than ever, without risking releasing code with poor quality?

The agile approach has led to big changes in the people, processes and tools that organizations use to both develop and test software. High growth companies like Atlassian are able to make software that has changed the landscape of software development in a seemingly impossible time frame. Founded by a couple of twenty year-olds in 2002, today they have over 40,000 customers and recently went public with a $6 billion valuation.

While most organizations have now adopted agile, they have focused solely on development and failed to look at their testing team. Are they agile? If your answer is no, then you are not fully embracing agile, and you’re likely to experience some pains from the broken framework.

If you are looking to learn more about the people, process and tools to make your transformation successful, I encourage you to check out our recent webinar with Clearvision – Agile Transformation: People, Process and Tools to Make Your Transformation Successful.

“But my testing team can’t go agile.”

Ideally everyone wants to be fully agile, but a lot of companies say they can’t because they don’t have the right people in place or their testers can’t get involved in the development process.  Innovative companies are shifting their architecture to independent microservices written using more accessible languages like Ruby and Python.

In doing so, teams can make changes independent of other parts of the  product, and non technical employees can understand more of what is going on in the product.  This shift will allow teams to work independently and collaborate closely as a unit, but it will not happen overnight. I recommend starting with one project and slowly evolving.

Below are some tips to help prepare your testing team to go agile.

1) Shift to Embedded Testers

Getting quality integrated into product teams is an essential part of agile success, especially in scrum.  Including an embedded tester(s) on your agile teams is one of the easiest ways to make sure testing gets the focus it deserves.

Agile needs to happen quickly, which means you need to have teams that can work fast by being able to quickly pivot and reprioritize projects.  When I say “Embedded Tester” I am implying that you take a member of a large Quality Assurance team and place them into a team of programmers, much like dropping a reporter into a military unit.

In waterfall, you typically have a large team of testers that work across all the products, and the prioritization queue is large. It can provide a roadblock to coded features ready to be tested and released. When you have embedded testers, each tester works with a group of programmers on separate initiatives, making prioritization up to that small team, and fast.

Here is an example: you implement qTest. 50 testers focus on manual, 50 testers on automation. When you shift towards agile, it is common to shift towards scrum teams, made up of a scrum master (product owner), 3 developers, a business analyst, DevOps, and one or two testers (potentially a mix of automated and manual).  However, instead of leveraging a tester in a huge group of testers, your tester is already in your team.

Your tester will therefore be more knowledgeable about your product, and instead of being good at one facet of testing, they have a broader testing skill set.  This embedded tester focuses on one product, module or functionality within a broader skill set. See the image below for a rough sketch.

2) Embrace Different Types of Testing

On the manual side

The traditional way to do manual testing includes creating test plans for weeks or even months, then creating test cases for several more weeks.  After the software is developed, but before it is deployed, test validation happens – this often causes a bottleneck in the process.

If you are developing small sets of features rapidly, you want to quickly deploy to get the software into your customers hands as fast as possible.  By embracing exploratory testing, you will be aligning manual testing to be as agile as possible and making the most of the manual testing resources you already have.

On the automation side

There is a need is to be more collaborative so more developers and testers can contribute to the automated test coverage.  Agile needs collaboration to be successful.

So we need to break down these walls – developers are the most able to impact the quality of the code, and so it doesn’t make sense to remove developers from testing. It’s akin to a chef that never tastes their own food! Additionally,  developers will then believe in the validity of these tests, and this insight will help them to build for testers in the future.

3) Culture

Testers are often heads down. They want their list of test cases so they can run and report back on the results; they like finding problems, but are not necessarily interested in solving them.

Agile success depends on a culture where there is a shift in power, so testers are seen as change agents rather than rather than as whistle blowers.

They need to take initiative. It’s time to start saying, “Here is the problem.  I think this is why, and I would propose we fix it like this,” rather than, “Here’s the problem. Go fix it.”  Testers need to grow closer to customers, understanding their needs, and closer to developers as well, to learn why they did certain things in their code.

I think this is why we see more testing moving back onshore. It’s hard to find savvy testers that can collaborate well if they are not in the same location.

A shift needs to happen in testing:

• From pure test authors or executors to more holistic test leads
• From large test silos to embedded testers in product teams
• From a culture of one team (testing) owning quality to a more cross functional view of quality

It’s time to ditch Quality Center ALM. Download the “No More Excuses” free guide to find out what you’re missing and why you should consider qTest.