Being a Scrum Master for Multiple Teams: Why It Happens, What It Breaks, and How to Make It Work

Being a Scrum Master for Multiple Teams – Is it possible? Can it work? and rather “How to make it work?” – In almost every organization I’ve worked with, this question eventually comes up:

“Can one Scrum Master handle multiple teams?” And more often than not—the answer is already assumed to be yes.

Not because it’s ideal. But because it feels practical… It seems more efficient

Let’s be clear about why this model exists before we jump into whether it works.

Why Organizations Assign One Scrum Master to Multiple Teams

In my experience across large agile transformations, this decision usually comes from one (or more) of these reasons:

1. Budget Constraints

Agile transformations are often expected to be “lean.”

So instead of hiring one  Scrum Master per team, Organizations go for one Scrum Master for 2–3 teams. On paper, it looks efficient.

2. Misunderstanding the Scrum Master Role

This is still very common. Often leadership sees the Scrum Master as:

• A meeting facilitator
• A Jira admin
• A status tracker

Then naturally, they ask – “Why can’t one person handle multiple teams?”

3. “Senior = Can Handle More”

I’ve seen this especially with Senior Scrum Masters or Experienced Developers stepping into SM roles. The logic then becomes: “They’re experienced, so they should handle more teams.”

Experience does increase effectiveness. But it doesn’t multiply time or presence.

4. Mature Teams (At Least Perception of It)

Sometimes the assumption is: “These teams are “doing” Agile for long time now. They don’t need much support.” Sometimes this is true. But many times it’s just… optimistic.

When  Organizations Assign One Scrum Master to Multiple Teams

 – What Actually Happens?

Let me share something I’ve seen repeatedly. I once worked with an organization where one Scrum Master supported three teams.

• Team A was high-performing
• Team B was struggling with dependencies
• Team C was newly formed

Guess where most of the Scrum Master’s time went?

Team C (firefighting)
Then Team B (escalations)

And Team A? -They slowly drifted. Retrospectives became routine … Improvement slowed down ….Small issues went unnoticed

Nothing broke immediately. But growth stalled.

That’s the subtle risk in this model.

Challenges You Should Expect

Despite of all this, it is inevitable that you will have to look after more than one team at a time – Below I will give some challenges you should expect in the situation

1. Context Switching Is Real

Every team has:

• Different stakeholders and Energy
• Different maturity
• Different challenges (geographical distribution / domain complexities / cultural differences /product lifecycle stage.. etc)

Switching between them isn’t just logistical—it is a definite mental stress. And this stress builds up. Slowly but surely.

2. You May Move from Deep Impact to Surface Coverage

When you work with many teams, you run the risk of spreading yourself too thin. Then, instead of:

• Coaching behaviors
• Enabling ownership
• Driving systemic improvements

You may end up:

• Just Attending Events – and this is when the Scrum Events start to turn into mere “ceremonies”
• Focusing on the obvious, on the surface “blockers” – you now lack bandwidth to go deeper to seek and address the true impediments. Read this article to understand how (and more importantly – “why” to differentiate between blocker and impediment. 

3. Your Availability Becomes a Bottleneck

Teams don’t need you all the time. But when they do need you—it’s usually urgent. With multiple teams, you’re often:

• In another meeting
• Context-switching
• Or already overloaded

Slowly the teams start to normalize you being less available to them… and that often leads ti them accepting the waiting game.

4. Impediments Take Longer to Resolve

The real work of a Scrum Master is not in meetings or Scrum Events. It’s in:

• Following through
• Influencing stakeholders
• Removing systemic blockers

And that work suffers when attention is split.

5. Energy Drain (The Silent One)

When you are working as a Scrum master for more than one team, you are running from one meeting to other …

• Daily Scrum for Team  A
• Refinement sessions for Team B
• Reviews for Team C
• Retrospectives  for Team A

The cycle goes on and on without a break. This is where even experienced Scrum Masters start feeling stretched.

What Helps When One Scrum Master Is Supporting Multiple Teams

Scrum Guide says Scrum Master is accountable for helping the Scrum Team become more effective. When you work with multiple teams as a Scrum Master, that expectations will still remain. Below I have given some tips that help

1  Shared Product Context

If there’s one factor that significantly improves the chances of success in a multi-team setup, it’s this:  The teams are working on the same or closely related products. I’ve seen this make a huge difference.

When teams are aligned around:

• The same product
• A shared customer journey
• Interconnected features

The Scrum Master gains leverage:

• Better context retention (less mental switching)
• Stronger stakeholder alignment
• Easier dependency management
• More meaningful cross-team coaching

I once worked with three teams building different modules of the same platform.

Instead of treating them as separate units, we:

• Ran joint backlog refinement for shared features
• Aligned retrospectives occasionally to spot system-level issues
• Visualized dependencies across both teams

The result?

Less duplication
Faster decision-making
And significantly smoother flow

Compare that to supporting unrelated teams (say, one in payments and another in HR systems)—the cognitive load and disconnect are much higher.

So if organizations must assign one Scrum Master to multiple teams, product alignment is a powerful enabler.

2. Shift from “Team Scrum Master” to “System Enabler”

If you try to give equal time to all teams—you’ll struggle. Instead:

• Look for patterns across teams
• Solve problems at the system level
• Reduce recurring issues

This is where Kanban thinking (flow, bottlenecks) becomes incredibly valuable.

3. Be Intentional About Where You Go Deep

Not all teams need the same level of attention.

I usually ask:

• Which team is at risk?
• Which team can self-sustain?
• Where will my effort create the most impact?

Then I adjust accordingly.

4. Build Capability Inside the Team

One of the biggest shifts:

Stop being the center of everything.

Instead:

• Encourage team members to facilitate
• Build ownership of Scrum Events
• Develop internal champions

If everything depends on you—you won’t scale. Remember, as a Scrum Master you are accountable from Scrum Team effectiveness – and you are NOT accountable to do everything yourself

5. Make Retrospectives Non-Negotiable

If there’s one place to invest your energies deeply—it’s for Sprint Retrospectives

Even with multiple teams:

• Make every effort to keep retrospectives meaningful
• Focus on real actionable improvement items
• Follow through on actions

This is where the teams start being more effective.

6. Use Visualization to Your Advantage

Across teams:

• Visualize bottlenecks
• Highlight delays
• Track dependencies

When leaders see the system, conversations change. Teams delivering value is more important  than teams just “doing work”

7. Protect  Your Own Energy and bandwodth Ruthlessly

This is rarely talked about—but critical.

• Avoid stacking heavy sessions back-to-back – if you are not at your best, that will impact the value you bring to the table.
• Create thinking space (not just meeting space)  – create some bandwidth for your self to  just think
• Protect time for actual coaching work

You’re not effective when you’re exhausted.

Final Thoughts On Being a Scrum Master for Multiple Teams….

Being a Scrum Master for multiple teams isn’t about doing more.

It’s about:

• Establishing Synergy
• Empowering Teams
• Enabling systems
• And using context (especially shared product context) to your advantage

When done thoughtfully, this model can actually elevate the Scrum Master role from team facilitator to organizational change agent.

The post Being a Scrum Master for Multiple Teams appeared first on World Of Agile.

In an Agile testing team, testers must closely collaborate with all other team members and with business stakeholders. This has a number of implications in terms of agile tester skills must have and the activities they perform within an Agile team.

Agile Tester Skills

A tester in an Agile team should be competent in test automation, test-driven development, acceptance test-driven development, white-box, black-box, and experience-based testing.

As Agile methodology depend heavily on collaboration, communication, and interaction between the team members as well as stakeholders outside the team, testers in an Agile team should have good interpersonal skills. Below are the Agile Tester Skills –

• Be positive and solution-oriented with team members and stakeholders
• Display critical, quality-oriented, skeptical thinking about the product
• Actively acquire information from stakeholders (rather than relying entirely on written specifications)
• Accurately evaluate and report test results, test progress, and product quality
• Work effectively to define testable user stories, especially acceptance criteria, with customer representatives and stakeholders
• Collaborate within the team, working in pairs with programmers and other team members
• Respond to change quickly, including changing, adding, or improving test cases
• Plan and organize their own work

Continuous skills growth, including interpersonal skills growth, is essential for all testers, including those on Agile teams.

The Role of a Tester in an Agile Team

The role of a tester in an Agile team includes activities that generate and provide feedback not only on test status, test progress, and product quality, but also on process quality. In addition to the activities described elsewhere in this syllabus, these activities include:

• Understanding, implementing, and updating the test strategy
• Measuring and reporting test coverage across all applicable coverage dimensions o Ensuring proper use of testing tools
• Configuring, using, and managing test environments and test data o Reporting defects and working with the team to resolve them
• Coaching other team members in relevant aspects of testing
• Ensuring the appropriate testing tasks are scheduled during release and iteration planning
• Actively collaborating with developers and business stakeholders to clarify requirements, especially in terms of testability, consistency, and completeness
• Participating proactively in team retrospectives, suggesting and implementing improvements

Within an Agile team, each team member is responsible for product quality and plays a role in performing test-related tasks.

Agile organizations may encounter some test-related organizational risks:

• Testers work so closely to developers that they lose the appropriate tester mindset
• Testers become tolerant of or silent about inefficient, ineffective, or low-quality practices within the team
• Testers cannot keep pace with the incoming changes in time-constrained iterations
• To mitigate these risks, organizations may consider variations for preserving independence.

The Role of a Tester in a Scrum Lifecycle

Throughout this study content, general reference has been made to Agile methods and techniques, and the role of a tester and agile tester skills within various Agile lifecycles. This subsection looks specifically at the role of a tester in a project following a Scrum lifecycle .

Teamwork

Teamwork is a fundamental principle in Agile development. Agile emphasizes the whole-team approach consisting of developers, testers, and business representatives working together. The following are organizational and behavioural best practices in Scrum teams:

• Cross-functional: Each team member brings a different set of skills to the team. The team works together on test strategy, test planning, test specification, test execution, test evaluation, and test results reporting.
• Self-organizing: The team may consist only of developers, but ideally there would be one or more testers.
• Co-located: Testers sit together with the developers and the product owner.
• Collaborative: Testers collaborate with their team members, other teams, the stakeholders, the product owner, and the Scrum Master.
• Empowered: Technical decisions regarding design and testing are made by the team as a whole (developers, testers, and Scrum Master), in collaboration with the product owner and other teams if needed.
• Committed: The tester is committed to question and evaluate the product’s behavior and characteristics with respect to the expectations and needs of the customers and
• Transparent: Development and testing progress is visible on the Agile task board.
• Credible: The tester must ensure the credibility of the strategy for testing, its implementation, and execution; otherwise the stakeholders will not trust the test results. This is often done by providing information to the stakeholders about the testing process.
• Open to feedback: Feedback is an important aspect of being successful in any project, especially in Agile projects. Retrospectives allow teams to learn from successes and from failures.
• Resilient: Testing must be able to respond to change, like all other activities in Agile projects.

These best practices maximize the likelihood of successful testing in Scrum projects and agile tester skills.

The First Sprint

In the first iteration of the Scrum many preparation activities take place. The tester collaborates with the team on the following activities during this iteration:

• Identify the scope of the project (i.e., the product backlog)
• Create an initial system architecture and high-level prototypes
• Plan, acquire, and install needed tools (e.g., for test management, defect management, test automation, and continuous integration)
• Create an initial test strategy for all test levels, addressing (among other topics) test scope, technical risks, test types, and coverage goals
• Perform an initial quality risk analysis
• Define test metrics to measure the test process, the progress of testing in the project, and product quality
• Specify the definition of “done”
• Create the task board
• Define when to continue or stop testing before delivering the system to the customer
• First Sprint sets the direction for what testing needs to achieve and how testing needs to achieve it throughout the sprints.

Integration

In Agile projects, the objective is to deliver customer value on a continuous basis (preferably in every sprint). To enable this, the integration strategy should consider both design and testing. To enable a continuous testing strategy for the delivered functionality and characteristics, it is important to identify all dependencies between underlying functions and features.

Test Planning

Since testing is fully integrated into the Agile team, test planning should start during the release planning session and be updated during each sprint. Test planning for the release and each sprint should address the issues.

Sprint planning results in a set of tasks to put on the task board, where each task should have a length of one or two days of work. In addition, any testing issues should be tracked to keep a steady flow of testing.

Agile Testing Practices in scrums

Many practices may be useful for testers in a agile scrum team, some of agile tester skills include:

• Pairing: Two team members (e.g., a tester and a developer, two testers, or a tester and a product owner) sit together at one workstation to perform a testing or other sprint task.
• Incremental test design: Test cases and charters are gradually built from user stories and other test bases, starting with simple tests and moving toward more complex ones.
• Mind mapping: Mind mapping is a useful tool when testing. For example, testers can use mind mapping to identify which test sessions to perform, to show test strategies, and to describe test data.

The post Agile Tester Skills appeared first on World Of Agile.

Some of the options while deciding the strategy for structuring of Agile Testing teams are as follows

• Testers Embedded into the Development Teams : Independent testers are often more effective at finding defects. In some Agile teams, developers create many of the tests in the form of automated tests. One or more agile testing engineer may be embedded within the team, performing many of the testing tasks. However, given those testers’ position within the team, there is a risk of loss of independence and objective evaluation.
• Testers on a on-demand basis : Other Agile teams retain fully independent, separate test teams, and assign testers on-demand during the final days of each sprint. This can preserve independence, and these agile testing engineers can provide an objective, unbiased evaluation of the software. However, time pressures, lack of understanding of the new features in the product, and relationship issues with business stakeholders and developers often lead to problems with this approach.
• Independent Test Teams : A third option is to have an independent, separate test team where testers are assigned to Agile testing teams on a long-term basis, at the beginning of the project, allowing them to maintain their independence while gaining a good understanding of the product and strong relationships with other team members. In addition, the independent test team can have specialized testers outside of the Agile testing teams to work on long-term and/or iteration-independent activities, such as developing automated test tools, carrying out non-functional testing, creating and supporting test environments and data, and carrying out test levels that might not fit well within a sprint (e.g., system integration testing).
• Testing in case of multiple large Agile Teams and Independent Test Teams : Organizations may plan on having independent testing teams for large implementations involving larger number of teams. It is therefore important to integrate across scrums so that the testing team sees a fully integrated version at all times instead of working on versions which may work for a particular functionality but may not work well if integrated with other teams. Principles of Continuous Integration are particularly useful in such an approach. Doing a regular Scrum of Scrum meetings across development teams and testing teams is also a useful technique which may help in independently assuring quality.

• Applications where Requirements are Fluid (Mobile Applications, Internet Applications) :

Where the requirements are fluid (e.g. Mobile Application Development, Internet websites etc), the obvious choice of most customers is to go for Agile Development Methodology.

To speed up testing, it is worth taking a N+1 approach as shown in the diagram below. In this approach, Functional testing is done (manually) along with the development team. However, the functional testing done manually is automated in the following sprint (N+1). This makes it possible to have a fully updated Regression Test Suite. This Regression Test Suite will be useful in performing the functional testing in the subsequent sprints.

• Large Enterprise Applications:

For Large Enterprise Applications, upfront planning and design is generally done in a waterfall way. Thus a detailed design and detailing of all important features is available upfront before the implementation starts.

However, in such situations also, where the requirements and known upfront (Large Enterprise Applications) Customer may still prefer Agile Development for various reasons

o   Customer may still like to see incremental deliverables instead of a big-bang delivery.

o   Agile gives the customer ability to Inspect and Adapt based on what they see.

o   In requirements may end up changing due to various needs of the market or how the market evolves over time.

o   Risk of the requirements fluidity may be high, while it’s a perception that the requirements are known upfront

In such situations following are the things which could be done upfront to create a more effective deliverable

o   Automating the Acceptance Test suites and providing the same to development upfront to create an environment of preventive testing rather than reactive testing. The focus here is on prevention rather than on finding defects.

o   A More thorough acceptance test suite could be written in close coordination with the business teams.

o   The testing team now focuses on keeping the acceptance test suites updated all the time based on changes in the requirements.

o   The testing team will now get more time to focus on Exploratory testing and finding defects that the machine may not be able to do.

o   Thus a right mix of Automated and Manual testing could be used by the independent testing teams.

The post Organization Options for Agile Testing appeared first on World Of Agile.

Many kinds of testing exist. Brian Marick came up with the Agile Testing Quadrant as shown below.

In this diagram, he categorized tests according to whether they are business facing or technology facing and whether they support the development process or are used to critique the project.

Q1-Technology Facing Tests that Support the Development Process

These automated tests are written and maintained exclusively by developers. There are three kinds of tests that falls into this category : Unit tests, Component tests and Deployment tests.

Q2-Business-Facing tests that support the Development Process

The tests in this quadrant are more commonly known as functional or acceptance tests. Acceptance testing ensures that the acceptance criteria for a story are met. Acceptance tests should be written and ideally automated before development starts on a story. Acceptance tests, like acceptance criteria, can test all kinds of attributes of the system being built, including functionality, capacity, usability, security, modifiability, availability and so on.

Q3-Business Facing Tests that Critique the Project

These manual tests verify that the application will in fact deliver to the users the value they are expecting. This is not just a matter of verifying that the application meets its specifications, it is also about checking that the specifications are correct.

Q4- Technology-Facing Tests that critique the Product

Acceptance testing comes in two categories : Functional and Non-Functional tests. By Non-Functional tests, it means that all the qualities of the system other than its functionality, such as capacity, availability, security and so forth. This quadrant covers the Non-Functional tests which are equally important for the success of the product.

The post Agile Testing Quadrant appeared first on World Of Agile.

A software system may be tested at different levels. Typical test levels are, from the base of the pyramid to the top, unit, integration, system, and acceptance. The test pyramid emphasizes having a large number of tests at the lower levels (bottom of the pyramid) and, as development moves to the upper levels, the number of tests decreases (top of the pyramid). Usually unit and integration level tests are automated and are created using API-based tools. At the system and acceptance levels, the automated tests are created using GUI-based tools. The test pyramid concept is based on the testing principle of early QA and testing (i.e., eliminating defects as early as possible in the lifecycle).

Test Levels

Test levels are test activities that are logically related, often by the maturity or completeness of the item under test.

In sequential lifecycle models, the test levels are often defined such that the exit criteria of one level are part of the entry criteria for the next level. In some iterative models, this rule does not apply. Test levels overlap. Requirement specification, design specification, and development activities may overlap with test levels.

In some Agile lifecycles, overlap occurs because changes to requirements, design, and code can happen at any point in an iteration. While Scrum, in theory, does not allow changes to the user stories after iteration planning, in practice such changes sometimes occur. During an iteration, any given user story will typically progress sequentially through the following test activities:

• Unit testing, typically done by the developer
• Feature acceptance testing, which is sometimes broken into two activities

^o    Feature verification testing, which is often automated, may be done by developers or testers, and involves testing against the user story’s acceptance criteria

o   Feature validation testing, which is usually manual and can involve developers, testers, and business stakeholders working collaboratively to determine whether the feature is fit for use, to improve visibility of the progress made, and to receive real feedback from the business stakeholders

Example of Feature acceptance testing:

As a new depositor, in order to protect my money, I want to save my money a bank account. Since, I am a new depositor; my default opening balance in a new bank account is INR 0.00

In addition, there is often a parallel process of regression testing occurring throughout the iteration. This involves re-running the automated unit tests and feature verification tests from the current iteration and previous iterations, usually via a continuous integration framework.

In some Agile projects, there may be a system test level, which starts once the first user story is ready for such testing. This can involve executing functional tests, as well as non-functional tests for performance, reliability, usability, and other relevant test types.

Agile teams can employ various forms of acceptance testing. Internal alpha tests and external beta tests may occur, either at the close of each iteration, after the completion of each iteration, or after a series of iterations. User acceptance tests, operational acceptance tests, regulatory acceptance tests, and contract acceptance tests also may occur, either at the close of each iteration, after the completion of each iteration, or after a series of iterations.

The post Agile Test Pyramid appeared first on World Of Agile.

Agile projects often involve heavy use of automated tools to develop, test, and manage software development. Developers use tools for static analysis, unit testing, and code coverage. Developers continuously check the code and unit tests into a configuration management system, using automated build and test frameworks. These frameworks allow the continuous integration of new software with the system, with the static analysis and unit tests run repeatedly as new software is checked in.

The tools usage in Agile projects must supplement people interaction but should not replace it. In Agile software development projects, there are many tools that are being used in various situations. Few examples of tools are: Developers use tools like SONAR for static analysis and code coverage, JUnit for code coverage. Developers also use configuration management tools like SVN, where they can check in source code, unit tests. The configuration management tool will compile and build the code with test frameworks.

Examples of few tools that are commonly used with build automation are:

• Make
• Ant
• Maven
• Gradle
• Jenkins
• JUnit
• Subversion
• GIT

These common toolset and build scripts allows for customization when needed, giving their customers flexibility to configure the tools to their individual needs. They support centralized controls and reporting, decentralized execution (Identity-based security). They can be easily deployed on the existing infrastructure where possible.

These automated tests can also include functional tests at the integration and system levels. Such functional automated tests may be created using functional testing harnesses, open-source user interface functional test tools, or commercial tools, and can be integrated with the automated tests run as part of the continuous integration framework. In some cases, due to the duration of the functional tests, the functional tests are separated from the unit tests and run less frequently. For example, unit tests may be run each time new software is checked in, while the longer functional tests are run only every few days.

One goal of the automated tests is to confirm that the build is functioning and installable. If any automated test fails, the team should fix the underlying defect in time for the next code check-in. This requires an investment in real-time test reporting to provide good visibility into test results. This approach helps reduce expensive and inefficient cycles of “build-install-fail-rebuild-reinstall” that can occur in many traditional projects, since changes that break the build or cause software to fail to install are detected quickly.

The goal of automated tests may also be to check the build function and its stabilization. Any build failure immediately warrants an action from the developers and testers. This can quickly help other developers not to get delayed due to build failure.

There are 3 kinds of builds, namely Fast builds, Full build, and Push-To-QA build.

• Fast build is triggered when it detects the source code changes, and it also detects complication, unit testing or packaging errors. It also performs the static code analysis and provides a web based build report on the code coverage. This build can be customized as per the team
• Full Build is scheduled usually twice a day, it is same as fast build, and it deploys into DEV server
• Push-To-QA build is scheduled On-demand and it deploy the latest DEV build to QA

Automated testing and build tools help to manage the regression risk associated with the frequent change that often occurs in Agile projects. However, over-reliance on automated unit testing alone to manage these risks can be a problem, as unit testing often has limited defect detection effectiveness. Automated tests at the integration and system levels are also required. There are frequent changes to software/application in Agile development, effective use of build tools and automated testing helps in managing and minimizing risks related to regression issues.

The post Configuration Management appeared first on World Of Agile.

Managing Regression Risk with Evolving Manual and Automated Test Cases

In an Agile project, as each iteration completes, the product grows. Therefore, the scope of testing also increases. Along with testing the code changes made in the current iteration, testers also need to verify no regression risk has been introduced on features that were developed and tested in previous iterations. The risk of introducing regression in Agile development is high due to extensive code churn (lines of code added, modified, or deleted from one version to another). Since responding to change is a key Agile principle, changes can also be made to previously delivered features to meet business needs. In order to maintain velocity without incurring a large amount of technical debt, it is critical that teams invest in test automation at all test levels as early as possible. It is also critical that all test assets such as automated tests, manual test cases, test data, and other testing artifacts are kept up-to-date with each iteration. Regression Risk is highly recommended that all regression test assets be maintained in a configuration management tool in order to enable version control, to ensure ease of access by all team members, and to support making changes as required due to changing functionality while still preserving the historic information of the test assets.

Testers often do routine job every iteration; however, there might be excessive work load during some iteration it may be difficult to juggle around several issues. The testers at the beginning of the iteration will have to get together to prepare a test strategy to deal with the unknowns and known and proceed accordingly. They testers team should also review the tests written earlier and discuss the probably touch points on where they need to add or delete the scripts.

Because complete repetition of all tests is seldom possible, especially in tight-timeline Agile process, testers need to allocate time in each iteration to review manual and automated test cases from previous and current iterations to select test cases that may be candidates for the regression test suite, and to retire test cases that are no longer relevant. Tests written in earlier iterations to verify specific features may have little value in later iterations due to feature changes or new features which alter the way those earlier features behave.

While reviewing test cases, testers should consider suitability for automation. The team needs to automate as many tests as possible from previous and current iterations. This allows automated regression tests to reduce regression risk with less effort than manual regression testing would require. This reduced regression test effort frees the testers to more thoroughly test new features and functions in the current iteration.

It is critical that testers have the ability to quickly identify and update test cases from previous iterations and/or releases that are affected by the changes made in the current iteration. Defining how the team designs, writes, and stores test cases should occur during release planning. Good practices for test design and implementation need to be adopted early and applied consistently. The shorter time-frames for testing and the constant change in each iteration will increase the impact of poor test design and implementation practices and reduce regression risk.

Use of test automation, at all test levels, allows Agile teams to provide rapid feedback on product quality. Well-written automated tests provide a living document of system functionality. By checking the automated tests and their corresponding test results into the configuration management system, aligned with the versioning of the product builds, Agile teams can review the functionality tested and the test results for any given build at any given point in time.

Automated unit tests are run before source code is checked into the mainline of the configuration management system to ensure the code changes do not break the software build. To reduce build breaks, which can slow down the progress of the whole team, code should not be checked in unless all automated unit tests pass. Automated unit test results provide immediate feedback on code and build quality, but not on product quality.

Automated acceptance tests are run regularly as part of the continuous integration full system build. These tests are run against a complete system build at least daily, but are generally not run with each code check-in as they take longer to run than automated unit tests and could slow down code check-ins. The test results from automated acceptance tests provide feedback on product quality with respect to regression since the last build, but they do not provide status of overall product quality.

Automated tests can be run continuously against the system. An initial subset of automated tests to cover critical system functionality and integration points should be created immediately after a new build is deployed into the test environment. These tests are commonly known as build verification tests. Results from the build verification tests will provide instant feedback on the software after deployment, so teams don’t waste time testing an unstable build.

Automated tests contained in the regression test set are generally run as part of the daily main build in the continuous integration environment, and again when a new build is deployed into the test environment. As soon as an automated regression test fails, the team stops and investigates the reasons for the failing test. The test may have failed due to legitimate functional changes in the current iteration, in which case the test and/or user story may need to be updated to reflect the new acceptance criteria. Alternatively, the test may need to be retired if another test has been built to cover the changes. However, if the test failed due to a defect, it is a good practice for the team to fix the defect prior to progressing with new features.

In addition to test automation, the following testing tasks and regression risk may also be automated:

• Test data generation
• Loading test data into systems
• Deployment of builds into the test environments
• Restoration of a test environment (e.g., the database or website data files) to a baseline
• Comparison of data outputs

Automation of these regression test reduces the overhead and allows the team to spend time developing and testing new features.

The post Regression Risk appeared first on World Of Agile.

The Differences between Testing in Traditional and Agile Approaches

Testers must understand the differences between testing in traditional lifecycle models (e.g., sequential such as the V-model or iterative such as RUP) and Agile lifecycles in order to work effectively and efficiently. The Agile models differ in terms of the way testing and development activities are integrated, the project work products, the names, entry and exit criteria used for various levels of testing, the use of tools, and how independent testing can be effectively utilized.

Testers should remember that organizations vary considerably in their implementation of lifecycles. Deviation from the ideals of Agile lifecycles may represent intelligent customization and adaptation of the practices. The ability to adapt to the context of a given project, including the software development practices actually followed, is a key success factor for testers.

Testing and Development Activities

One of the main differences between traditional lifecycles and Agile lifecycles is the idea of very short iterations, each iteration resulting in working software that delivers features of value to business stakeholders. At the beginning of the project, there is a release planning period. This is followed by a sequence of iterations. At the beginning of each iteration, there is an iteration planning period. Once iteration scope is established, the selected user stories are developed, integrated with the system, and tested. These iterations are highly dynamic, with development, integration, and testing activities taking place throughout each iteration, and with considerable parallelism and overlap. Testing activities occur throughout the iteration, not as a final activity.

Testers, developers, and business stakeholders all have a role in testing, as with traditional lifecycles. They should self manage and build skills necessary in the team to make things happen (cross functional)

• Developers perform unit tests as they develop features from the user stories.
• Testers then test those features. Business stakeholders also test the stories during implementation.
• Business stakeholders might use written test cases, but they also might simply experiment with and use the feature in order to provide fast feedback to the development team.

In some cases, hardening or stabilization iterations occur periodically to resolve any lingering defects and other forms of technical debt. However, the best practice is that no feature is considered done until it has been integrated and tested with the system. Another good practice is to address defects remaining from the previous iteration at the beginning of the next iteration, as part of the backlog for that iteration (referred to as “fix bugs first”).

However, some complain that this practice results in a situation where the total work to be done in the iteration is unknown and it will be more difficult to estimate when the remaining features can be done. At the end of the sequence of iterations, there can be a set of release activities to get the software ready for delivery, though in some cases delivery occurs at the end of each iteration.

When risk-based testing is used as one of the test strategies, a high-level risk analysis occurs during release planning, with testers often driving that analysis. However, the specific quality risks associated with each iteration are identified and assessed in iteration planning. This risk analysis can influence the sequence of development as well as the priority and depth of testing for the features. It also influences the estimation of the test effort required for each feature.

In some Agile Testing practices (e.g., Extreme Programming), pairing is used. Pairing can involve testers working together in twos to test a feature. Pairing can also involve a tester working collaboratively with a developer to develop and test a feature. Pairing can be difficult when the test team is distributed, but processes and tools can help enable distributed pairing.

Testers may also serve as agile testing and quality coaches within the team, sharing testing knowledge and supporting quality assurance work within the team. This promotes a sense of collective ownership of quality of the product.

Test automation at all levels of testing occurs in many Agile teams, and this can mean that testers spend time creating, executing, monitoring, and maintaining automated tests and results. Because of the heavy use of test automation, a higher percentage of the manual testing on Agile projects tends to be done using experience-based and defect-based techniques such as software attacks, exploratory testing, and error guessing. While developers will focus on creating unit tests, testers should focus on creating automated integration, system, and system integration tests. This leads to a tendency for Agile teams to favour testers with a strong technical and test automation background.

One core Agile principle is that change may occur throughout the project. Therefore, lightweight work product documentation is favoured in Agile projects. Changes to existing features have testing implications, especially regression testing implications. The use of automated testing is one way of managing the amount of test effort associated with change.

However, it’s important that the rate of change not exceed the project team’s ability to deal with the risks associated with those changes.

Project Work Products

Project work products of immediate interest to Agile testers typically fall into three categories:

• Business-oriented work products that describe what is needed (e.g., requirements specifications) and how to use it (e.g., user documentation)
• Development work products that describe how the system is built (e.g., database entity-relationship diagrams), that actually implement the system (e.g., code), or that evaluate individual pieces of code (e.g., automated unit tests)
• Test work products that describe how the system is tested (e.g., test strategies and plans), that actually test the system (e.g., manual and automated tests), or that present test results (e.g., test dashboards)

In a typical Agile project, it is a common practice to avoid producing vast amounts of documentation. Instead, focus is more on having working software, together with automated tests that demonstrate conformance to requirements. This encouragement to reduce documentation applies only to documentation that does not deliver value to the customer. In a successful Agile project, a balance is struck between increasing efficiency by reducing documentation and providing sufficient documentation to support business, testing, development, and maintenance activities. The team must make a decision during release planning about which work products are required and what level of work product documentation is needed.

Typical business-oriented work products on Agile projects include user stories and acceptance criteria. User stories are the Agile form of requirements specifications, and should explain how the system should behave with respect to a single, coherent feature or function.

A user story should define a feature small enough to be completed in a single iteration. Larger collections of related features, or a collection of sub-features that make up a single complex feature, may be referred to as “epics”. Epics may include user stories for different development teams. For example, one user story can describe what is required at the API-level (middleware) while another story describes what is needed at the UI-level (application). These collections may be developed over a series of sprints. Each epic and its user stories should have associated acceptance criteria.

Epics can be easily broken down into user stories by slicing them vertically and they comply to INVEST criteria. Each Epic and user story contains acceptance criteria with necessary business rules and mockups attached to them.

Typical developer work products on Agile projects include code. Agile developers also often create automated unit tests. These tests might be created after the development of code. In some cases, though, developers create tests incrementally, before each portion of the code is written, in order to provide a way of verifying, once that portion of code is written, whether it works as expected. While this approach is referred to as test first or test-driven development, in reality the tests are more a form of executable low-level design specifications rather than tests.

Typical tester work products on Agile projects include automated tests, as well as documents such as test plans, quality risk catalogs, manual tests, defect reports, and test results logs. The documents are captured in as lightweight a fashion as possible, which is often also true of these documents in traditional lifecycles. Testers will also produce test metrics from defect reports and test results logs, and again there is an emphasis on a lightweight approach.

In some Agile implementations, especially regulated, safety critical, distributed, or highly complex projects and products, further formalization of these work products is required. For example, some teams transform user stories and acceptance criteria into more formal requirements specifications. Vertical and horizontal traceability reports may be prepared to satisfy auditors, regulations, and other requirements.

In some regulated agile projects, more inspection of the documentation that is being produced during the project execution may be required.

For example: Federal drug administration (FDA) projects require lot of audit reports, strategy reports and compliance reports that need to be produced during the project execution.

The post Agile Testing appeared first on World Of Agile.