Chapter 1

1.1 Agile Software Development and the Agile Manifesto

1.1.1 the Agile Manifesto & Principles:

 Individuals and interactions over processes and tools

 Working software over comprehensive documentation
 Customer collaboration over contract negotiation
 Responding to change over following a plan

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.

Working Software: 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, Agile development can confer significant time-to-market advantage.

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.

Responding to Change: Change is inevitable in software projects. having flexibility in work practices to embrace change is more important than
simply adhering rigidly to a plan.

Note: Agile development is 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.

Agile Principles:

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

1.1.2 Whole-Team Approach:

The whole-team approach means involving everyone with the knowledge and skills necessary to ensure project success.
Agile team should be:

 includes representatives from the customer and other business stakeholders who determine product features.
 team should be relatively small from 3 – 9 members
 the whole team shares the same workspace, as co-location
 The whole-team approach is supported through the daily stand-up meetings Build projects around motivated individuals.

the main benefits of Whole-Team Approach:

 Enhancing communication and collaboration within the team

 Enabling the various skill sets within the team to be leveraged to the benefit of the project
 Making quality everyone’s responsibility

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

Agile projects have short iterations enabling the project team to receive early and continuous feedback on product quality throughout the
development lifecycle.

Benefits of early and continuous feedback:

 By getting frequent customer feedback helps the Agile teams incorporate most new changes into the product development process
 helps the team focus on the features with the highest business value, or associated risk, and these are delivered to the customer first.
 It also helps manage the team better since the capability of the team is transparent to everyone. (help the team go faster)

Benefits of early and continuous feedback:

 Avoiding requirements misunderstandings

 Clarifying customer feature requests
 Discovering, isolating, and resolving quality problems early.
 Providing information to the Agile team regarding its productivity and ability to deliver.
 Promoting consistent project momentum.

One way to provide rapid feedback is by continuous integration

1.2 Agile Software Development Approaches

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

Extreme Programming (XP):

XP embraces five values to guide development:

 Communication
 simplicity
 feedback
 courage
 respect

XP describes thirteen primary practices: sit together, whole team, informative workspace, energized work, pair programming, stories, weekly cycle,
quarterly cycle, slack, ten-minute build, continuous integration, test first programming, and incremental design

Scrum:

Scrum is an Agile management framework which contains the following constituent instruments and practices:

 Sprint: Scrum divides a project into iterations (called sprints) of fixed length (usually two to four weeks).
 Product Increment: Each sprint results in a potentially releasable/shippable product (called an increment).
 Product Backlog: The product owner manages a prioritized list of planned product items. The product backlog evolves from sprint to sprint.
 Sprint Backlog: At the start of each sprint, the Scrum team selects a set of highest priority items from the product backlog.
 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.
 Timeboxing: enforcing meeting start and end times
 Transparency: scrum makes the content and progress of the current sprint, including test results, visible to the team.

Note: Task that cannot finish within a sprint are removed from the sprint and the task is moved back into the product backlog.

Note: The development team reports and updates sprint status on a daily basis at a meeting called the daily scrum.

Scrum defines three roles:

 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.
 Product Owner: represents the customer, and generates, maintains, and prioritizes the product backlog.
 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.
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. Kanban utilizes three instruments

 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.
 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.
 Lead Time: Kanban is used to optimize the continuous flow of tasks by minimizing the (average) lead time for the complete value stream.

1.3 Collaborative User Story Creation

user stories are written to capture requirements from the perspectives of developers, testers, and business representatives.

"Documentation of user stories should be concise, sufficient, and necessary," regardless of the approach taken to document user stories.

Benefits of collaboration:

 Prevents misunderstandings: By actively participating in creating user stories, everyone involved avoids misinterpretations and ensures
they are on the same page.
 Identifies missing details: Testers, with their unique perspective, can help identify any missing information or functionalities needed for a
complete feature.
 Ensures clarity: User stories should be clear, concise, and easy for everyone to understand.

How can testers contribute:

 Ask questions: Testers can ask open-ended questions to help clarify user needs and identify potential issues early on.
 Propose testing strategies: Testers can suggest appropriate ways to test the feature and ensure it meets the acceptance criteria.
 Contribute diverse perspectives: Testers bring a different viewpoint to the table.

The user stories must address both functional and non-functional characteristics, each story includes acceptance criteria for these characteristics.
These criteria should be defined in collaboration between business representatives, developers, and testers.

An Agile team considers a task finished when a set of acceptance criteria have been satisfied.

Typically, the tester’s unique perspective will improve 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, proposing ways to test the user story, and
confirming the acceptance criteria.

User stories should follow the concept of INVEST technique:

 Independent
 Negotiable
 Valuable
 Estimable
 Small
 Testable

the 3C concept state that a user story is the conjunction of three elements:

 Card: The card is the physical media describing a user story.

 Conversation: The conversation explains how the software will be used. Conversation begins during the release-planning phase and
continues when the story is scheduled.
 Confirmation: The acceptance criteria, discussed in the conversation, are used to confirm that the story is done.
1.4 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.

the purpose is to identify root causes and use that information to improve both testing and development processes.

Retrospectives are reflection meetings held at the end of each Agile iteration where the following topics are discussed:

 Discuss what went well: Identify things that worked smoothly and contributed to the team's success.
 Identify areas for improvement: Explore what could be done better in future iterations.
 Plan for improvement: Decide on concrete actions to address identified issues and build on strengths.

Retrospectives can address various aspects of the project, including:

 Processes: How tasks were organized and managed.

 People: Teamwork, communication, and collaboration.
 Tools: The effectiveness of software tools used for development and testing.
 Relationships: Collaboration and communication between team members and stakeholders.

Benefits of Retrospectives:

 Regular retrospectives are crucial for continuous improvement in Agile development.

Tester’s role in Retrospectives:

 Providing unique perspective: Testers bring valuable insights into the testing process
 Contributing to discussions: Testers can share their experiences and provide input on both testing and non-testing aspects of the project.

1.5 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.

a continuous integration process consists of the following automated activities:

 Static code analysis: executing static code analysis and reporting results
 Compile: compiling and linking the code, generating the executable files
 Unit test: executing the unit tests, checking code coverage and reporting test results
 Deploy: installing the build into a test environment
 Integration test: executing the integration tests and reporting results
 Report (dashboard): posting the status of all these activities to a publicly visible location or e-mailing status to the team
Continuous integration allows Agile testers to run automated tests regularly, in some cases as part of the continuous integration process itself, and
send quick feedback to the team on the quality of the code.

Good automated regression tests cover as much functionality as possible, including user stories delivered in the previous iterations.

Good coverage in the automated regression tests helps support building (and testing) large integrated systems.

When the regression testing is automated, the Agile testers are freed to concentrate their manual testing on new features, implemented changes,
and confirmation testing of defect fixes.

organizations using continuous integration typically use build tools to implement continuous quality control.

In addition to running unit and integration tests, such tools can run additional static and dynamic tests, measure and profile performance, extract
and format documentation from the source code, and facilitate manual quality assurance processes.

Continuous integration can provide the following benefits:

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

continuous integration is not without its risks and challenges:

 Continuous integration tools have to be introduced and maintained

 The continuous integration process must be defined and established
 Test automation requires additional resources and can be complex to establish
 Thorough test coverage is essential to achieve automated testing advantages
 Teams sometimes over-rely on unit tests and perform too little system and acceptance testing

Release and Iteration Planning

Release planning looks ahead to the release of a product, often a few months ahead of the start of a project. (high-level):

 defines and re-defines the product backlog,

 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
In release planning, business representatives establish and prioritize the user stories for the release Based on these user stories, project and quality
risks are identified and a high-level effort estimation is performed

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

 Defining testable user stories, including acceptance criteria

 Participating in project and quality risk analyses
 Estimating testing effort associated with the user stories
 Defining the necessary test levels
 Planning the testing for the release
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,
 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.

The number of stories selected is based on established team velocity and the estimated size of the selected user stories. 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.

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

 Participating in the detailed risk analysis of user stories

 Determining the testability of the user stories

  Creating acceptance tests for the user stories

 Breaking down user stories into tasks (particularly testing tasks)

 Estimating testing effort for all testing tasks

 Identifying functional and non-functional aspects of the system to be tested

 Supporting and participating in test automation at multiple levels of testing

Release plans may change as the project proceeds, including changes to individual user stories in the product backlog. These changes may be
triggered by internal or external factors

Internal factors include delivery capabilities, velocity, and technical issues.

External factors include the discovery of new markets and opportunities, new competitors, or business threats that may change release objectives
and/or target dates.

These changes can be challenging for testers. Testers must understand the big picture of the release for test planning purposes,

Tester must have an adequate test basis and test oracle in each iteration for test development purposes

Release and iteration planning should address test planning as well as planning for development activities. Particular test-related issues to address
include:

 The scope of testing, the extent of testing for those areas in scope, the test goals, and the reasons for these decisions.

 The team members who will carry out the test activities.

 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.

 The timing, sequencing, dependencies, and prerequisites for the functional and non-functional test activities. including how the test
activities relate to and depend on development activities.

 The project and quality risks to be addressed

In addition, the larger team estimation effort should include consideration of the time and effort needed to complete the required testing activities.