The document outlines key aspects of agile testing and team dynamics, emphasizing the importance of collaboration among team members, effective communication, and the Scrum methodology. It discusses various testing strategies, including automated unit tests, exploratory testing, and the significance of product backlog management for prioritizing and estimating user stories. Additionally, it highlights the role of testers as active participants in the development process and the need for continuous improvement in quality assurance practices.

2. Role Of A Tester
Skills
Testing Tools
Team Structure
Supporting The Team
High Quality
CI
Feedback Loops
ATDD/TDD
Exploratory Testing
Automation
Company structure

3. Product Owner workshop by Practical Agile is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.
A-HA wall
Parking lot

4. Product Owner workshop by Practical Agile is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.
4

5. Product Owner workshop by Practical Agile is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.
5

6. Product Owner workshop by Practical Agile is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.
Photos

7. Product Owner workshop by Practical Agile is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.

16. In each Group:
What are the 3 biggest issues your facing today,
with you development process?
Lets Discuss

17. Eliminate waste.
Faster release cycles.
Deliver maximum business value.
Measure and improve.
Respond to change.
Increase quality.
Have Fun.

18. SCRUM is very simple
A complex process draws focus from real issues.
SCRUM maximize feedback
Using SCRUM everything is known.
All the information to enable good decision
making
SCRUM is flexible
Gives the ability to respond to change
Inspect and adapt

20. First Step – Prepare the Product Backlog
Stories Priority Estimate
As a user I want to be able to input disability % data using a GUI, so it will be
faster.
1 5
As a user I want to get the calculation result for a complex case 2 3
As a developer I want to be able to input disability % data using a text file, so it
can be easier to test.
3 1
As a user I want to be able to store result to a file 4 1
As a user I want to be able to easily install the application. 5 3
As a user I want to be able to learn how to use the application 6 2

21. A story represents a requirement
3C’s – Ron Jeffries
Card – Placeholder for conversation
Conversation – discussion between implementer
and customer
Confirmation – Definition Of Done (DOD)
Possible format:
As a ____ I want ______ so that _____.

22. Stories Pri. Est.
As a user I want … 1 5
As a user I want … 2 3
As a user I want … 3 1
As a user I want … 4 1
Stories Pri. Est.
As a user I want … 1 5
As a user I want … 2 3
As a user I want … 3 1
As a user I want … 4 1
As a user I want … 5 3
As a user I want … 6 1
As a user I want … 7 1
As a user I want … 8 3
As a user I want … 9 1
As a user I want … 10 1
Sprint 2
Rest
Stories Priority Estimate
As a user I want … 1 5
As a user I want … 2 3
As a user I want … 3 1
As a user I want … 4 1
As a user I want … 5 3
As a user I want … 6 5
As a user I want … 7 3
As a user I want … 8 1
As a user I want … 9 1
As a user I want … 10 3
As a user I want … 11 5
As a user I want … 12 3
As a user I want … 13 1
As a user I want … 14 1
As a user I want … 15 3
As a user I want … 16 5
As a user I want … 17 3
As a user I want … 18 1
… … …
Product Backlog
Stories Pri. Est.
As a user I want … 1 5
As a user I want … 2 3
As a user I want … 3 1
As a user I want … 4 1
As a user I want … 5 3
As a user I want … 6 5
Sprint 1

23. Sprint is a short cycle in which work get done.
Typically between 1-4 weeks
Once started, content does not change
Goal
Allow the team to work, without interference, in
order to produce a potentially shippable product
that will increase business value.
A sprint results in a Product Increment.

24. Product Backlog
Sprint Planning
Story To Do In Progress Done
As a user…
As a user…
As a user…
As a user…
Stories Priority Estimate
As a user I want … 1 5
As a user I want … 2 3
As a user I want … 3 1
As a user I want … 4 1
As a user I want … 5 3
As a user I want … 6 5
As a user I want … 7 3
As a user I want … 8 1
As a user I want … 9 1
As a user I want … 10 3
As a user I want … 11 5
As a user I want … 12 3
As a user I want … 13 1
As a user I want … 14 1
As a user I want … 15 3
As a user I want … 16 5
As a user I want … 17 3
As a user I want … 18 1
As a user I want … 19 1
As a user I want … 20 3
As a user I want … 21 5
As a user I want … 22 3
… … …

25. Stand up meeting held every day (15 minutes).
Each team member answer 3 questions (only)
What has he done the previous day,
What is he going to do today
Is there anything holding him back (that the team
can help with).
Goals
Daily planning
Communication with other team members

26. Get feedback
General feedback – are we headed in the right
direction
Specific feedback – to the stories completed
feedback should reflect in product backlog.

27. Scrum is an adaptive process
Review what went well and we want to keep,
and what needs to be changed.
Team forming
Let the team be heard
Let the team handle issues
Reflect on overall plan
Changes to release plans.
Changes to goals.

28. Agile = no process
Scrum is a rigorous process.
Agile = No Documentation
Agile stresses only needed documentation.
Agile = No Design
Design is an ongoing activity.
Agile = No Planning
Just in Time & just enough Information.
Agile = Small Teams
Has been scaled to very large groups (hundreds).

30. Goal Setting (on many levels)
Responsible for the ROI.
Responsible for the product backlog
Writing Stories
Prioritization
Updating backlog
Helps the developers understand what needs to be
done
DOD – Definition Of Done
Conflicts resolution
Approval of work.

31. Part of the Team
No Authority on the team
Roles
Obstacle remover
Facilitator
External communication
Responsible for the process
Shield the Team

33. Estimate story size
Split stories into tasks (sprint planning)
Estimate tasks
Build the product
In charge of quality
Communicate progress and impediments
Improve!

34. In each Group:
Go over the list of issues we have and see if you
can find things in the process that might address
them.
Lets Discuss

37. Team size should be 5-9 members.
Focus on team results:
• Team must share a common goal.
Team should be heterogeneous:
• Include coders, testers, DBA, GUI,…
Self Contained teams:
• All required skills are present at the team level.
• Allow the team to progress at full speed.

38. 1. Forming
polite but untrusting.
2. Storming
I know best.
3. Norming
Maybe they can help me.
4. Performing
They are really good.
Tuckman added a 5th stage 10 years later:
5. Adjourning
Time to move on.

40. Versatile
Should be able to do several things.
Responsible
Take ownership of the process
Collaborative
“Lone wolves” generally does not fit an
agile team.

41. Development and QA are often
operational silos.
Tests are derived from detailed
requirements and specifications.
Usually don’t actively participate in
planning
Almost never help in the product design

42. Testers are often viewed as second class
citizens
They are not active partners at building the
product
Developers considers testing as an obstacle in
the delivery process.
Testers do not get the necessary knowledge
(from R&D) to test effectively.

43. Represents the customer.
Approve new work.
Improve the testing process.
May help in defects handling.

44. Help define and elicit the acceptance criteria
(or requirements)
Preferably in the form of automated acceptance
tests.
Work with the customer (PO) to identify risks
If its hard to test it might be very hard to use.
Provide information to customer about
Quality.

45. Performing regression tests
When major changes are about to be
committed.
Validate acceptance criteria's
Exploratory testing
Put more testing effort into the areas where
the developers tests (unit and integration)
are weakest.

46. Quality must have an owner.
Train developers in effective testing.
Build specialized internal testing
tools
Identify trends and areas of
deteriorating quality.

47. Two main strategies
Handle as they come
Postpone until next cycle and schedule as any other
feature.
Pragmatic approach
Allocate resources for treating critical defects as they
come.
Postpone the rest (or when allocated resources are
not enough)

48. Reproduce Defect
Work with customer to understand the issue.
Initial investigation
Is it a defect or a misunderstanding.
Root Cause Analysis
Defects are not acceptable.
Verify fix
To make sure this wont happen again.

52. In each Group:
Find a volunteer.
Have him map out his team/company testing process.
Write down the different kinds/Levels of testing they
perform.
Try to find how much effort is allocated to each kind
Lets Discuss

54. The testing quadrants:
Q1: UTs, component tests
Q2: Functional tests, examples, story tests,
prototyping, simulators
Q3: Exploratory tests, Scenarios, Usability testing,
UAT, Alpha/Beta
Q4: Performance & load tests, Security tests,
“illities” tests

56. The foundation that supports all of the rest.
Make up the majority of the automation test scripts
Written usually in the same language of the production
code is, to increase communication within the team
members, using xUnit family of tools
After mastering TDD, these tests are with the most ROI,
which means the least expensive ones
Very effective at catching regression bug
Usually done by the programmer who writes the code

57. Most of the automated business-facing tests
Functional tests that verify we are “building the
right thing”
Operate at the API level, “below the GUI”
Because these tests bypass the presentation
layer, they are less expensive to write and
maintain, and they are less brittle
Should be written in domain specific language,
that customers understand
They run more slowly, to cover complex
scenarios

58. Focus on GUI operated tests:
Provides the lowest ROI in the pyramid
Manipulate the system via the presentation layer
Written after code is completed, to critique the
product
Likely to change often – as often as GUI changes
Run slow & breaks often– so we try to lower the
number of tests there.
Never use a recorder to generate them

59. Have a lot of value
Should be intelligent (not scripted)
Utilize human advantages over the computer
(exploratory testing)

60. If I Could have 3 magic boxes, I would
like to know:
1. Am I doing things right?
2. Am I doing the right things?
3. Am I Adding Business Value?

61. This is what unit test are used for.
Unit tests:
Are fast
Test each unit in isolation
Enable me to test all paths of my code
Will improve my technical design

62. E2E tests are a good tool for:
Help me understand the requirements
E2E tests:
Goes through all the system
Help me understand how the system
behaves
Help me refine Acceptance Criteria

64. Automated Unit 60% - 70%
Automated E2E 20% - 30%
Exploratory 20% - 30%

65. Unit Testing
An integral part of the coding phase. (TDD)
All code should be tested before it moves to next
stage
E2E Testing
Most of the effort is done as part of the requirement.
Actual automation in parallel to coding
Exploratory Testing
Final activity before Done.

66. Unit Testing
Programmers (Each on his own code)
E2E Testing
Product + Testers (Programmers) – define
the test scenarios
Test Engineers/Programmers - Automation
Exploratory Testing
Expert testers

67. Developed by Elisabeth Hendriksom

69. The system need to work
We need to be able to deploy it
Satisfy minimum functionality
Enough is enough
Minimum viable product (Lean Startup)

70. The system needs to work well
Scalability
Security
Availability…
Enough is enough
Quantify your goals.

71. Can the system be used?
User Interaction design
Graphical design
Creating a community

72. The system needs to help the users
Are the feature in use?
The 80-20 rule
Take out the feature which are not used
they have negative ROI

73. The system solves a business problem
Does it saves money?
Does it save time?
What are the business goals?
Was it right for the business in the first place?