Agile Tester

Foundation Level Extension

Lecture 6
After Eid vacation, we will have year work assessment during lecture time.
Schedule will be announced soon.
Lectures 3 to 8 are included.
The ISTQB® Foundation Level Agile Tester (CTFL-AT) certification provides the key testing skills
necessary to successfully contribute to an Agile project. CTFL-AT covers agile testing in
alignment with the principles of agile software development as outlined in the Agile Manifest.
A tester on an Agile project will work differently than one working on a traditional project.
Testers must understand the values and principles that underpin Agile projects, and how
testers are an integral part of a whole-team approach together with developers and business
representatives.
Fundamentals of
Agile
Software
Development
Introduction
• Tester on an Agile project will work differently
than one working on a traditional project.
• Testers must understand the values and
principles that underpin Agile projects, and
how testers are an integral part of a
whole-team approach together with
developers and business representatives.
• Members in an Agile project communicate
with each other early and frequently, which
helps with removing defects early and
developing a quality product.

6
The Agile Manifesto

• The Agile Manifesto contains four statements of values:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

• The Agile Manifesto argues that although the concepts on the

right have value, those on the left have greater value.

7
Whole-Team Approach

• The team should be relatively small (3-9 members).

• Ideally, the whole team shares the same workspace, as
co-location strongly facilitates communication and interaction.
• Supported through daily stand-up meetings involving all
members of the team, where work progress is communicated
and any barriers to progress are highlighted.
• The whole team is responsible for quality in Agile projects.

9
Whole-Team Approach

• Testers will work closely with both developers and business

representatives to ensure desired quality levels are achieved.
• Examples:
• supporting and collaborating with business representatives to help
them create suitable acceptance tests,
• working with developers to agree on the testing strategy,
• deciding on test automation approaches.
• Testers can thus transfer and extend testing knowledge to
other team members and influence the development of the
product.

10
Early and Frequent Feedback

• Agile projects have short iterations enabling project team to

receive early and continuous feedback on product quality
throughout SDLC.
• Benefits of early and frequent feedback include:
• Avoiding requirements misunderstandings, which may not have been
detected until later in SDLC when they are more expensive to fix.
• Clarifying customer feature requests, making them available for
customer use early. This way, the product better reflects what the
customer wants.
• Discovering, isolating, and resolving quality problems early.
• Providing information to Agile team regarding its productivity and ability
to deliver.
11
 Aspects of
Agile
Approaches
 Aspects of Agile Approaches

Collaborative
Agile
User Story Retrospectives
Approaches
Creation

Release and
Continuous
Iteration
Integration
Planning
 Agile
Software
Development
Approaches
Agile Software Development Approaches

15
1. Extreme Programming (XP)

16
17
18
Extreme Programming (XP) Practices

19
Planning Game

• The main planning process. There are 2 levels of plans in XP:

• release planning
• iteration planning
• In both levels, there are 3 steps:
• exploration,
• commitment,
• steering.
• In release planning, the team and stakeholders collaboratively
decide what are the requirements and features that can be delivered
into production and when. This is done based on priorities, capacity,
estimations and risks factor of the team to deliver.
• In Iteration planning, the team will pick up the most valuable items
from the list and break them down into tasks then estimates and a
commitment to delivering at the end of the iteration.
20
Simple Design and Refactoring

• Team will start with a simple design and let it emerge and
evolve over a period of iterations.
• The code is frequently refactored so that it will be maintainable
and free of technical debt.
• Simple designs make the 'definition of done' easier.
• XP teams conduct a small test or proof-of-concept workout
called Spike. Spike uses the simplest possible program to
explore potential solutions. The outcome of the spike helps the
team to consider the validity of the hypothesis, measure the
complexity of the solution and feel assured to estimate and build
something primarily based on the test.
21
Minimum Viable Product (MVP)

• A cross-functional team in XP releases Minimum Viable Product

(MVP) frequently.
• Advantages:
• helps to breakdown complex modules in a small chunk of
code.
• helps the development team as well as the on-site customer
to demonstrate the product and focus only on the least
amount of work that has the highest priority.

22
System Metaphor

• It could be a naming conversion practice used in design and

code to have a shared understanding between teams.
• For example: Order_Food() is easily explained -- this will be
used to order food.
• It is easy for the team to relate to the functionality of the
particular component by just looking at its name.

23
Pair Programming

• Pair programming consists of two programmers operating on the

same code and unit test cases on the same system (one display and
one keyboard).
• One programmer plays the pilot role and focuses on clean code, and
compiles and runs. The second one plays the role of navigator and
focuses on the big picture and reviews code for improvement or
refactoring.
• Every hour or given a period of time, this pair is allowed to switch
roles.
• The pairs of pilots and navigators are not fixed, and they are
frequently swapped.

24
Collective Code Ownership

• By following pair programming practices, the XP team always

takes collective ownership of code.
• Success or failure is a collective effort and there is no blame
game.
• There is no one key player here, so if there is a bug or issue
then any developer can fix it.

25
Continuous Integration (CI)

• In XP, Developers work on local versions of the code. There is a

need to integrate changes made every few hours or on a daily
basis.

• After every code compilation and build we have to integrate it

where all the tests are executed automatically for the entire project.

• If the tests fail, they are fixed then and there, so that any chance of
defect propagation and further problems are avoided with minimum
downtime.

• The team can use CI tools like Jenkins, shippable, Integrity, Azure
DevOps Pipelines, etc.

26
Test-driven Development

• Tests are written before code and ‘passing’ the tests is the critical
driver of development.
• You develop code incrementally, along with a test for that
increment. You don’t move on to the next increment until the
code that you have developed passes its test.
• TDD is used to develop code guided by automated test cases.
• The tests written are primarily unit level and are code-focused,
tests may also be written at integration or system levels.
• It helps developers focus on clearly-defined expected results. The
tests are automated and are used in continuous integration.
27
Sustainable Pace

• Practices like TDD, continuous integration and refactoring of

code help to proactively improve the quality and stability of the
working software.
• XP maintains a sustainable pace by introducing slack time
during the iteration. The team is not doing actual
development at this time but acts as a buffer to deal with
uncertainties and issues.
• Teams can use the slack time to pay down technical debt by
refactoring code or do research to keep up the pace.

28
2. Scrum

• Scrum (as opposed to XP) does not dictate specific software

development techniques (e.g., test-driven development).
• In addition, Scrum does not provide guidance on how testing
has to be done.

29
30
3. Kanban

• The general objective is to visualize and

optimize the flow of work within a
value-added chain.
• It is a management approach that is
sometimes used in Agile projects.
• Kanban can be used in situations where work
arrives in an unpredictable fashion and/or
when you want to deploy work as soon as it
is ready, rather than waiting for other work
items.
• Kanban is great for teams that have lots of
incoming requests that vary in priority and
size.

31
Kanban
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 WIP 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.

32
Kanban

Kanban lead time: is the time between a request being made and a task
being released. It’s the total time the client is waiting for a task to be
delivered. Lead time is frequently used by Kanban teams to evaluate
customer satisfaction.
Kanban cycle time: is calculating the actual work-in-progress time. It
tracks how long a task stays in the different process stages. It is used to
measure team performance. Low cycle times mean that team is efficient.
High cycle times indicate stalls, bottlenecks, and backlogs.

33
34
 Aspects of Agile Approaches

Collaborative
Agile
User Story Retrospectives
Approaches
Creation

Release and
Continuous
Iteration
Integration
Planning
User Story

• User stories are the Agile form of requirements specifications.

• They should explain how the system should behave with respect
to a single, coherent feature or function.
• A user story should define a feature small enough to be completed
in a single iteration.
• Larger collections of related features, or a collection of sub-features
that make up a single complex feature, may be referred to as
“epics”.
• Epics may include user stories for different development teams. For
example, one user story can describe what is required at the
API-level (middleware) while another story describes what is
needed at the UIlevel (application).

36
Collaborative User Story Creation

• In Agile development, user stories are written to capture requirements

from the perspectives of developers, testers, and business
representatives. This shared vision is accomplished through frequent
informal reviews while the requirements are being written.
• User stories must address both functional and non-functional
characteristics. Each story includes acceptance criteria for these
characteristics.
• Agile team considers a task finished when a set of acceptance criteria
have been satisfied.
• Tester’s unique perspective will improve the user story by identifying
missing details or non-functional requirements.
• Techniques: INVEST and 3Cs.
37
INVEST Technique

• Collaborative authorship of the user story can use techniques such as

brainstorming and mind mapping.
• To write effective user stories, tester may use the INVEST technique.

38
3Cs Concept

1. Card: 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.
2. Conversation: explains how the software will be used. The
conversation can be documented or verbal. Testers bring valuable
input to the exchange of thoughts, opinions, and experiences.
3. Confirmation: 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.
39
3Cs Concept

40
 Aspects of Agile Approaches

Collaborative
Agile
User Story Retrospectives
Approaches
Creation

Release and
Continuous
Iteration
Integration
Planning
Retrospectives

• 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.
• Retrospectives cover following topics: process, people, organization,
relationships, and tools.
• All team members, testers and non-testers, can provide input on both
testing and non-testing activities.
• Retrospectives can result in test-related improvement decisions focused
on test effectiveness, test productivity, test case quality, and team
satisfaction. They may also address the testability of the applications, user
stories, features, or system interfaces.

42
Thank You