ISTQB Foundation Extension Agile Tester Chapter 1: Agile Software Development

Conversation

(The 3C concept) The conversation explains how the software will be used. The conversation can be documented or verbal. Testers, having a different point of view than developers and business representatives, bring valuable input to the exchange of thoughts, opinions, and experiences. Conversation begins during the release-planning phase and continues when the story is scheduled.

The tester may use the INVEST technique

1 Independent 2 Negotiable 3 Valuable 4 Estimable 5 Small 6 Testable The collaborative authorship of the user story can use techniques such as brainstorming and mind mapping. The tester may use the INVEST technique.

The core Agile Manifesto values are captured in 12 principles

1 Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. 2 Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. 3 Deliver working software frequently, at intervals of between a few weeks to a few months, with a preference to the shorter timescale. 4 Business people and developers must work together daily throughout the project. 5 Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. 6 The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. 7 Working software is the primary measure of progress. 8 Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. 9 Continuous attention to technical excellence and good design enhances agility. 10 Simplicity—the art of maximizing the amount of work not done—is essential. 11 The best architectures, requirements, and designs emerge from self-organizing teams. 12 At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Responding to Change

Change is inevitable in software projects. The environment in which the business operates, legislation, competitor activity, technology advances, and other factors can have major influences on the project and its objectives. These factors must be accommodated by the development process. As such, having flexibility in work practices to embrace change is more important than simply adhering rigidly to a plan.

Customer Collaboration

Customers often find great difficulty in specifying the system that they require. Collaborating directly with the customer improves the likelihood of understanding exactly what the customer requires. While having contracts with customers may be important, working in regular and close collaboration with them is likely to bring more success to the project.

Continuous Integration

Delivery of a product increment requires reliable, working, integrated software at the end of every sprint. Continuous integration addresses this challenge by merging all changes made to the software and integrating all changed components regularly, at least once a day. Configuration management, compilation, software build, deployment, and testing are wrapped into a single, automated, repeatable process. Since developers integrate their work constantly, build constantly, and test constantly, defects in code are detected more quickly.

Development Team

Develop and test the product. The team is self-organized: There is no team lead, so the team makes the decisions. The team is also cross-functional

Product Increment

Each sprint results in a potentially releasable/shippable product (called an increment).

Scrum Master

Ensures that Scrum practices and rules are implemented and followed, and resolves any violations, resource issues, or other impediments that could prevent the team from following the practices and rules. This person is not the team lead, but a coach.

Working Software

From a customer perspective, working software is much more useful and valuable than overly detailed documentation and it provides an opportunity to give the development team rapid feedback. In addition, because working software, albeit with reduced functionality, is available much earlier in the development lifecycle, Agile development can confer significant time-to-market advantage. Agile development is, therefore, especially useful in rapidly changing business environments where the problems and/or solutions are unclear or where the business wishes to innovate in new problem domains.

Retrospectives

In Agile development, a retrospective is a meeting held at the end of each iteration to discuss what was successful, what could be improved, and how to incorporate the improvements and retain the successes in future iterations

Agile Software Development Approaches

In this syllabus, three representatives of Agile approaches are considered: 1. Extreme Programming (XP) 2. Scrum 3. Kanban

Topics in Retrospectives

Retrospectives cover topics such as the process, people, organizations, relationships, and tools.

Sprint

Scrum divides a project into iterations (called sprints) of fixed length (usually two to four weeks).

Scrum

Scrum is an Agile management framework

Work-in-Progress Limit

The amount of parallel active tasks 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 predecessor station.

The power of three

The concept of involving testers, developers, and business representatives in all feature discussions is known as the power of three

Transparency

The development team reports and updates sprint status on a daily basis at 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. For example, the development team can show sprint status on a whiteboard.

The number of stories selected in an iteration

The number of stories selected is based on established team velocity and the estimated size of the selected user stories.

Product Backlog

The product owner manages a prioritized list of planned product items (called the product backlog). The product backlog evolves from sprint to sprint (called backlog refinement).

Team size

The team should be relatively small; successful teams have been observed with as few as 3 people and as many as 9

User story , functional and non-functional characteristics

The user stories must address both functional and non-functional characteristics

Kanban Board

The value chain to be managed is visualized by a Kanban board. Each column shows a station, which is a set of related activities, e.g., development or testing. The items to be produced or tasks to be processed are symbolized by tickets moving from left to right across the board through the stations.

Agile Approaches

There are a number of Agile approaches in use by organizations. Common practices across most Agile organizations include collaborative user story creation, retrospectives, continuous integration, and planning for each iteration as well as for overall release.

Who defines acceptance criteria?

These criteria should be defined in collaboration between business representatives, developers, and testers.

Definition of Done

To make sure that there is a potentially releasable product at each sprint's end, the Scrum team discusses and defines appropriate criteria for sprint completion. The discussion deepens the team's understanding of the backlog items and the product requirements.

Product Owner

Represents the customer, and generates, maintains, and prioritizes the product backlog. This person is not the team lead.

Card

(The 3C concept) The card is the physical media describing a user story. It identifies the requirement, its criticality, expected development and test duration, and the acceptance criteria for that story. The description has to be accurate, as it will be used in the product backlog.

Confirmation

(The 3C concept) The acceptance criteria, discussed in the conversation, are used to confirm that the story is done. These acceptance criteria may 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 focused on performance, security, interoperability, and other quality characteristics. To confirm a story as done, the defined acceptance criteria should be tested and shown to be satisfied.

Continuous integration benefits

1. Allows earlier detection and easier root cause analysis of integration problems and conflicting changes 2. Gives the development team regular feedback on whether the code is working 3. Keeps the version of the software being tested within a day of the version being developed 4. Reduces regression risk associated with developer code refactoring due to rapid re-testing of the code base after each small set of changes 5. Provides confidence that each day's development work is based on a solid foundation 6. Makes progress toward the completion of the product increment visible, encouraging developers and testers 7. Eliminates the schedule risks associated with big-bang integration 8. Provides constant availability of executable software throughout the sprint for testing, demonstration, or education purposes 9. Reduces repetitive manual testing activities 10. Provides quick feedback on decisions made to improve quality and tests

The benefits of early and frequent feedback

1. Avoiding requirements misunderstandings, which may not have been detected until later in the development cycle when they are more expensive to fix. 2. Clarifying customer feature requests, making them available for customer use early. This way, the product better reflects what the customer wants. 3. Discovering (via continuous integration), isolating, and resolving quality problems early. 4. Providing information to the Agile team regarding its productivity and ability to deliver. 5. Promoting consistent project momentum.

The 3C concept

1. Card 2. Conversation 3. Confirmation

Continuous integration risks and challenges

1. Continuous integration tools have to be introduced and maintained 2. The continuous integration process must be defined and established 3. Test automation requires additional resources and can be complex to establish 4. Thorough test coverage is essential to achieve automated testing advantages 5. Teams sometimes over-rely on unit tests and perform too little system and acceptance testing

Whole-Team Approach Benefits

1. Enhancing communication and collaboration within the team 2. Enabling the various skill sets within the team to be leveraged to the benefit of the project 3. Making quality everyone's responsibility

Agile Manifesto

1. Individuals and interactions over processes and tools 2. Working software over comprehensive documentation 3. Customer collaboration over contract negotiation 4. Responding to change over following a plan

Kanban utilizes 3 instruments

1. Kanban Board 2. Work-in-Progress Limit 3. Lead Time

For Agile lifecycles, two kinds of planning occur

1. Release planning 2. Iteration planning

Scrum defines three roles

1. Scrum Master 2. Product Owner 3. Development Team

Scrum contains the following constituent instruments and practices

1. Sprint 2. Product Increment 3. Product Backlog 4. Sprint Backlog 5. Definition of Done 6. Timeboxing 7. Transparency

A continuous integration process consists of the following automated activities

1. Static code analysis: executing static code analysis and reporting results 2. Compile: compiling and linking the code, generating the executable files 3. Unit test: executing the unit tests, checking code coverage and reporting test results 4. Deploy: installing the build into a test environment 5. Integration test: executing the integration tests and reporting results 6. Report (dashboard): posting the status of all these activities to a publicly visible location or emailing status to the team

Particular test-related issues to address in release and iteration planning

1. The scope of testing, the extent of testing for those areas in scope, the test goals, and the reasons for these decisions. 2. The team members who will carry out the test activities. 3. The test environment and test data needed, when they are needed, and whether any additions or changes to the test environment and/or data will occur prior to or during the project. 4. The timing, sequencing, dependencies, and prerequisites for the functional and non-functional test activities (e.g., how frequently to run regression tests, which features depend on other features or test data, etc.), including how the test activities relate to and depend on development activities. 5. The project and quality risks to be addressed.

Continuous integration requires the use of tools

1. Tools for testing 2. Tools for automating the build process 3. Tools for version control

XP embraces five values to guide development

1. communication 2. simplicity 3. feedback 4. courage 5. respect

XP describes a set of principles as additional guidelines

1. humanity 2. economics 3. mutual benefit 4. selfsimilarity 5. improvement 6. diversity 7. reflection 8. flow 9. opportunity 10. redundancy 11. failure 12. quality 13. baby steps 14. accepted responsibility

XP describes thirteen primary practices

1. sit together 2. whole team 3. informative workspace 4. energized work 5. pair programming 6. stories 7. weekly cycle 8. quarterly cycle 9. slack 10. ten-minute build 11. continuous integration 12. test first programming 13. incremental design

Iteration planning

After release planning is done, iteration planning for the first iteration starts. Iteration planning looks ahead to the end of a single iteration and is concerned with the iteration backlog. In iteration planning, the team selects user stories from the prioritized release backlog, elaborates the user stories, performs a risk analysis for the user stories, and estimates the work needed for each user story. If a user story is too vague and attempts to clarify it have failed, the team can refuse to accept it and use the next user story based on priority. The business representatives must answer the team's questions about each story so the team can understand what they should implement and how to test each story.

Tasks

After the contents of the iteration are finalized, the user stories are broken into tasks, which will be carried out by the appropriate team members.

Individuals and Interactions

Agile development is very people-centered. Teams of people build software, and it is through continuous communication and interaction, rather than a reliance on tools or processes, that teams can work most effectively.

Documentation of user stories

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

Extreme Programming (XP)

An Agile approach to software development described by certain values, principles, and development practices

Sprint Backlog

At the start of each sprint, the Scrum team selects a set of highest priority items (called the sprint backlog) from the product backlog. Since the Scrum team, not the product owner, selects the items to be realized within the sprint, the selection is referred to as being on the pull principle rather than the push principle.

Kanban and Scrum

Kanban features some similarities to Scrum. In both frameworks, visualizing the active tasks (e.g., on a public whiteboard) provides transparency of content and progress of tasks. Tasks not yet scheduled are waiting in a backlog and moved onto the Kanban board as soon as there is new space (production capacity) available. Iterations or sprints are optional in Kanban. The Kanban process allows releasing its deliverables item by item, rather than as part of a release. Timeboxing as a synchronizing mechanism, therefore, is optional, unlike in Scrum, which synchronizes all tasks within a sprint.

Kanban

Kanban is a management approach that is sometimes used in Agile projects. The general objective is to visualize and optimize the flow of work within a value-added chain.

Lead Time

Kanban is used to optimize the continuous flow of tasks by minimizing the (average) lead time for the complete value stream.

XP and Agile software development

Many of the Agile software development approaches in use today are influenced by XP and its values and principles. For example, Agile teams following Scrum often incorporate XP practices.

Timeboxing

Only those tasks, requirements, or features that the team expects to finish within the sprint are part of the sprint backlog. If the development team cannot finish 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 in other situations (e.g., enforcing meeting start and end times).

Release planning

Release planning defines and re-defines the product backlog, and may involve refining larger user stories into a collection of smaller stories. Release planning provides the basis for a test approach and test plan spanning all iterations. Release plans are high-level.