Chapter 3

TDD, ATDD and BDD:

These include writing tests in advance to express proper behavior, focusing on early defect prevention, detection, and removal, and ensuring that the
right test types are run at the right time and as part of the right test level.

Test-Driven Development: Test-driven development (TDD) is used to develop code guided by automated test cases.
The process for test-driven development is:

 Add a test that captures the programmer’s concept of the desired functioning of a small piece of code

 Run the test, which should fail since the code doesn’t exist

 Write the code and run the test in a tight loop until the test passes

 Refactor the code after the test is passed, re-running the test to ensure it continues to pass against the refactored code

 Repeat this process for the next small piece of code, running the previous tests as well as the added tests

The tests written are primarily unit level and are code-focused, though tests may also be written at the integration or system levels. Extreme
Programming , but is also used in other Agile methodologies and sometimes in sequential lifecycles. It helps developers focus on clearly-defined
expected results. The tests are automated and are used in continuous integration.

Acceptance Test-Driven Development: helps defines acceptance criteria and tests during the creation of user stories.

Acceptance test-driven development is a collaborative approach that allows every stakeholder to understand how the software component has to
behave and what the developers, testers, and business representatives need to ensure this behavior.

Acceptance test-driven development allows quick resolution of defects and validation of feature behavior. It helps determine if the acceptance criteria
are met for the feature.

Behavior-Driven Development: allows a developer to focus on testing the code based on the expected behavior of the software.

the tests are generally easier for other team members and stakeholders to understand.

the behavior-driven development framework generates code that can be used by developers to create test cases.

Behavior-driven development helps the developer collaborate with other stakeholders, including testers, to define accurate unit tests focused on
business needs.

The Test Pyramid: 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.

Testing Quadrants, Test Levels, and Testing Types: The testing quadrants model, and its variants, helps to ensure that all important test types and
test levels are included in the development lifecycle. This model also provides a way to differentiate and describe the types of tests to all
stakeholders, including developers, testers, and business representatives.

In the testing quadrants, tests can be:

 business (user) facing
 technology (developer) facing

In the testing quadrants, tests can be:

 supports developers/ team
 Critique the products

Quadrant Q1 is unit level, technology facing, and supports the developers. This quadrant contains unit tests. These tests should be automated and
included in the continuous integration process.
Quadrant Q2 is system level, business facing, and confirms product behavior. This quadrant contains functional tests, examples, story tests, user
experience prototypes, and simulations. These tests check the acceptance criteria and can be manual or automated. They are often created during the
user story development and thus improve the quality of the stories. They are useful when creating automated regression test suites.

Quadrant Q3 is system or user acceptance level, business facing, and contains tests that critique the product, using realistic scenarios and data. This
quadrant contains exploratory testing, scenarios, process flows, usability testing, user acceptance testing, alpha testing, and beta testing. These tests
are often manual and are user-oriented.

Quadrant Q4 is system or operational acceptance level, technology facing, and contains tests that critique the product. This quadrant contains
performance, load, stress, and scalability tests, security tests, maintainability, memory management, compatibility and interoperability, data
migration, infrastructure, and recovery testing. These tests are often automated.

The Role of a Tester

Agile emphasizes the whole-team approach consisting of developers, testers, and business representatives working together.

 Cross-functional: Each team member brings a different set of skills to the team.
 Self-organizing
 Co-located: Testers sit together with the developers and the product owner.
 Collaborative: Testers collaborate with their team members
 Empowered: Technical decisions regarding design and testing are made by the team as a whole
 Committed: The tester is committed to question and evaluate the product’s behavior and characteristics
 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.
 Open to feedback: Feedback is an important aspect of being successful in any project
 Resilient: Testing must be able to respond to change

Sprint zero is the first iteration of the project where many preparation activities take place

The tester collaborates with the team on the following activities during this iteration:

 Identify the scope of the project

 Create an initial system architecture and high-level prototype

 Plan, acquire, and install needed tools

 Create an initial test strategy for all test levels, addressing 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

Integration
In Agile projects, the objective is to deliver customer value on a continuous basis To enable this, the integration strategy should consider both design
and testing

Since testing is fully integrated into the Agile team, test planning should start during the release planning session and be updated during each sprint.
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

Assessing Quality Risks in Agile Projects

A typical objective of testing in all projects, Agile or traditional, is to reduce the risk of product quality problems to an acceptable level prior to
release.

One of the many challenges in testing is the proper selection, allocation, and prioritization of test conditions. This includes determining the
appropriate amount of effort to allocate in order to cover each condition with tests, and sequencing the resulting tests in a way that optimizes the
effectiveness and efficiency of the testing work to be done.

Risk is the possibility of a negative or undesirable outcome or event. The level of risk is found by assessing the likelihood of occurrence of the risk
and the impact of the risk.

quality risks or product risks: When the primary effect of the potential problem is on product quality.

In Agile projects, quality risk analysis takes place at two places.

  Release planning: business representatives who know the features in the release provide a high-level overview of the risks, and the whole
team, including the tester(s), may assist in the risk identification and assessment.

 Iteration planning: the whole team identifies and assesses the quality risks.

asks associated with higher risks should start earlier and involve more testing effort. Tasks associated with lower risks should start later and involve
less testing effort.

how the quality risk analysis process in an Agile project may be carried out during iteration planning is outlined in the following steps:

 Gather the Agile team members together, including the tester(s)

 List all the backlog items for the current iteration (e.g., on a task board)

 Identify the quality risks associated with each item, considering all relevant quality characteristics

 Assess e

 ach identified risk, which includes two activities: categorizing the risk and determining its level of risk based on the impact and the
likelihood of defects

 Determine the extent of testing proportional to the level of risk.

 Select the appropriate test technique(s) to mitigate each risk, based on the risk, the level of risk, and the relevant quality characteristic.

Throughout the project, the team should remain aware of additional information that may change the set of risks and/or the level of risk associated
with known quality risks.

Periodic adjustment of the quality risk analysis, which results in adjustments to the tests, should occur. Adjustments include identifying new risks, re-
assessing the level of existing risks, and evaluating the effectiveness of risk mitigation activities.

Quality risks can also be mitigated before test execution starts. example, if problems with the user stories are found during risk identification

Estimating Testing Effort Based on Content and Risk:

During release planning, the Agile team estimates the effort required to complete the release. The estimate addresses the testing effort as well.

In a planning poker A high estimate usually means that the story is not well understood or should be broken down into multiple smaller stories.

The estimators discuss the feature, and ask questions of the product owner as needed.

Aspects such as development and testing effort, complexity of the story, and scope of testing play a role in the estimation. Therefore, it is advisable to
include the risk level of a backlog item

If not, the estimators discuss the differences in estimates after which the poker round is repeated until agreement is reached, either by consensus or
by applying rules (e.g., use the median, use the highest score) to limit the number of poker rounds.

Criteria, Adequate Coverage & Other Info for Testing:

Agile projects outline initial requirements as user stories in a prioritized backlog at the start of the project. Initial requirements are short and usually
follow a predefined format

Task Management and Tracking Tools

Configuration management tools are 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 artifacts.

An Agile teams might use physical or electronic tracking tools

 Physcal tools: story/task boards
 Electronictools: task boards
These tools serve the following purposes:

 Record stories and their relevant development and test tasks, to ensure that nothing gets lost during a sprint

 Capture team members’ estimates on their tasks and automatically calculate the effort required to implement a story, to support efficient
iteration planning sessions

 Associate development tasks and test tasks with the same story helps provide a complete picture of the team’s effort required to implement
the story

 Aggregate developer and tester updates to the task status as they complete their work, automatically providing a current calculated snapshot
of the status of each story, the iteration, and the overall release

 Provide a visual representation of the current state of each user story, the iteration, and the release, allowing all stakeholders, including
people on geographically distributed teams, to quickly check status

 Integrate with configuration management tools, which can allow automated recording of code check-ins and builds against tasks, and, in
some cases, automated status updates for tasks

Communication and Information Sharing Tools

In addition to e-mail, documents, and verbal communication, Agile teams often use three additional types of tools to support communication and
information sharing:
 Wikis
 instant messaging
 desktop sharing.

Wikis allow teams to build and share an online knowledge base on various aspects of the project, including the following:

 Product feature diagrams, feature discussions, prototype diagrams, photos of whiteboard discussions, and other information
 Tools and/or techniques for developing and testing found to be useful by other members of the team
 Metrics, charts, and dashboards on product status, which is especially useful when the wiki is integrated with other tools such as the build
server and task management system, since the tool can update product status automatically
 Conversations between team members, similar to instant messaging and email, but in a way that is shared with everyone else on the team

Instant messaging, audio teleconferencing, and video chat tools provide the following benefits:

 Allow real time direct communication between team members, especially distributed teams
 Involve distributed teams in standup meetings
 Reduce telephone bills by use of voice-over-IP technology, removing cost constraints that could reduce team member communication in
distributed settings

Desktop sharing and capturing tools provide the following benefits:

 In distributed teams, product demonstrations, code reviews, and even pairing can occur
 Capturing product demonstrations at the end of each iteration, which can be posted to the team’s wiki

Software Build and Distribution Tools

building and deploying software frequently is a core practice in Agile. To achieve this, teams use two important types of tools:
 Continuous integration (CI) tools: CI tools are like that assembly line for software development. They automate various tasks involved in
building the software, including:

 Collecting the latest code changes from everyone on the team.

 Running automated tests to ensure the new code doesn't break anything.
  Building the updated software automatically.

 Build distribution tools: Once the software is built and tested, these tools help deliver it to the right people. They can be used to:
 Share the latest build with testers for further testing.
 Deploy the final version of the software to production (the environment where users interact with it).

Benefits of using these tools:

 Faster delivery: Automating tasks saves time and allows for more frequent software updates.
 Improved quality: Automated testing helps catch bugs early in the development process.
 Reduced risk: Frequent builds and deployments help identify and fix issues quickly, minimizing the risk of major problems later.
Configuration Management Tools:
Type of configration management Tools:
 centralized source control systems
 distributed version control systems
how determine which version control system is right for a particular Agile project:
 The team size
 Structure, location
 Requirements to integrate with other tools
Benefits of using these tools:
 provides traceability between which versions of the software were tested with which particular versions of the tests
 allows for rapid change without losing historical information
Test Design, Implementation, and Execution Tools
 Test design tools: Use of tools such as mind maps have become more popular to quickly design and define tests for a new feature.
 Test case management tools: The type of test case management tools used to manage test case
 Test data preparation and generation tools: Tools that generate data to populate an application’s database
 Test data load tools: After data has been generated for testing, it needs to be loaded into the application.
 Automated test execution tools: There are test execution tools which are more aligned to Agile testing.
 Exploratory test tools: Tools that capture and log activities performed on an application during an exploratory test session
Cloud Computing and Virtualization Tools:

Virtualization allows a single physical resource (server) to operate as many separate, smaller resources. When virtual machines or cloud instances
are used, teams have a greater number of servers available to them for development and testing.

This can help to avoid delays associated with waiting for physical servers.

Provisioning a new server or restoring a server is more efficient with snapshot capabilities built into most virtualization tools.