MANUAL TESTER

Workshop
1

Agile
Agenda

01 Agile – history, Manifesto of Agile Software Development, Scrum

02 Weekly planning – discussion and noting down tasks, prioritizing, sprint planning
03 Test plan – why do we need one, what does it include, the ISO/IEC/IEEE 29119-3 norm, discussing
an example

2
Agile 3
The History of Agile

On February 11, 2001, 17 practitioners met at a skiing resort in Utah, USA.

Each day they worked in small, self-organized teams, cooperating with the client, in mutual respect,
focused on delivering early and regularly working software at a high level of technological excellence.

They worked on the basis of the so-called lightweight methods such as Scrum, Extreme
Programming, Feature-Driven Development, or Crystal Clear. 4
The History of Agile continued

The methods were "lightweight" compared to developing software based on extensive

documentation of requirements and speci cations.

Participants of this meetup included persons engaged in creating those methods, such as
 Je  Sutherland and Ken Schwaber (Scrum), Kent Beck (Extreme Programming), Alistair
Cockburn (Crystal Clear).
5

They met to talk about the speci city of the lightweight methods which they had used, exchange
their experiences and opinions, ski, and spend some quality time in the mountains.
The History of Agile continued

Within 3 days they managed to achieve much more than they had expected. They found a common
denominator for all their methods and they decided that the commonly used name "lightweight
methods" is inappropriate.

They agreed that the word “agile” suits the speci city of their work much more precisely. That's how
the term Agile methods came to be.
6

They have also created the Manifesto for Agile Software Development, commonly called the Agile
Manifesto, the purpose of which is to emphasize the 4 values, on which all of the agile methods rest.
The Agile Manifesto
We are uncovering better ways of developing software by doing it and helping others do it.
Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan.
7

That is, while there is value in the items on the right, we value the items on the left more.

http://agilemanifesto.org/iso/pl/manifesto.html
Principles of the Agile Manifesto

How to use it in practice?

The 12 Principles of Agile Software help to explain that.

8
12 Principles of Agile Software

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, from a couple of weeks to a couple of months, with a
preference to the shorter timescale.
4. Business teams and developers must work closely together daily throughout the project. 9

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 e cient and e ective method of conveying information to and within a development
team is face-to-face conversation.
 12 Principles of Agile Software

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 inde nitely.
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.
10
12. At regular intervals, the team re ects on how to become more e ective, then tunes and adjusts
its behavior accordingly.
The Essence of Being Agile

To sum up, we can say that the most crucial elements of Agile are:

Cooperation, trust, and direct communication

Frequent delivery of working software, which is the measure of success
Openness to changing requirements, which can take place even at later stages of
development
11
A responsible, self-organized, and interdisciplinary team
So, What is Agile?

Agile is a collection of rules and values, which are to help us deliver high-quality
software e ectively.

12
Agile methodologies

There are many methodologies/frameworks, which are consistent with the principles of Agile
development. Most of them are similar and have many common elements. Examples of such agile
methodologies include::

Scrum
Kanban
13

Extreme Programming (XP)

Feature-Driven Development (FDD)
Crystal Clear
Test-Driven Development (TDD)

Source: https://medium.com/@hans.bruins/naked-scrum-81218f6f4833
Scrum 14
Scrum - history

Hirotaka Takeuchi and Ikujiro Nonaka used the name "Scrum" for the rst time in the context of
creating products (cars, printers, etc.) in the article entitled "The new product development game"
published by "Harvard Business Review" in 1986.

In the article, this approach was referred to as a holistic

approach, or rugby, as the entire process is executed by
one interdisciplinary team throughout numerous 15

overlapping phases, during which the team tries to cover a

certain distance as a team by passing the ball forward and
backward.
Scrum - history continued

In 1995 Ken Schwaber and Je Sutherland revealed their work describing the Scrum framework to
the world (in the context of software development) during their presentation at the "Business
Object Design and Implementation Workshop", which took place at the "Object-Oriented
Programming, Systems, Languages & Applications '95" (OOPSLA '95) conference in Texas.

In the following years, Schwaber and Sutherland continued their cooperation to eventually describe
what we know today as Scrum on the basis of the material they had presented in Texas. In 2009 they 16

published the "Scrum Guide", where they precisely de ned the Scrum framework rules and
assumptions.
What is Scrum?

Scrum - a framework within which people can Scrum is:

address complex adaptive problems, while lightweight,
productively and creatively delivering products
simple to understand,
of the highest possible value.
di cult to master.
17
Scrum - Pillars

Scrum employs an iterative, incremental approach to optimize predictability and control risk. The
framework is based on three pillars:

Transparency
It provides the team and everyone within the organization with access to the entirety of work and
the same understanding of each element of Scrum. This allows to avoid ambiguity and
misunderstandings. 18

Inspection
Allows for frequent monitoring and validation of the subject of work and performance of the
team.

Adaptation
Should be the result of Inspection and lead to the necessary changes which put the team on the
right track to continue their work.
Scrum - The Framework

19
Scrum - The Role

Scrum Team = Development Team + Product Owner + Scrum Master

Development Team
Responsible for delivering an Increment of the product at the end of each Sprint. It includes 3-9
people.

Product Owner 20
Responsible for maximizing the value of the product and the work of the Development Team and
for managing the backlog.

Scrum master
Responsible for ensuring that Scrum is properly understood and used. They make sure that the
Scrum Team follows Scrum assumptions, practices, and rules.
Scrum - Events

Prescribed events are used in Scrum to create regularity and to minimize the need for meetings not
de ned in Scrum. All events are time-limited. Each event (except for the Sprint) represents an
opportunity to inspect and adapt something.

Sprint
Sprint Planning
Daily Scrum
21

Sprint Review
Sprint Retrospective
Scrum - Sprint

Sprint is the most important event in Scrum. It usually takes from 1 to 4 weeks, during which a
"Done" (usable and releasable) product increment is created. Sprints include Sprint Planning, Daily
Scrums, development work, Sprint Review, Sprint Retrospective. During a Sprint:

No changes can be made which would endanger the delivery of the Sprint Goal
Quality goals cannot be lowered
The scope may be clari ed and re-negotiated between the Product Owner and Development
22

Team as more is learned.

Scrum - Sprint Planning and Daily Scrum
Sprint Planning
Planning of the work to be completed in a
Sprint
The entire Scrum Team takes part in it
The maximum duration is 8h (for monthly
Sprints)
The decision regarding the number of
Product Backlog issues to be selected for the
particular Sprint belongs to the Development
Team
Sprint Backlog is created
Sprint Goal is de ned
Daily Scrum
Event for the Development Team
Maximum duration of 15 minutes
Common meeting place
Progress evaluation with the Sprint Goal in
mind 23
Improves communication among the team
Allows to quickly discover and solve
problems, which the Development Team is
facing
Key meeting for the process of inspecting
and adapting
Scrum - Daily Scrum and questions

During the Daily Scrum event, current e orts are synchronized and a plan is drawn up for the
upcoming 24 hours. Every member of the team must answer the following questions:
• What did I do yesterday that helped the Development Team meet the Sprint Goal?
• What will I do today to help the Development Team meet the Sprint Goal?
• Do I see any impediment that prevents me or the Development Team from meeting the Sprint
Goal?
24
Scrum - Sprint Review and Retrospective
Sprint Review
Event organized at the end of a Sprint
The goal is to inspect the increment
The Scrum team presents the e ects of the
work in the Sprint to stakeholders
The purpose of the presentation of the
Increment is to elicit feedback and foster
collaboration
Duration - maximum of 4 hours
Discussion of what could be done next in the
following sprint
Sprint Retrospective
The Sprint Retrospective occurs after the
Sprint Review and prior to the next Sprint
Planning.
This is at most a three-hour meeting
Inspect how the last Sprint went with regards 25
to people, relationships, process, and tools
Identify the major items that went well and
potential improvements
Allows for inspection of activities to date and
drawing up of an improvement plan
Scrum - Artifacts

Scrum Artifacts help obtain a proper level of transparency and allow for inspection and adaptation.
They are speci cally designed to maximize transparency of key information so that everybody has
the same understanding of the artifact. Artifacts include:

Product Backlog
Sprint Backlog
Increment
26
Scrum - Product Backlog

Product Backlog
An ordered list of everything (characteristics,
features, requirements, improvements, and
adaptations) that is known with regards to
the development of the product.
It changes dynamically in order to improve
the competitiveness and usability of the 27
product
It is never complete (its early version initially
includes the known and mostly understood
requirements)
It is constantly re ned
Product Backlog items often include test
descriptions that will prove its completeness
when "Done".
Scrum - Sprint Backlog

Sprint Backlog
The set of Product Backlog items selected for
the Sprint
It should include at least one high priority
process improvement identi ed in the
previous Retrospective meeting
Only the Development Team can modify the 28

Sprint Backlog throughout the duration of

the Sprint
The purpose of the Sprint Backlog is to
monitor progress throughout the duration of
the Sprint
Scrum - Increment

Increment
The sum of all items of a Product Backlog
done throughout the Sprint along with the
product from previous Sprints
It has do be completed, ready to use and it
has to meet the Scrum Team’s de nition of
"Done". 29

Result of the work performed, which is

subject to inspection
A step towards the vision or goal
Scrum - De nition of "Done"

De nition of Done
A list of criteria, conditions, and
characteristics, which a story or an increment
must meet in order for us to be able to
consider it done
All members of the Scrum Team must know
what it means for an element of Backlog or 30
Increment to be "Done"
It helps the Development Team de ne how
many elements of the Product Backlog can
be selected for development during Sprint
Planning
The de nition of "Done" may also develop
along with the development of the Scrum
Team.
Scrum - De nition of "Done"

De nition of "Done" for a requirement

Code review carried out by another
developer
Code added to the main repository
All unit tests completed with a positive result
Acceptance tests - identi ed, written, and
executed 31

Functional tests completed with a positive

result
The feature is ready for release at any time,
with no need for further improvement
Weekly planning 32

Sprint planning
Weekly planning - tasks (1/2)
Throughout the workshop module of our course, the following tasks listed below should be
registered. The exercises will be assigned by the lecturer to Sprint 1.
IMPORTANT
To obtain a passing grade for this module all tasks must be completed by the course participant.
Work progress should be immediately registered in JIRA. The tasks will be discussed by lecturers
during Daily meetings.

33
TASKS
• Registration of exercises on JIRA.
• Completing the survey following module 1.
• Drawing up test cases for the Booking System app using the Testlink tool.
• Review of the MyStore app documentation.
• Executing exploratory tests for the MyStore app - registering errors.
Weekly planning - tasks (2/2)
TASKS continued
• Execution of retests for the registered errors in the MyStore app.
• Drawing up test cases for the improved features of the MyStore app with the use of the TestFlo
tool.
• Preparing a report summarizing the test work performed on MyStore.
• Participation in the Retrospective summarizing the course.
• Filling in the survey following the completion of the course. 34