Leadership In Test: Testing As A Team

In recent years, responsibility for testing has become more distributed. Rather than dedicated teams owning testing, teams are now encouraging users, analysts, developers, and testers to redistribute responsibility for testing to support better collaboration. Therefore some test activities and responsibilities are being shifted left.

In this article, I’ll cover:

• Shift Left
• Testing As An Activity, Not A Role
• A New Role
• Agile Test Interventions
• Relationships with Developers
• Challenges of Distributed and Outsourced Teams

Introducing Shift-Left

Shift-Left, or left shift, can refer to a few different scenarios. It can mean developers taking more ownership and responsibility for their own testing. It can also mean testers get involved earlier in the project, challenging requirements and feeding examples through a Behavior-Driven Development (BDD) process to developers. 

Sometimes it can mean no testers at all (dun-dun-duuu), with BAs and developers taking full responsibility for testing.

Shift-left isn’t new—testing advocates have preached the mantra, "test early, test often" for many years. As long back as 1993, it was suggested that all artifacts in a staged process—both documentary and software—could (and should often) be tested.

Shift-Left is mostly about bringing the thinking about testing earlier in the process.

Although Waterfall was the dominant life-cycle approach at the time, the number or duration of stages are not what is important. The underlying principle was that the Sources of Knowledge that provide direction for the design and development of software should be challenged or tested. 

In a staged project, this might involve formal reviews. In an Agile project, the tester (or developer or BA or user) can suggest scenarios that challenge the author of a requirement or story to think-through concrete examples and discuss them before any code is written.

These are the main changes involved in the shift-left phenomena:

1. The Behavior Driven Development (BDD) approach has allowed developers, users/BAs, and testers to engage around what might be called business stories. Test-Driven Development has been used by many developers for 15 or more years. Today, BDD is being adopted more widely because it encourages better collaboration in agile teams as well as introducing BDD tools that can be used by developers. It is an easier Test-First approach.
2. Continuous Delivery (CD) has been around for 5-10 years and its roots are in the highly automated build and release automation approaches pioneered by large online businesses. It is now adopted by most organisations with an online presence.
3. CD systematised and accelerated the release process through automation. But it also highlighted the delays in production, deployment and infrastructure change that had previously been masked by slow build, test and release processes. DevOps is a cultural mind-set change whereby developers collaborate much more closely with operations staff. Right now, new tools appear almost daily and vendors promote DevOps as the 'next big thing'. It is a very hyped and dynamic situation.
4. SMAC, or Social, Mobile, Analytics and Cloud represents a shift in the way organisations are managing business and systems change in the mobile space. Experimentation in business, implemented as production systems’ changes, are monitored at a detailed level. The "Big" data captured is processed and business decisions are made based on the analytics obtained.

Frequent experimentation with production systems enables business innovation 'at the speed of marketing'. Experimentation is at the heart of what was the most important bandwagon of the 2010s – Digital Transformation.

Join our Newsletter

Discover how to deliver better software and systems in rapidly scaling environments.

• Your email*
• By submitting this form you agree to receive our newsletter and occasional emails related to the CTO. You can unsubscribe at anytime. For more details, review our Privacy Policy. We're protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.
• Comments
  This field is for validation purposes and should be left unchanged.

Testing as an Activity, Not a Role

Shift-left changes the role of testers. The redistribution of testing triggered by the shift-left approach makes it clear that testers are not solely responsible for testing i.e. testers don’t own testing anymore. 

If you think about it they never really did own testing, but there was a tacit understanding in projects that whatever the rest of the team, in particular developers, did in testing, the testers provided a safety-net. If developers were squeezed on time and reduced their testing to deliver, the safety-net was provided by the testers.

Testing is now an activity, not a role.

Developers are adopting better test practices and visibility into their work. Good component-level or unit testing has specific goals distinct from system testing (as an example). Therefore the scope (or amount) of system-level testing can be reduced. 

The correct distribution of testing goals, and testing to meet those goals, is the primary purpose of the test strategy. Unfortunately, until recently, developers were not held effectively accountable, so they relied on late system testing to compensate.

Shift-left makes developers more accountable.

Overall, the responsibility for testing is redistributed so the tester’s role changes. Testers might do less tactical testing, but their strategic contribution increases. Testers might own the test strategy, they challenge requirements, consult with stakeholders, and forge a closer relationship with developers to support better developer testing and test automation.

A New Role

Shift-Left implies that whenever it is possible to provide feedback that will help the team to understand, challenge and improve goals, requirements, design or implementation – that feedback should be provided. 

Users, BAs, developers, and the entire software team should be ready to exchange feedback in this way. Sometimes there is resistance, but the overall aim is to run a better, more informed project—that's all.

The easiest way to summarise this behavior is, 'get involved early'—as early as possible. Engage in the discussion and collaborate on ideas, requirements, and at every stage where the outcome of that stage has a bearing on the value of the final deliverable of the project. 

Put simply, the tester challenges sources of knowledge, whether these sources are stakeholders, users, developers, business stories, documents, or precedents.

The most common approach is to challenge through example. At all stages, these examples can be regarded as tests. They might be discarded quickly after use or be codified into test automation or manual checks. These examples could just be used tactically to point out flaws in peoples' thinking, or be provided to developers, say, as ideas or seeds for developer tests. They might also be used as coaching aids to show users or developers how better tests can be created.

Think of your software project as a knowledge acquisition process. This knowledge is gathered throughout the project and often evolves over time. The goal of shift-left is to assure this knowledge through challenge and testing close to its source, and to ensure where possible that it is trusted before it is frozen in code.

Shift-Left takes the test-first philosophy further. Agile has always promoted collaboration and rapid feedback—shift-left can be viewed as a concerted rapid-feedback approach. If your team is adopting a shift-left approach to testing, having the right tools can make all the difference. Check out our curated list of software testing tools to find the best fit for your team.

Agile Test Interventions

The shift-left approach is fundamental to a test strategy for agile projects. In an agile context, test strategy can be viewed as a series of test interventions. There are critical moments in all projects where opportunities to gather and give feedback present themselves. The tester needs to focus on these critical moments and be ready to contribute at those times.

In your own projects, you need to identify critical moments where intervention is possible and identify the choices you can make when testing as a team. For example, should the tester write unit tests for developers, provide examples to get them started, or coach them to improve their testing ability? Only you and your new software testing team can decide this.

We’ll use a typical Scrum process to demonstrate how test interventions can be positioned in the Scrum approach. Interventions occur at either a project (or release) level, or at the level of a sprint. The diagram below shows a project-level view and the five key interventions.

Story challenge and story definition are where the tester validates a user story and proposed acceptance criteria for a story, respectively. Integration tests check that new features link correctly with other features and the system as a whole. System and user (acceptance) tests are conducted as appropriate.

A project usually has multiple sprints and the four sprint interventions are shown in the diagram below. The daily stand-up is an opportunity to report progress, raise concerns, identify risks or discuss questions raised and answers received during the sprint. 

Story refinement and contributions to developer testing are day-to-day activities that occur as part of discussions with users, analysts and developers. The tester incorporates developer and new system tests into a growing collection of tests to be automated.

In the table below, you can see a tabular summary of interventions by testers. Your process might be different, or based on Scrum with variations, but the table identifies typical intervention types in a typical Scrum process. You might have more or less interventions active at different points in your own unique process.

I suggest you identify the critical moments, propose your contribution and negotiate with your team. You offer more test leadership and guidance rather than volunteering simply to take on responsibility for the testing work. Taking this approach will make it much easier to demonstrate your value to the team, but the team might not need as many testers.

Relationships With Developers

In some organisations, the relationship between developers can be mistrustful, blameworthy and antagonistic. At worst, the relationship is toxic: developers don’t test much at all and testers are regarded as the servants of developers. Testers adopt what might be called co-dependent behaviors and act like victims. This situation is exactly what the shift-left approach aims to avoid.

There are many metaphors that have been used to describe a good developer-tester relationship. We’ll use a pilot-navigator style of working to illustrate how the comparable developer-tester relationship can work. But first, let’s look at a dysfunctional situation.

The navigator doesn’t get on the plane, but waves to the pilot as they take off. The navigator travels by bus, separately but slowly. Eventually, the navigator arrives at the destination, but, after some time, the plane is found to have flown in the wrong direction and crashed into a mountain.

Surely the navigator should have been on the plane? Imagine how pilots and navigators work together in reality.

• The pilot cannot fly the plane without a navigator. The navigator cannot fly the plane.
• The pilot and navigator agree on the flight plan before the journey begins.
• The pilot takes off and flies the plane.
• The navigator tracks the course and compares it to the flight plan and/or final destination taking into account adverse events, in particular the weather.
• The navigator looks for variances, plots a new course, and notifies the pilot who makes adjustments to the flight path.
• And so on.

The pilot/navigator relationship is comparable to the programmer/tester relationship. Separating the developers and testers into separate teams working sequentially makes no sense either. Yet that is what we have conventionally done for the past thirty years or so – particularly in larger, longer-term projects.

Shift-left redistributes the thinking about testing, and effectively brings it forward. Testers act as full partners to the developers, just like navigators do with pilots:

• The tester and developer jointly collate information on requirements.
• Typically, the tester challenges requirements through examples (potential or actual test ideas).
• The developer thinks about implementation, using examples to provide direction for their design.
• The tester, developer, stakeholders, users and analysts agree on a shared understanding of a trusted requirement.
• The tester is in constant communication with the developer, discussing requirements change, risks of failure, and how testing can show features working or exposing failures.
• The tester looks at how the feature being worked on will integrate at both a technical and user-journey level and how integration can be tested.
• The tester looks outside the immediate feature the developer is working on to identify future challenges, risks, changes and uncertainties.
• And so on.

The ideal-world developer-tester relationship just described doesn’t happen automatically. It has to be worked out by the team. You can think of each of the activities above as interventions, but interventions are not always comfortable for all parties. Give this approach the best chance of succeeding by discussing each intervention type with your partners at the very beginning – when you first know that you’ll be working closely together.

Interventions, like good user stories, are triggers for conversations.

Each intervention type requires assent from both sides that it is a valid thing to do. To be comfortable, each has to trust the other that there is a good reason for asking questions, raising issues, and challenging requirements or understanding in stand-up meetings, planning sessions or retrospectives.

Challenges of Distributed and Outsourced Teams

In the discussions above, it’s been tacitly assumed everyone works in the same team and is co-located. When software testing team workload is outsourced and/or offshored, several negative factors come into play. The table shows three typical factors to consider.

Physical (and temporal) Separation	Teams can be distributed in an office, different buildings, towns, countries, and time zones. Communication is disrupted, the channels are constrained and less information flows.
Different Motivations	The supplier team works for an organisation that is being paid to do the testing work. Ultimately, their motivation is to make a profit. On fixed-price contracts, the pressure is to work quickly. On-time and materials contracts, the temptation is to spin out the work.
Cultural Differences	National, cultural differences can be significant. These can sometimes take time to acknowledge and make an allowance for.
Company/Corporate Culture	Company cultures differ too – companies tend to partner best with companies of comparable size, flexibility, and formality. Companies are more or less cautious when it comes to privacy, security, confidentiality, and so on. Companies have different leadership styles and the difference between government and commercial organisations also takes some getting used to.
Suppliers work to Contracts	Your supplier has no loyalty to your project stakeholders or their business goals. They work to the rules specified in their contract. If you can, make sure your contracts identify all responsibilities on both sides, and that the contract rewards good behaviors and penalises bad behavior.

Some companies augment existing software testing teams to build up capabilities for larger projects, or hire specialist testing companies rather than rely on contractors or internal user staff for testing. In other situations, all development and/or testing can be handed off to suppliers. In all cases, the client company needs to manage its suppliers. This does not mean that writing a restrictive contract with severe penalty clauses will suffice.

When things go wrong, you want rapid responses and collaboration from your supplier; you don’t want them hiding behind legal clauses in contracts.

The secrets to success are:

• If you don’t manage your supplier, they will manage you (if you are not full partners, and leave the supplier to define terms, the supplier will hold all the cards).
• The goal is to define a good working relationship. These need to be established at all levels – stakeholder, manager as well as practitioner.
• Contracts should be worded to identify all responsibilities on both sides, with appropriate measures, thresholds, stage payments and acceptance criteria defined to encourage good behavior (on both sides of the agreement).
• Agreements should encourage openness and buy-in to the shared goal of project success.

Food For Thought

And finally, some questions to get you thinking. 

What relationship do you have as a tester with your developers? Or, if you are a developer reading this, what is your relationship with testers? Maybe ask your partners in development or testing how they would describe your relationship. Compare notes!

For software testing teams to be productive, they must communicate and collaborate.