Testing in Team

Welcome to the series “Leadership in testing” from software testing guru and consultant Paul Gerrard. This series is designed to help testers with years of experience, especially in Agile teams, succeed in their roles as test leaders and managers.

IN previous article we talked about how to manage the execution of a testing project. Today we will talk about the changing role of a tester in a project team and how to improve interaction with colleagues both in the office and remotely.

In recent years, testing responsibilities have become more distributed. Instead of dedicating teams to testing, teams now encourage users, analysts, developers, and testers to redistribute testing responsibilities to improve collaboration. As a result, some testing activities and responsibilities are shifting to the left.

In this article we will talk about:

Shift Left (shift testing processes to the left)

Shift-Leftor shift left, can refer to several different scenarios. It can mean that developers take on more responsibility for their own testing. It can also mean that testers become involved earlier in the project, analyzing complex requirements and providing developers with examples as part of a behavior-driven development (BDD) process.

Sometimes this may mean no testers at all, with business analysts and developers taking full responsibility for testing.

The shift to the left is not new – the mantra of testing advocates has been “test early, test often” for years. As early as 1993, it was suggested that all artifacts of the incremental process – both document and software – can (and should) be tested frequently.

Shift left is primarily intended to force thinking about testing earlier in the process.

Although the dominant approach to the life cycle at the time was the “waterfall approach”, the number or length of the phases did not matter. The underlying principle was that the sources of knowledge that guide the design and development of software should be verified.

In a phased project, this might include formal reviews. In an agile project, a tester (or developer, or business analyst, or user) might propose scenarios in which the requirement or story author is asked to think through specific examples and discuss them before any code is written.

Here are the main changes associated with the “shift left” phenomenon:

Behavior-driven development (BDD) allowed developers, users/business analysts, and testers to interact with what can be called business stories. Test-driven development (TDD) has been used by many developers for 15 years or more. Today, BDD is becoming more widely adopted because it promotes better collaboration in agile teams, as well as the introduction of BDD tools that can be used by developers. It is a simpler, test-driven approach.
Continuous delivery (CD) has been around for 5-10 years, with roots in the highly automated build and release automation approaches pioneered by large online companies. It is now used by most organizations operating online.
CD systematized and accelerated the release process through automation. But it also exposed delays in production, deployment, and infrastructure changes that were previously hidden behind slow build, test, and release processes. DevOps is a cultural shift in which developers collaborate much more closely with operations staff. New tools are now being released almost daily, and vendors are touting DevOps as “the next big thing.” It's a very hyped and dynamic situation.
SMAC, or Social, Mobile, Analytics, and Cloud, represents a change in the way businesses are managed and a systemic change in the mobile space. Big data is collected, processed, and business decisions are made based on the insights gained.

Frequent experimentation with production systems enables business innovation to be implemented “at the speed of marketing.” Experimentation underlies what has become the most important achievement of the 2010s: digital transformation.

Testing as an activity, not a role

Shift left changes the role of testers. The redistribution of testing caused by shift left makes it clear that testers are not solely responsible for testing, i.e. testers no longer own testing.

If you think about it, they never really did their own testing, but there was an unspoken understanding in the projects that no matter what the rest of the team, particularly the developers, did in testing, the testers were the ones keeping things safe. If the developers were pressed for time and cut their testing time short to get the job done, the testers were there to keep them safe.

Testing is now an activity, not a role.

Developers are adopting better testing methods and increasing the transparency of their work. Good component or unit testing has specific goals that are different from system testing (as an example). Therefore, the amount of testing at the system level can be reduced.

Properly allocating test objectives and conducting testing to achieve these objectives is the primary goal of a testing strategy. Unfortunately, until recently, developers were not effectively held accountable, so they relied on late system testing to compensate.

Shift left increases developer responsibility.

Overall, the responsibility for testing is being redistributed, so the role of the tester is changing. Testers may do less tactical testing, but their strategic contribution is increasing. Testers may have their own testing strategy, challenge requirements, consult with stakeholders, and develop closer relationships with developers to improve developer testing and test automation.

The navigator does not board the plane, but waves to the pilot as it takes off. The navigator travels by bus, separately, but slowly. Eventually, the navigator arrives at his destination, but after a while it turns out that the plane flew in the wrong direction and crashed into a mountain.

Surely the navigator would have been on the plane? Imagine pilots and navigators working together in real life.

A pilot cannot fly an airplane without a navigator. A navigator cannot fly an airplane.
The pilot and navigator agree on a flight plan before the start of the journey.
The pilot takes off and controls the plane.
The navigator monitors the course and compares it with the flight plan and/or final destination, taking into account adverse events, particularly weather.
The navigator looks for deviations, 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. Splitting developers and testers into separate teams working sequentially also doesn't make sense. However, that's what we've traditionally done for the last thirty years or so, especially on larger, longer-term projects.

Shift left redistributes the notion of testing and effectively moves it forward. Testers act as full partners with developers, just as navigators act in relation to pilots:

The tester and developer work together to compare requirements information.
Typically, a tester challenges requirements using examples (potential or actual ideas for testing).
The developer thinks about implementation, using examples to guide his design.
The tester, developer, stakeholders, users, and analysts agree on a common understanding of the requirements that is trusted.
The tester is in constant contact with the developer, discussing changing requirements, risks of failures, and how testing can show that features are working or identify failures.
The tester considers how the feature being worked on will integrate both at a technical level and at a user interaction level, and how the integration can be tested.
A tester looks beyond the current feature the developer is working on to identify future issues, risks, changes, and uncertainties.
And so on.

The developer-tester relationship just described does not happen automatically in an ideal world. It must be designed by the team. You can view each of the above actions as an intervention, but intervention is not always convenient for all parties. Give this approach the best chance of success by discussing each type of intervention with your partners at the very beginning, when you know for sure that you will have to work closely together.

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

Each type of intervention requires agreement from both parties that it is an acceptable action. To feel comfortable, each must trust the other that there are valid reasons to ask questions, raise issues, and challenge demands, or to understand each other in meetings, planning sessions, or retrospectives.

Problems of distributed and outsourced teams

The discussions above have assumed by default that everyone is working on the same team and in the same location. When a software testing team's workload is outsourced and/or offshored, several negative factors come into play. The table below lists three typical factors to consider.

*Physical (and temporal) separation*	Teams may be spread across offices, buildings, cities, countries and time zones. Communication is disrupted, channels are limited and less information is received.
*Different motivations*	The supply team works for an organization that is paid to perform testing work. Ultimately, their motivation is to make a profit. Fixed-price contracts require fast work. When deadlines and material contracts are met, there is a temptation to expand the work.
*Cultural differences*	National and cultural differences can be significant and sometimes take time to acknowledge and accommodate them.
*Company/Corporate Culture*	Corporate cultures also vary – companies tend to work best with companies of comparable size, flexibility and formality. Companies are more or less cautious when it comes to confidentiality, security and so on. Companies have different leadership styles, and the differences between government and commercial organisations also take some getting used to.
*Suppliers work under contracts*	Your supplier is not loyal to your project stakeholders or their business goals. They operate under the rules specified in their contract. If you can, make sure your contracts define all responsibilities of both parties and that the contract rewards good behavior and punishes bad behavior.