There are a number of agile approaches used by organizations. Practices common to most agile organizations include collaborative user story creation, retrospectives, continuous integration, and planning for each iteration as well as for the overall release. This subsection describes some of the agile approaches.

Agile Software Development Approaches

There are several agile approaches, each of which implements the values and principles of the Agile Manifesto in different ways. In this curriculum, we will look at three representatives of the agile approaches:

• Extreme Programming (XP)
• Scrum
• Kanban

Extreme Programming
Extreme Programming (XP), is an agile approach to software development described by specific values, principles, and development practices.

XP focuses on five values to guide development:

• Communication
• Simplicity
• Feedback
• Courage
• Respect

XP describes a set of principles as additional guidelines:

• Humanity
• Economy
• Mutual Benefit
• Self-Similarity
• Improvement
• Diversity
• Reflection
• Flow
• Opportunity
• Redundancy
• Failure
• Quality
• Small Steps
• Assumed Responsibility

XP describes thirteen primary practices:

• sit together
• whole team
• informative workspace
• energetic work
• pair programming
• stories
• weekly cycle
• quarterly cycle
• Slack
• ten-minute build
• continuous-integration
• test-first programming
• incremental design

Many of the agile software development approaches used today are influenced by XP and its values and principles. Agile teams that follow Scrum, for example, often use XP practices.

Scrum
Scrum is an agile management framework that includes the following tools and practices:

• Sprint: Scrum divides a project into iterations (called sprints) of fixed length (typically two to four weeks).
• Product Increment: each sprint results in a potentially releasable/deliverable product (called an increment).
• Product Backlog: The Product Owner maintains a prioritized list of planned product elements (called the Product Backlog). The Product Backlog evolves from Sprint to Sprint (called Backlog Refinement).
• SprintBacklog: At the beginning of each Sprint, the Scrum team selects a set of highest priority items from the Product Backlog (called the Sprint Backlog). Since the Scrum team, and not the product owner, selects the elements to be realized within the sprint, the selection is made according to the pull and not the push principle.
• Definition of Done: To ensure that there is a potentially releasable product at the end of each Sprint, the Scrum team discusses and defines appropriate criteria for completing the Sprint. The discussion deepens the team’s understanding of the backlog items and product requirements.
• Timeboxing: Only the tasks, requirements, or features that the team expects to be completed within the sprint are part of the sprint backlog. If the development team cannot complete a task within a Sprint, the associated product features are removed from the Sprint and the task is moved back into the Product Backlog. Timeboxing applies not only to tasks, but also in other situations (e.g., enforcing start and end times for meetings).
• Transparency: the development team reports and updates sprint status daily in a meeting called the Daily Scrum. This makes the content and progress of the current sprint, including test results, visible to the team, management, and all interested parties. The development team can display the sprint status on a whiteboard, for example.

Scrum defines three roles:

• ScrumMaster: ensures that Scrum practices and rules are implemented and followed, and resolves violations, resource issues, or other obstacles that may prevent the team from following the practices and rules. This person is not the team leader, but a coach.
• Product Owner: Represents the customer and creates, maintains, and prioritizes the Product Backlog. This person is not the team leader.
• Development Team: develops and tests the product. The team is self-organized: There is no team leader, so the team makes the decisions. The team is also cross-functional.

Scrum (unlike XP) does not prescribe specific software development techniques (e.g., test-oriented programming). Also, Scrum does not provide guidance on how testing must be done in a Scrum project.

Kanban
Kanban is a management approach sometimes used in agile projects. The general goal is to visualize and optimize the flow of work within a value chain. Kanban employs three tools:

• KanbanBoard: the value chain to be managed is visualized by a Kanban board. Each column shows a station, i.e. a set of related activities, e.g. development or test. The items to be produced or tasks to be processed are symbolized by tickets that move from left to right across the board and stations.
• Work-in-Progress Limit: The amount of tasks running in parallel is strictly limited. This is controlled by the maximum number of tickets allowed for a station and/or globally for the board. Whenever a station has free capacity, the worker pulls a ticket from the previous station.
• Lead Time: Kanban is used to optimize the continuous flow of tasks by minimizing the (average) lead time for the entire value stream.

Kanban has some similarities to Scrum. In both frameworks, visualization of active tasks (e.g., on a public whiteboard) provides transparency about task content and progress. Tasks that are not yet scheduled wait in a backlog and are moved to the Kanban board as soon as new space (production capacity) is available.

Iterations or sprints are optional in Kanban. The Kanban process allows the release of its deliverables piece by piece and not as part of a release. Timeboxing as a synchronization mechanism is therefore optional, unlike Scrum which synchronizes all tasks within a sprint.

Collaborative User Story Creation

Poor specifications are often a major reason for project failure. Specification problems can result from users not having insight into their true needs, lack of a global vision for the system, redundant or conflicting features, and other misunderstandings. In agile development, user stories are written to capture requirements from the perspective of developers, testers, and business representatives. In sequential development, this shared vision of a function is achieved through formal reviews after the requirements are written; in agile development, this shared vision is achieved through frequent informal reviews as the requirements are written.

User stories must address both functional and non-functional features. Each story includes acceptance criteria for these features. These criteria should be defined in collaboration between business representatives, developers, and testers. They provide developers and testers with an expanded vision of the feature to be validated by business representatives. An agile team considers a task complete when a set of acceptance criteria is met.

Typically, the tester’s unique perspective will enhance the user story by identifying missing details or non-functional requirements. A tester can contribute by asking business representatives open-ended questions about the user story, suggesting ways to test the user story, and confirming acceptance criteria.

Collaborative creation of the user story can use techniques such as brainstorming and mind mapping. The tester may use the INVEST technique:

• Independent
• Negotiable
• Valuable
• Assessable
• Small
• Testable

According to the 3C concept, a user story is the combination of three elements:

• Map: the map is the physical medium that describes a user story. It identifies the requirement, its criticality, the expected development and test duration, and the acceptance criteria for that story. The description must be accurate as it will be used in the Product Backlog.
• Conversation: the conversation explains how the software will be used. The conversation can be documented or verbal. Testers have a different perspective than developers and company representatives and bring valuable input to share thoughts, opinions, and experiences. The conversation begins in the release planning phase and continues as the story is planned.
• Confirmation: The acceptance criteria discussed in the conversation are used to confirm that the story is ready. These acceptance criteria can span multiple user stories. Both positive and negative tests should be used to cover the criteria. During confirmation, various participants play the role of a tester. These can include developers as well as specialists who focus on performance, security, interoperability, and other quality attributes. To confirm a story is ready, the defined acceptance criteria should be tested and considered met.

Agile teams differ in how they document user stories. Regardless of the approach to documenting user stories, documentation should be concise, sufficient, and necessary.

Retrospectives

In agile development, a retrospective is a meeting held at the end of each iteration to discuss what was successful, what can be improved, and how to incorporate the improvements and maintain the successes in future iterations. Retrospectives cover topics such as the process, people, organizations, relationships, and tools. Regularly scheduled retrospectives with appropriate follow-up activities are critical for self-organization and continuous improvement of development and testing.

Retrospectives can lead to test-related improvement decisions focused on test effectiveness, test productivity, test case quality, and team satisfaction. They can also address the testability of applications, user stories, features, or system interfaces. Root cause analysis of defects can lead to improvements in testing and development. In general, teams should implement only a few improvements per iteration. This allows for continuous improvement at a steady pace.

The timing and organization of the retrospective depend on the agile methodology. Company representatives and the team attend each retrospective as participants, while the facilitator organizes and leads the session. In some cases, teams may invite other participants to the session.

Testers should play an important role in retrospectives. They are part of the team and bring their own perspective. Testing happens in every sprint and is a critical contributor to success. All team members, testers and non-testers, can contribute to both testing and non-testing activities.

Retrospectives must take place in a professional environment characterized by mutual trust. The characteristics of a successful retrospective are the same as for any other review.

Continuous Integration

The delivery of a product increment requires reliable, functioning, and integrated software at the end of each sprint. Continuous integration overcomes this challenge by bringing together all changes made to the software and integrating all changed components on a regular basis, at least once a day. Configuration management, compilation, software creation, deployment, and testing are combined into a single, automated and repeatable process. As developers constantly integrate their work, constantly build, and constantly test, errors in the code are detected more quickly.

After coding, debugging, and checking code into a common source code repository by developers, a continuous integration process consists of the following automated activities:

• Static code analysis: performing static code analysis and reporting the results
• Compile: Compiling and linking the code, generating the executables
• Unit testing: running the unit tests, checking the code coverage, and reporting the test results
• Deploy: installing the build in a test environment
• Integration testing: Running the integration tests and reporting the results
• Report (dashboard): publish the status of all these activities in a publicly accessible place or send the status to the team via email

An automated build and test process takes place daily and uncovers integration errors early and quickly. Continuous integration allows Agile testers to run automated tests regularly, in some cases as part of the continuous integration process itself, and provide quick feedback to the team on the quality of the code. These test results are visible to all team members, especially when automated reports are integrated into the process. Automated regression testing can be performed throughout the iteration. Good automated regression testing covers as many features as possible, including user stories delivered in previous iterations. Good coverage in the automated regression tests helps in building (and testing) large integrated systems. When regression testing is automated, agile testers can focus their manual testing on new features, implemented changes, and confirmation testing of bug fixes.

In addition to automated testing, organizations using continuous integration typically use build tools to implement continuous quality control. In addition to performing unit and integration testing, such tools can perform additional static and dynamic testing, measure and profile performance, extract and format documentation from source code, and facilitate manual quality assurance processes. This continuous application of quality control aims to improve the quality of the product and reduce time to delivery by replacing the traditional practice of quality control after all development is complete.

Build tools can be linked to automated deployment tools that can retrieve the appropriate build from the continuous integration or build server and deploy it to one or more development, test, staging, or even production environments. This reduces the errors and delays that occur when specialized staff or programmers are tasked with installing versions in these environments.

Continuous integration can provide the following benefits

• Enables earlier detection and easier root cause analysis of integration issues and conflicting changes
• The development team receives regular feedback on whether the code is working
• Keeps the version of the software under test at the same level as the version under development within a single day
• Reduces the regression risk associated with developers refactoring code, as the code base is quickly retested after each minor change
• Provides assurance that day-to-day development work is based on a solid foundation
• Makes progress toward completion of the product increment visible and encourages developers and testers
• Eliminates the schedule risks associated with big-bang integration
• Continuous availability of executable software throughout the sprint for testing, demonstration, or training purposes
• Reduces repetitive manual testing activities
• Rapid feedback on decisions made to improve quality and testing

However, continuous integration is not without risks and challenges:

• Continuous integration tools must be introduced and maintained
• The continuous integration process must be defined and established
• Test automation requires additional resources and can be very complex
• Thorough test coverage is essential to reap the benefits of automated testing.
• Teams sometimes rely too much on unit testing and do not perform enough system and acceptance testing

Continuous integration requires the use of tools, including tools for testing, tools for automating the build process, and tools for version control.

Release and Iteration Planning

Planning is an ongoing activity, and this is also true for Agile lifecycles. In Agile lifecycles, there are two types of planning: release planning and iteration planning.

Release planning provides for the release of a product, often a few months before the start of a project. Release planning defines and redefines the product backlog, where larger user stories can be refined into a collection of smaller stories. Release planning forms the basis for a testing approach and a test plan that covers all iterations. Release plans are very general.

During release planning, business representatives work with the team to define and prioritize the user stories for the release. Based on these user stories, project and quality risks are identified and a high-level effort estimate is made.

Testers are involved in release planning and add value especially in the following activities:

• Definition of testable user stories, including acceptance criteria
• Participation in project and quality risk analyses
• Estimation of the testing effort associated with the user stories
• Definition of the necessary test levels
• Planning the tests for the release

After release planning is complete, iteration planning for the first iteration begins. Iteration planning provides for the end of a single iteration and deals with the iteration backlog.

During iteration planning, the team selects user stories from the prioritized release backlog, elaborates on the user stories, performs risk analysis for the user stories, and estimates the amount of work required for each user story. If a user story is too vague and attempts to clarify it has failed, the team can refuse to accept it and use the next user story based on priority. Business representatives must answer the team’s questions about each story so the team understands what to implement and how to test each story.

The number of stories selected is based on the established team velocity and the estimated volume of user stories selected. After the content of the iteration is determined, the user stories are broken down into tasks that are executed by the appropriate team members.

Testers participate in iteration planning and add value especially in the following activities:

• Contributing to the detailed risk analysis of the user stories.
• Determining the testability of the user stories
• Creation of acceptance tests for the user stories
• Breaking down the user stories into tasks (especially test tasks)
• Estimation of the test effort for all test tasks
• Identifying functional and non-functional aspects of the system under test
• Support and participate in test automation at multiple test levels

Release plans may change during the course of the project, including changes to individual user stories in the product backlog. These changes may be triggered by internal or external factors. Internal factors include deliverability, velocity, and technical issues. External factors include the discovery of new markets and opportunities, new competitors, or business threats that may change version goals and/or target dates. In addition, iteration plans may change during an iteration. For example, a particular user story that was considered relatively simple during estimation may turn out to be more complex than expected.

These changes can be challenging for testers. Testers need to understand the big picture of the release for test planning and have an adequate test base and test oracle for test development in each iteration. The required information must be available to the tester early, and yet changes must be adopted according to agile principles. This dilemma requires careful decisions about test strategies and test documentation.

Release and iteration planning should consider both test planning and development activity planning. Specific test-related issues that need to be addressed include:

• The test scope, the extent of testing for the areas in the test scope, the test objectives, and the rationale for these decisions.
• The team members who will perform the testing activities.
• The test environment and test data needed when they will be needed, and whether additions or changes to the test environment and/or data will be made before or during the project.
• The schedule, sequence, dependencies, and prerequisites for the functional and non-functional test activities (e.g., how frequently regression testing will be performed, which functions depend on other functions or test data, etc.), including how the test activities relate to and depend on the development activities.
• Project and quality risks should be considered.

In addition, when estimating effort, the team should also consider the time and effort required to perform the required test activities.

Source: ISTQB®: Certified Tester Foundation Level Agile Tester Syllabus Version 1.0