A high level overview of a test environment management solution, based on the Experimentus iTEM (intelligent test environment method) offering. The module covers the governance services and the delivery and technical activities which are needed to provision and support pre-production IT environments throughout the software development life cycle.

Environment management can be implemented in many ways. How it should be done depends on several factors, including the abilities and skills available in the organisation.

Talking very generally, implementing environment management involves creating processes and procedures which define how the constituent elements of environment management will be carried out. So there will be processes and governance procedures for such activities as managing knowledge about the environments, provisioning them, managing demand, providing ongoing support, managing and resolving issues and reporting.

Discovery

But the level of complexity and breadth of these processes will depend on the number and type of environments to be managed, so before any processes are defined, a discovery exercise should normally be undertaken to understand the current environments and any existing management processes and tools. This provides information about the scale of the problem, on which recommendations can be based about the best way to manage the environment landscape.

Having gathered sufficient information, appropriate processes for control and governance can be created. These processes and controls, together with appropriate supporting tools, help to minimise the risk of encountering environment-related problems.

Another purpose of discovery is to find out what the current environment management process consists of. There is no need to re-invent the wheel if there is one already there – however, a wobbly wheel could be tightened or a broken wheel could be repaired or swapped out for an improved model. But enough of the metaphors.

Deployment

Once an appropriately simple, or complicated set of processes (in other words, the environment management service) – has been defined, it can be deployed. This is usually best not done with a big-bang approach, but by introducing new or updated procedures and tools in discrete packages over a suitably extended period.

If an external consultancy (such as Experimentus) has been employed to help define and deliver the new service, it can be introduced over time, initially by utilising the consultancy resources to run the service, and simultaneously by training in-house staff to enable a transition to run the service fully by the organisation’s own employees.

This is an important part of what Experimentus do. We can resource the centralised environment team exclusively if requested to do so, but we find it normally serves the organisation best when in-house personnel are involved and eventually take full ownership as the service is implemented and transitioned to them.

Properly conducted, test environment management helps organisations to speed up stable software releases by:

• Establishing collaboration between members of development and testing teams,
• Capturing environment demands, and establishing a simple and transparent environment utilisation procedure
• Engendering cooperation by planning and scheduling resources and controlling their lifecycles.

Ultimately, test environment management aims to streamline delivery by providing stable and correctly configured environments in which to execute tests or replicate defects.

It provides records for and accountability of environment activities. This means there is a greater ability to control and forecast usage, with the possibility of significantly increasing environment utilisation.

Having more visibility and control of environment status and configuration can reduce unplanned downtime and rework, resulting in fewer project overruns in terms of both time and budget.

Having specialist resources handling environment management reduces or removes pain points for test teams and management, allowing them to focus on their core roles – and this can also provide a cost saving around resources.

Knowing that test environments and data are being properly managed by people who know what they are doing, increases confidence in both development and test outcomes.

By employing the services of a dedicated test environment team with focused, expert resources allows rigid controls to be established, and removes the burden of environment and data management from project managers and test teams, allowing them to focus on their primary roles.

By standardising environment configuration and software release and change management processes, compliance is ensured by introducing a level of control over to what changes are made to the environment.

Managing access to environments and resolving conflicts between projects     and programs provides assurance that only approved resources have access, at the appropriate time and with the correct permissions and privileges.

Clear and effective management of assets, utilisation and costs ensures the non-production estate is as streamlined as possible.

Many of the benefits mentioned will result in a reduction of unscheduled outages and loss of testing time, which in themselves improve environment stability.

• Increased environment documentation and visibility enhances overall confidence in systems and enables provision of a high-level view for senior stakeholders
• By making critical information available, in a suitable context, to stakeholders ensures there is a level of consistency of knowledge across projects.
• A reduction of risk of deploying into production through greater control of change impacts will lead to fewer post-implementation issues.
• And effective handling of the post-project decommissioning of redundant software and hardware components leads to more effective environment cost management.

Environment management, properly conducted, is important because poor, or missing, environment management can lead to expensive consequences.

Test environments can become different from development or production environments, by having inconsistent versions of operating systems or hardware configurations and varying software versions and patches. The greater the differences, the greater the probability that the final product will have more defects.

Infrastructure assets that are inefficiently managed can result in budget spikes and may delay, or otherwise hinder, the testing process. For example, root cause analysis of incidents and defects becomes more challenging when there is misalignment of test and other environments.

It is common for test teams to clone or extract production data and use it for the purposes of testing. This approach can be time-consuming and is error-prone – and it may not meet data protection policies. Often, the process is not sufficiently change-controlled and cannot be audited.

Communication plays a critical role in all phases of the software development lifecycle. Poor communication can result in misunderstanding at all levels, including of the business requirements, and may result in failure to identify important defects.

Poorly configured defect tracking tools can themselves cause additional issues. A controlled process should be in place to manage the defect lifecycle. If this is not done, defects may be assigned incorrectly for resolution and important information missed, resulting in wasted time and resources as well as injecting additional defects at later stages.

Recent research has shown that:

• Almost a third of the effort of a project team is consumed by environment- or data-related problems,
• Testers spend, on average, one day per week identifying and resolving environmental issues (that’s effectively a 20% reduction in test resource availability)
• Over a third of environments are not properly or efficiently utilised (and the costs associated with non-productive environments can be very high, and are not “green”)

By appropriately employing good environment management processes, both the costs and time wasted as a result of these statistics and examples can be dramatically reduced.

Test environment management is something that many companies consider an unnecessary expense. When allocating project funding, it is common for test environment management either to be disregarded, or seen as a cost that should be avoided, or at least drastically reduced. This approach introduces considerable risk to the quality of projects and to their timely delivery.  Environment management is a critical process for software development and testing, and, if not conducted properly, test environments could become chaotic or unusable very quickly.

Test environment management is the set of processes defined and carried out to help in understanding the need for IT environments across the development life-cycle, establishing proactive controls to ensure the environments are provisioned and serviced in a timely manner, ensuring they are used and shared effectively, and, when no longer needed, that they are decommissioned promptly.

What is test environment management?

An effective and efficient test environment management process consists of many activities. Some of the most important include:

Managing environment knowledge

It is important to know what the IT and test environment landscape looks like. Unless the platforms and end-to-end architecture are truly understood it is difficult to manage and co-ordinate them.

Knowledge management can begin with a discovery exercise, ensuring that development, testing and production environments are sufficiently documented. This should include key configuration items such as environment groups, systems, environment instances, components, microservices, relationships, and test data. As requests for new environments are received (and as changes to existing environments are needed) these must be analysed before they are built and made available.

Provisioning environments

When a request for a new or changed environment is received, the requirements must be turned into an environment design solution based on what is in scope. Options include building new or re-configuring existing environments or sharing existing environments. Provisioning also includes determining tool requirements and setting them up, and creating and managing various artefacts for re-use and purposes related to compliance and audits.

Once created, environments must be configured and finally integrated into the overall environment landscape at the appropriate time. It may also be necessary to manage the initial provision of test data.

Providing ongoing support

After environments have been provisioned, development and test teams will require support from an environment management team. This support can include incident and issue resolution, configuration and change management, access management and general environment-related activities such as batch-running, file transfers or data roll-back operations.

Managing demand

Both development teams and software testing teams require access to specific development and test environments throughout the software development process. Often, test environments must be shared by different teams or even different projects, and a way is needed to avoid the potential resulting conflicts.

One way to do this is to have a system in place that captures and manages the demand for environment usage, including an environment booking system. The demand information collected in this way, together with planning and co-ordinating activities, can be used to help schedule and allocate resources appropriately.

Reporting and communicating

Comprehensive reporting and timely communication with stakeholders helps to keep environment management running smoothly. Useful reports can include supply and demand metrics (including forecasting), booking and change requests over time, numbers of outstanding requests, release booking status, availability of shared environments, data on current and historic configurations, upcoming maintenance downtime,  asset utilisation, actual usage and current health status.

Managing and resolving issues

Nothing in life is perfect. Things go wrong from time to time, and this is true for environments just as much as anything else. Issue management is a process that analyses unexpected environment problems, allocates them for rectification and tracks them to resolution. It should also involve some form of root-cause analysis as part of an attempt to prevent similar issues from occurring in the future.

Introduction

The main source material for this section of the course is the latest version of the Foundation document “TMMi in the Agile World” – a 45 page document containing a lot of detailed information about how the TMMi model should be interpreted for use when dealing with Agile methodologies.

TMMi and Agile are not antagonistic. The TMMi model, when applied in an Agile context, helps us keep in mind the important and useful testing practices that are often mistakenly thought of as unnecessary or overly-burdensome to Agile projects. The way to approach it is to use the lean principles of Agile alongside the best practices embodied in TMMi.

The Specific Practices of TMMi are expected components, but they, and the Goals they feed into, can still be satisfied, and even fully achieved, by employing acceptable alternatives and this applies to any testing organisation using any software development method, not just Agile ones. The traditional implementation of many of the TMMi Practices just do not apply in an Agile context, but can be covered in other ways, meeting the requirements both of TMMi and of Agile values. For example, product risk assessments in Agile projects may take a more lightweight approach than in a sequential lifecycle model.

As organisations move to more Agile methodologies, they may trim down their procedures and make processes, and the associated documentation, leaner, more efficient and effective. This can result in documentation that records what people actually do (not just a theoretical “best way of doing things”).

Improvements will usually be undertaken by small, autonomous teams. Even so, a centralised TMMi process improvement project may be beneficial, as it can help to ensure proper implementation of improvements across the organisation, where they are applicable to more than just one project. Still, the focus of improvements in an Agile context is often on continuous, localised change. So, when considering the Specific Goals in Process Area 5.3 Test Process Optimisation, the deployment of new testing technologies and test improvements do not have to be made across the whole organisation, since Agile teams can usually decide for themselves which improvements best suit their way of working.

Agile organisations, in particular, are recommended to select and implement only the Level 4 and Level 5 Practices that provide them with some benefit. In general though, when Agile approaches are implemented correctly, and in parallel with appropriate TMMi processes, the result will be effective testing practices, not their removal.

The table here summarises what the TMMi Foundation believes are the not-so-applicable Specific Practices. Remember these ones that are considered less-relevant and you should be able to answer correctly at least some of the questions in the TMMi Professional exam that relate to the Agile context.

To be absolutely clear, all other Specific Practices are considered applicable to Agile methodologies, although the way in which they achieve, in the absence of a better word, ‘compliance’, may be very different from traditional software development life cycles.

Implementation of Agile practices at TMMi Level 2

Now we will summarise the way TMMi is implemented in Agile projects, beginning at Level 2

An Agile, lean test strategy specifies, at a high-level:

The testing to be performed by the iteration teams, including:

• Test types
• Test quadrants
• Test levels to be executed
• The test approach
• How testing is organised (in other words, what testing is to be carried out by the Agile team and what by others)
• And the relationship between Agile teams and those test levels that are performed by others (such as system integration testing or beta testing)

Test performance indicators tend to focus on team and systems rather than being concentrated on testing itself. Indicators at TMMi Level 2 are mainly related to the end-results of iterations, including escaped defects, velocity and customer satisfaction ratings.

The product risk assessment process for Agile may, initially, take a lighter approach compared with what happens for a sequential methodology. Techniques such as ‘risk poker’ are used. Risk analysis is continued in iteration planning, where the whole team identifies and prioritises product risks based on a review of user stories.

Most test planning activities are performed during release and iteration planning. There will not necessarily be a test plan document, at least in the normal sense, because activities will usually be listed on a task board or in a mind-map format.

Progress is normally monitored with the combined use of task boards and daily stand-up meetings. Product quality is monitored in much the same way, with daily stand-ups being the main mechanism to perform product quality reviews and at the same time discuss and manage immediate corrective actions.

The usually separate phases of test analysis and design, test implementation and test execution, in Agile projects are performed in parallel during each iteration. Documentation is normally less detailed, and the test techniques used tend to be experienced-based or defect-based.

in Agile development, not all incidents uncovered will necessarily be recorded. The Specific Goal Manage Test Incidents to Closure only applies to those that are logged.

Test environment requirements are often specified, and even implemented, during an iteration 0, as early as possible in the development life cycle. Management and control of the environment takes place throughout the project.

Implementation of Agile practices at TMMi Level 3

Determining and planning test process improvements is usually covered in retrospectives meetings. The deployment of improvements will be conducted mainly by the Agile team itself, or organisationally with the possible involvement of a test process improver.

Specific Goal 3.2.1 Establish an Organisational Test Training Capability is fully applicable in an Agile context because Agile testers need skills specific to Agile testing as well as those required in traditional software development

Many organisations who consider themselves Agile, do not fully achieve the integration of testing with development. Often this is because their sprints or iterations are conducted more like mini V-models, where the main body of testing only commences towards the end of the iteration. This leads to testing being time-pressured, or even terminated before it is complete. For these pseudo-Agile organisations, the Specific Goal of integrating test life cycle models with development models is a definite area for improvement.

Planning, at release and iteration level, should cover all necessary testing aspects that a master plan would normally address, and so could be considered acceptable alternatives to the Specific Practices in the Goal “Establish a Master Test Plan”.

Agile projects do not usually conduct formal reviews in the ‘normal’ way of holding meetings specifically to give feedback on a product. In Agile this is achieved through the application of different review techniques such as refinement or grooming sessions on user stories, holding regular meetings to discuss work products, such as code or tests and frequent demonstration of products to customers.

Entry criteria for reviews are less likely to be relevant, but exit criteria can help to ensure that such work products as requirements are clear and testable.

Implementation of Agile practices at TMMi Level 4

Test Measurement is fully applicable to Agile projects. If measurement objectives are targeted and there are a relatively small number of key indicators it will accord with the principle of simplicity by which Agile projects try to abide.

Test measurement may well be more focused on the team or system, as opposed to testing itself.

Product Quality Evaluation is fully applicable to an Agile methodology, because setting measurable goals for product quality is little different in an Agile project to a more traditional one.

Definition-of-done may be used to define measurable goals for product quality. Features or user stories can be used to define them and acceptance criteria to make them measurable.

If quality goals are not applicable across the organisation, they can be defined as a feature or epic in a specific project

Producing early results from static testing helps to inform and possibly change the testing activities that follow. This has a perfect fit with the way Agile teams and projects work.

Implementation of Agile practices at TMMi Level 5

Agile projects tend to aim for defect prevention as part of their every-day activities. Retrospectives are used to investigate issues and to agree upon improvement actions. There are two types of defect prevention activities in Agile organisations, team level and

cross-team level. It is the cross-team level activities that are the focus of TMMi Level 5

Techniques such as cause-effect diagrams, fishbone diagrams or the 5 why’s, which are commonly used in Agile are also methods for evaluating the root causes of defects

In an Agile organisation, teams tend to be autonomous and self-managing. This means that the teams themselves decide whether or not to implement test process improvements.

Exam hints and tips

Concentrate on learning the list of specific practices that the TMMi Foundation consider to be less relevant or non-relevant. It is pretty certain you will get at least one question (and maybe two) on this particular aspect of TMMi use.

Read the summary of implementation of TMMi Specific Practices a few times, and make sure you understand why there are differences applying them in Agile projects.

Keywords

Some of the key words and phrases that will be covered in this section include:

• Acceptance criteria
• Exploratory testing
• Performance testing
• Product risk
• Quality risk
• Regression testing
• Test approach
• Test charter
• Test estimation
• Test execution automation
• Test strategy
• Test-driven development
• Unit test framework

Learning Objectives for Agile testing methods, techniques, and tools

3.1 Agile testing methods

After studying the lessons and topics on Agile testing methods you should be able to:

FA-3.1.1 (K1) Recall the concepts of test-driven development, acceptance test-driven development, and behavior-driven development
FA-3.1.2 (K1) Recall the concepts of the test pyramid
FA-3.1.3 (K2) Summarise the testing quadrants and their relationships to testing levels and testing types
FA-3.1.4 (K3) Practice the role of a tester in a Scrum team

3.2 Assessing quality risks and estimating test effort

After studying the lessons and topics on assessing quality risks and estimating test effort you should be able to:

FA-3.2.1 (K3) Assess quality risks for an Agile project
FA-3.2.2 (K3) Estimate testing effort, based on the content of an iteration and the associated quality risks

3.3 Techniques in Agile projects

After studying the lessons on the techniques in Agile projects you should be able to:

FA-3.3.1 (K3) Interpret relevant information in order to to support testing activities
FA-3.3.2 (K2) Explain to business stakeholders how to define testable acceptance criteria
FA-3.3.3 (K3) Write acceptance test-driven development test cases for a user story
FA-3.3.4 (K3) Write test cases using black box test design techniques, for both functional and non-functional behaviour, based on user stories
FA-3.3.5 (K3) Perform exploratory testing to support testing in an Agile project

3.4 Tools in Agile projects

After studying the lessons on the tools in Agile projects you should be able to:

FA-3.4.1 (K1) Recall the different tool types available to testers, according to their relevance to activities in Agile projects

According to the syllabus, lessons 3.1, 3.2, 3.3 and 3.4 of the course together are expected take at least 480 minutes to complete.

Keywords

Some of the key words and phrases that will be covered in this section include:

• Build verification test
  
  
• Configuration item
  
  
• Configuration management

Learning Objectives for fundamental Agile testing principles, practices and processes

2.1 The Differences between testing in traditional and agile approaches

After studying the section on fundamentals of Agile software development you should be able to:

FA-2.1.1 (K2) Describe the differences between testing activities in traditional and Agile projects
FA-2.1.2 (K2) Describe how development and testing activities are integrated in Agile projects
FA-2.1.3 (K2) Describe the role of independent testing in Agile projects

2.2 Status of Testing in Agile Projects

After studying the section on the status of testing in Agile projects you should be able to:

FA-2.2.1 (K2) Describe the tools and techniques used to communicate the status of testing in an Agile project, including test progress and product quality
FA-2.2.2 (K2) Describe the process of evolving tests across multiple iterations and explain why test automation is important to manage regression risk in Agile projects

2.3 Role and skills of a tester in an Agile team

After studying the section on the role and skills of a tester in an Agile team you should be able to:

FA-2.3.1 (K2) Understand the skills (people, domain, and testing) of a tester in an Agile team
FA-2.3.2 (K2) Understand the role of a tester in an Agile team

According to the syllabus, lessons 2.1, 2.2 and 2.3 of the course together are expected take at least 105 minutes to complete.

Select a link to go directly to the lesson or topic relating to the listed goal:

• Section 1: Agile Software Development
  
  • Remember the basic concept of Agile software development based on the Agile Manifesto.
    
    
  • Understand the advantages of the whole-team approach and the benefits of early and frequent feedback.
    
    
  • Recall Agile software development approaches.
    
    
  • Be able to write testable user stories in collaboration with developers and business representatives.
    
    
  • Understand how retrospectives can be used as a mechanism for process improvement in Agile projects.
    
    
  • Understand the use and purpose of continuous integration.
    
    
  • Know the differences between release planning and iteration planning, and how a tester adds value in each of these activities
    

• Section 2: Fundamental Agile testing principles, practices, and processes
  
  • Describe the differences between testing activities in traditional and Agile projects.
    
    
  • Describe how development and testing activities are integrated in Agile projects.
    
    
  • Describe the role of independent testing in Agile projects.
    
    
  • Describe the tools and techniques used to communicate the status of testing in an Agile project, including test progress and product quality.
    
    
  • Describe the process of evolving tests across multiple iterations and explain why test automation is important to manage regression risk.
    
    
  • Understand the skills (people, domain, and testing) of a tester in an Agile team.
    
    
  • Understand the role of a tester in an Agile team.
    

• Section 3: Agile testing methods, techniques, and tools
  
  • Recall the concepts of test-driven development, acceptance test-driven development, and behaviour-driven development.
    
    
  • Recall the concepts of the test pyramid.
    
    
  • Summarise the testing quadrants and their relationships to testing levels and testing types.
    
    
  • Be able to work as a tester in a Scrum team.
    
    
  • Be able to assess quality risks in an Agile project.
    
    
  • Be able to estimate testing effort based on iteration content and quality risks.
    
    
  • Be able to interpret relevant information to support testing activities.
    
    
  • Be able to explain to business stakeholders how to define acceptance criteria that are testable.
    
    
  • Be able to write acceptance test-driven development test cases for a given a user story.
    
    
  • Be able to write test cases using black-box test design techniques, for functional and non-functional behaviour, based on given user stories.
    
    
  • Be able to perform exploratory testing to support the testing of an Agile project.
    
    
  • Recall the different types of tool available to testers according to their relevance in Agile projects.
    

Overall, a certified tester foundation level – Agile tester is expected to have acquired the necessary skills to work effectively within an team in an Agile environment.

More specifically, an Agile Tester who has achieved the Foundation Level Extension – Agile Tester certification is expected to be able to:

• AFM1 Collaborate in a cross-functional Agile team being familiar with the principles and basic practices of Agile software development.
  
  
• AFM2 Adapt existing (traditional methodology) testing experience and knowledge to Agile values and principles.
  
  
• AFM3 Support an Agile team in planning the necessary test-related activities.
  
  
• AFM4 Apply relevant methods and techniques for testing in an Agile project.
  
  
• AFM5 Assist the Agile team in activities related to test automation.
  
  
• AFM6 Help business stakeholders in defining understandable (and testable) user stories, scenarios, requirements and acceptance criteria.
  
  
• AFM7 Work with other team members, using effective communication styles and channels to share information.

Intended audience

This course will be of general help and interest to professionals such as testers, test analysts, test engineers, test
consultants, test managers, user acceptance testers and software developers – as well and business representatives responsible for defining requirements for, and signing off acceptance for, a product.

It may also be appropriate for anyone who wants a deeper understanding of software testing in the Agile world, such as project managers, quality managers, software development managers, business analysts, IT directors, and management consultants.

The course will be particularly beneficial for the following testing professionals:

1. Those who have achieved in-depth testing experience in traditional methods and would
   like to know more about Agile testing.
   
   
2. Junior testers who are just commencing their testing profession, who have gained the Foundation Level certificate in software testing, and would like to understand the tester’s role in Agile environments.
   
   
3. Those who are relatively new to testing, but are required to implement test approaches, methods and techniques in their every-day employment on Agile projects.
   
   
4. Those who are experienced in their role as a developer, tester or project manager) and need more understanding and knowledge of how to perform and manage testing at all levels in Agile projects.
   

All topics in this course have learning objectives, which are given “K” levels to indicate the level of knowledge required. These are based on Bloom’s taxonomy of knowledge in the cognitive domain (ref Taxonomy of Educational Objectives, Handbook 1 – The Cognitive Domain, Bloom et al., New York 1956), illustrated below:

It is important to understand what you should take away from this course. Here, the learning objectives support the business outcomes and are used to create the examination for achieving the Certified Tester Foundation Level—Agile Tester Certification. In general, all parts of this syllabus are examinable at a K1 level. That is, the candidate will recognize, remember, and recall a term or concept. There are also some specific learning objectives at K2 and K3 levels, which are shown at the beginning of the relevant sections.

Remember (K1)

You must recognise, remember and recall a term or concept.

Understand (K2)

You are able to select the reasons, or explanations for, statements related to the topic and can summarise, compare, classify and give examples for the concept.

Apply (K3)

You are able to assess quality risks in a project, select a design technique to meet a purpose, practice a role, estimate the effort for a piece of work.

For this course, the overall learning objectives are:

• To ensure that the terminology used to describe Agile testing is understood and can be recalled and used appropriately.
  
  
• To be able to explain the concepts, approach and content of testing in Agile methodologies and to be able to apply them in the context of an organisation’s test process.

Keywords

Some of the key words and phrases that will be covered in this section include:

• Agile Manifesto
• Agile software development
• incremental development model
• iterative development model
• Software lifecycle
• Test automation
• Test basis
• Test-driven development
• Test oracle
• User story

Learning Objectives for Agile software development

1.1 The Fundamentals of Agile Software Development

After studying the section on fundamentals of Agile software development you should be able to:

FA-1.1.1 (K1) Recall the basic concept of Agile software development, based on the Agile Manifesto
FA-1.1.2 (K2) Understand the advantages of the whole-team approach
FA-1.1.3 (K2) Understand the benefits of early and frequent feedback

1.2 Aspects of Agile Approaches

After studying the section on aspects of Agile approaches you should be able to:

FA-1.2.1 (K1) Recall Agile software development approaches
FA-1.2.2 (K3) Write testable user stories in collaboration with developers and business representatives
FA-1.2.3 (K2) Understand how retrospectives can be used as a mechanism for process improvement in Agile projects
FA-1.2.4 (K2) Understand the use and purpose of continuous integration
FA-1.2.5 (K1) Know the differences between iteration and release planning, and how a tester adds value in each of these activities

According to the syllabus, section 1.1 and 1.2 of the course together are expected take at least 150 minutes to cover in a face-to-face environment.

Tools described in the Foundation Level syllabus are still relevant for testers on Agile teams. However, not all tools are used in precisely the same way in traditional and Agile methodologies. Indeed, some tools have even more applicability for Agile projects than they do for traditional projects.

Individual test management tools, requirements management tools and incident management tools (defect tracking tools) can be used by Agile projects, but some choose to employ an all-inclusive tool (an application lifecycle management or task management tool) that provides features more specific to Agile development, such as task boards, burndown charts, and user stories.

Configuration management tools are also important to testers in Agile teams due to the high number of automated tests at all levels and the need to store and manage the associated automated test assets.

As well as the the tools described in the Foundation Level syllabus, testers on Agile projects might also use the tools described in the following topics. These tools are generally employed by the whole team to help team collaboration and information sharing, which, as we have seen, are very important in Agile development.

Many of the test techniques and testing levels that apply to traditional projects can also be applied to Agile projects. For Agile projects, there are some variances in test techniques, terminologies, and documentation that should be taken into account.

One of the main objectives of testing (in all projects, Agile or traditional) is to reduce the risk of product quality problems to an acceptable (as low as possible) level prior to release.

The same types of techniques that are used in traditional projects to identify quality risks (or product risks), in other words:

• Assess the level of risk
  
  
• Estimate the effort required to reduce those risks, and
  
  
• Mitigate those risks through test design, implementation, and execution.

Having said this, because Agile projects usually have much shorter iterations and a higher rate of change, some adaptation may be required before those techniques can be used effectively.

There are certain testing practices that can be followed in every development project (Agile or not) to produce quality products. These include:

• writing tests in advance to define and document expected behaviour
  
  
• focusing effort on defect prevention, with early detection and removal, and
  
  
• ensuring that the appropriate test types are run at the right time and as part of the correct test level.

The aim should be to introduce these practices as early as possible. Testers in Agile projects are key to guiding the use of these testing practices throughout the lifecycle.

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