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.
8.
9.
10.
11.
12.
13.
14.
15.
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
19.
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. Help in Story Writing
Help to define the scope of the stories
Write Acceptance criteria
Think on Testing aspects
What other thing we need to consider?
Planning
Help with Story estimation
Make sure there is enough time to test
24. 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.
25. 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
… … …
26. Understanding the story
Explain how this is going to be tested
Ask question that will help to set clear scope
boundaries
Task decomposition
Add testing tasks (what about automation)
Make sure programmer do some unit test
What about setting up the system?
Help with estimation
27. 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
28. Report on your progress
Push work to testing as soon as possible
Guard the sprint time-box
Will there be enough time for testing?
“Code that isn't tested doesn't work—
this seems to be the safe assumption.”
Kent Beck 2002
29. Get feedback
General feedback – are we headed in the right
direction
Specific feedback – to the stories completed
feedback should reflect in product backlog.
30. Share your story
What have been done (and tested)
Where do you feel are the weak points?
Provide general feedback to the PO &
stakeholders
31. 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.
32. 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).
33.
34. “The Product Owner is responsible for
maximizing the value of the product and the
work of the Development Team… The Product
Owner is the sole person responsible for
managing the Product Backlog …. The Product
Owner may do the above work, or have the
Development Team do it. However, the
Product Owner remains accountable. … The
Product Owner is one person…” – Scrum guide
35. 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
Product conflicts resolution
36. “The Scrum Master is responsible for ensuring
Scrum is understood and enacted … The
Scrum Master is a servant-leader for the
Scrum Team. The Scrum Master helps those
outside the Scrum Team understand which of
their interactions with the Scrum Team are
helpful and which aren’t. The Scrum Master
helps everyone change these interactions to
maximize the value created by the Scrum
Team.” – Scrum guide
37. Finding techniques for effective Product Backlog
management
Helping the Scrum Team understand the need for
clear and concise Product Backlog items
Understanding product planning in an empirical
environment
Ensuring the Product Owner knows how to
arrange the Product Backlog to maximize value
Understanding and practicing agility
Facilitating Scrum events as requested or needed.
38. Coaching the Development Team in self-
organization and cross-functionality
Helping the Development Team to create high-
value products
Removing impediments to the Development
Team’s progress
Facilitating Scrum events as requested or needed
Coaching the Development Team in
organizational environments in which Scrum is
not yet fully adopted and understood.
39. Leading and coaching the organization in its Scrum
adoption
Planning Scrum implementations within the
organization
Helping employees and stakeholders understand and
enact Scrum and empirical product development
Causing change that increases the productivity of the
Scrum Team
Working with other Scrum Masters to increase the
effectiveness of the application of Scrum in the
organization.
40.
41. “The Development Team The Development
Team consists of professionals who do the work
of delivering a potentially releasable Increment
of “Done” product at the end of each Sprint. …
Development Teams are structured and
empowered by the organization to organize and
manage their own work…” – Scrum Guide
42. They are self-organizing.
Development Teams are cross-functional
Scrum recognizes no titles for Development Team
members other than
Scrum recognizes no sub-teams in the
Development Team
Individual Development Team members may have
specialized skills and areas of focus, but
accountability belongs to the Development Team
as a whole.
43. 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
44.
45.
46. 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.
47. 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.
48.
49. Versatile
Should be able to do several things.
Responsible
Take ownership of the process
Collaborative
“Lone wolves” generally does not fit an
agile team.
50. 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
51. 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.
53. 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.
54. 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.
55. Quality must have an owner.
Train developers in effective testing.
Build specialized internal testing
tools
Identify trends and areas of
deteriorating quality.
56. 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)
57. 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.
58.
59.
60.
61.
62. Stakeholders always have questions:
What’s the status?
When will you finish?
Why is it taking so long?
Is the testing of __________ finished?
65. None - No Plan to Test
Start - Expect to start testing soon
Low - Mainly regression, keeping cov.
High - In focus, increase cov.
Pause - hard to test/stopped for now
Blocked – Cant test this for now
Ship - Final testing before live
66. 0 We don’t know
1 Sanity only
1+ some functional, not all
2 Finished Common cases + some
2+ did some error & edge cases
3 All Corner cases covered
67.
We don’t know about any problems that
should stop production or suspect any.
We know of possible showstoppers, or
suspect there are some severe issues
We have issue that should not reach
production,.
68.
69.
70. 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?
71. 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
72. 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
73.
74.
75. The foundation that supports all of the rest.
Majority of effort should be invested at this
level.
Very cheap to write and maintain, have high
ROI.
Very effective at catching regression bug
Usually done by the programmer who
writes the code
76. Should & can be automated
Relatively cheap to write and maintain
Business-facing tests
Functional tests that verify we are “building the
right thing”
Should be written in domain specific language,
that customers understand
Operate at the API level, “below the GUI”
They run more slowly, to cover complex
scenarios
77. Focus on GUI operated tests:
Written after code is completed, to critique
the product
Likely to change often (high maintenance)–
as often as GUI changes
Run slow & breaks often
so we try to keep the number small
Never use a recorder to generate them
78. Have a lot of value
Should be intelligent (not scripted)
Utilize human advantages over the computer
(exploratory testing)
79. In Pairs:
Find a volunteer.
Have him map out his team/company testing
process.
Write down the different kinds/Levels of testing
they perform.
See if you can draw out his pyramid
Lets Discuss
81. 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.
82. 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
Learning competition: Each team has a different color of sticky notes, The team with the most post-it’s on the wall wins.
Feedback. please use the wall throughout the day so i can adapt to your needs.
At the end of the day you have a free choice of which shade of green to use as the feedback card.
Always feel free to ask questions
Or hear from me…
Ask permission to take photoes
Theory Vs Practice
Lets talk in general about scrum
Agile Key Principle:
Power Of Three (QA+Product+Programmers) (bring everyone to the table)
Working In High Quality
Feedback – Excercide – what can you do in your team to shorten the feedback loop?
Late Feedback is useless
The Process – Scrum
Debrief and Draw scrum on a flipchart
(Probably a good time to take a break)
Lets do a deeper Dive into the process
Pigs and chickens
Not its done and we tested,
more like:
“its done and were very confident it works well and the entire system are is rock solid.”
There’s a tough decision to make – can we release this?
Roles
For the Product Owner to succeed, the entire organization must respect his or her decisions. The Product Owner’s decisions are visible in the content and ordering of the Product Backlog. No one is allowed to tell the Development Teamto work from a different set of requirements, and the Development Team isn’t allowed to act on what anyone else says.
Scrum guide
Scrum guide
Scrum guide
They are self-organizing. No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality;
Development Teams are cross-functional, with all of the skills as a team necessary to create a product Increment
Scrum recognizes no titles for Development Team members other than Developer, regardless of the work being performed by the person;there are no exceptions to this rule
Scrum recognizes no sub-teams in the Development Team, regardless of particular domains that need to be addressed like testing or business analysis; there are no exceptions to this rule; and
Individual Development Team members may have specialized skills and areas of focus, but accountability belongs to the Development Team as a whole.
But first a short demonstration – circle with two friends
Provide feedback
Lets draft a job posting
Focus on:
What is the goal of the role? – 5 minutes
What will he do/be in charge of? – 5 minutes
What skills would you must have, - 3 minutes
What skills would you like to get as well
What kind of Traits the person should have
What kind of experience/Education do you need from him
And they always lack patient to hear all the details!!!!
Product Areas – 10-15 no more. Major parts of the system, which are important/significant to stake holders
(wht are the top 10 things you system need to do?)
Feel free to change add your own levels, make sure everyone understand what they mean
Use red to mark significant problems
Use green to denote were done, everything else is green, and we can ship (or almost there)
Black – in process
Color green if coverage is enough for shipping
Otherwise balck
0 -1+ does this product work at all
2 most of testing – 50-90% fnctionality coverage
2+ - did some ilities testing, can this product work in live?
3 – if there was a bad bug, we would have known
in groups, pick a produt from one of the companies,
Think of the areas (come up with 10 and explain to the entire group) – this should cover your system,
Think of the current effort invested in the various areas for the upcoming release
Think of the coverage goal and the current state
Do you know of any specific issues in those areas – try to use real data as much as possible
Business KPI’s
Here comes DevOps
Because these tests bypass the presentation layer, they are less expensive to write and maintain, and they are less brittle
Recorder is only good to discover the GUI layout
Exploratory testing is the key word here
Not the same organization
When finished switch
If have time…
Q4 – we can automate the run, but most likely we need someone to analyze the results
Discuss – take the backlog, create a shared understanding using examples (create the g/w/t acceptance criteria)
Develop – in parallel automate the AC (Fixture Code), develop UT & production (using TDD)
Deliver – run final manual tests, and deliver the new features (Preferably to a Real client)
Lets discuss about testing strategy
* We skip the unit level – cause that a perliminary condition before everything else
Tools
Testing Tools
Build Servers
Management Tools
Lets talk about BDD/ATDD
Testing over the GUI & Recording
First lets avoid recording – it doesn’t work!!!!!!
it goes like this:
You manually record all your tests (using manual testers which don’t know how to code)
Then the system changes
now you need to record them all over again (now isnt that manual testing?)
Alternatively you give the tests to someone to fix.
but they are not abstracted in any fashion – so the first time someone does this it usually takes a lot lot longer than just record them all over again
Lose-Lose
2) While the gui is probably the most obvious way to tap into the system fuctionality.
In most system, it’s the the most cumbersome, error prone and unstable. And on the way you couple your test into the GUI structure (which for many modern system is the most dynamic part which changes often
Buttom line – try to avoid as much as possible.