Presentation from TestWarez 2010 conference in Bydgoszcz, Poland

1. Testwarez 2010
© Krystian Kaczor 2010

2. Tester/Test Manager/Test Lead
Certified ScrumMaster & Certified Scrum Professional
NLP Practitioner
7 years of experience on projects in Sweden, Poland,
Iran, Netherlands
Experience in the whole Software Development Life
Cycle
Active member of goldenline.pl forum
2© Krystian Kaczor 2010

4. Iterations
Transparency
Simplicity
Refactoring
Working product at the end of every
iteration
4© Krystian Kaczor 2010

5. Changing requirements is possible
Self-organized, cross-functional team of
professionals
Small teams (in Scrum 5-9 people)
Informal communication – face to face
Continuous improvement – inspect and
adapt
5© Krystian Kaczor 2010

6. The software is:
 delivered on time,
 integrated,
 tested.
Definition of DONE is fulfilled
Business accepts the result of the Sprint
Product is potentially shippable after iteration

7. Feedback is immediate. Simple chat is
above reporting of everything.
Direct cooperation with business and
developers
No time for manual regression testing
Test describe expectations and
requirements
Defects are fixed immediately

8. Test Driven approach
Testing doesn’t stop release, but allows
the project to progress
There is no Test Team, there is only the
Scrum Team
Tester gives feedback and additional
information

9. There is no software handover for testing,
testing is continuous
Everybody tests
No ‘blaming game’
We change the discipline from relay race
to football

10. Every Story and task is testable,
Code is written and complete,
Task is completely done,
Code was reviewed,
Tested,
No errors in Continuous Integration,
No exceptions in Tomcat’s logs,
Documented (JavaDoc is mandatory)

11. 1. Bug-fix (fixing of new defects)
2. Code review
3. New code

12. Check all acceptance criteria,
System Testing,
Defects fixing, but only critical,
There is no new code and new features,
UAT,
Trainings for employees,
Instructions for support update
Final retrospective summarizing release,

13. Project Initiation
Release Planning
Every Iteration
Documentation reading, project understanding
Participation in Story
estimation
Ask for examples, ask
‘What if … ?’
Test Plan writing
Write and execute Story test
Write and execute functional tests
Confirm bug-fix
Pair-testing with testers and developers
„Show me”
Functional tests automation
Automated test execution
Exploratory testing
Iteration Planning Test tasks creating and
estimating
AcceptanceCriteria
validation and adding new

14. Release & Support
End Game
Add you remarks from testers point of view,
testing, processes, business support
Execute performance tests
Execute RegressionTests
Execute UAT
Execute SystemTesting
Test documentation of installation and support
Participate in Release preparation
Participate in Release in Production
Participate in Retrospection
Iteration
Retrospective

15. Elements of User Story
 As… (specific System User)
 I want… (desired feature or an issue that
needs to be solved)
 So that… (benefit from Story implementation)
Acceptance Criteria
 Details specified in form of acceptance tests
15© Krystian Kaczor 2010

16. A good User Story is:
Independent
Negotiable
Valuable
Estimable
Sized Appropriately
Testable
16© Krystian Kaczor 2010

17. Story doesn’t overlap with another one, so
we can implement them in any order
It is easier to estimate and plan such a
Story
You can change priority without impact on
other Stories
17© Krystian Kaczor 2010

18. Story is not a contract for doing specific
work
There is still enough room and flexibility to
specify the details together with customer
Covers only concept, doesn’t give solution
18© Krystian Kaczor 2010

19. Story has value
Story shows value for customer, not
developer
Technical requirements should be written
in a from reflecting benefit for the
customer
In case of splitting Stories to smaller once,
each of them needs to represent value for
customer
19© Krystian Kaczor 2010

20. You can estimate the Story
Estimation doesn’t need to be precise
Story is written in a way, that it is easy to
estimate it
20© Krystian Kaczor 2010

21. Story should be as small as possible
Story has a size proper for estimation on
level of Project, Release, Iteration
21© Krystian Kaczor 2010

22. Every Story with no exception has to be
testable
Test doesn’t necessary have to be
automated
If the customer of PO doesn’t know what
are the acceptance criteria, so doesn’t
know how to test that story, he or she
doesn’t understand it or the Story has no
business value
22© Krystian Kaczor 2010

23. Minimal valuable piece
Steal thread
In 2-weeks Sprint story can not be longer
than 3 days
Still delivers some value
Is testable
23© Krystian Kaczor 2010

24. 24© Krystian Kaczor 2010
Selecting Product
Order Creation
Billing
Shipping
Reporting

25. 25© Krystian Kaczor 2010
Design
Architecture
AcceptanceTests
Code
Integration
Database

26. 26© Krystian Kaczor 2010
Card Conversation Confirmation
Stories are written
on index cards
Index cards have
annotation with
estimation, notes,
etc.
Details of the Story
reveal during
discussion with
Product Owner
AcceptanceTest
confirm that
implementation of
the Story is correct
REQUIREMENT

28. NO FEATURES!

29. xUnit tests are the base layer
 Gives the fastest feedback
 The best ROI
Middle layer
 Becomes functional regression tests
GUI layer
 Can be partially automated
 Mainly exploratory testing

30. 30© Krystian Kaczor 2010

31. 31© Krystian Kaczor 2010

32. 32© Krystian Kaczor 2010

33. 33© Krystian Kaczor 2010

34. 2014 Remarks
• This was the original presentation shown at
TestWarez conference in 2010
• So called experts didn’t believe me and tried to
undermine my speech
• I said that testing industry lead by ISTQB is 5
years behind the market
• I was wrong
• ISTQB published Agile Tester add-on in 2014
• Check the difference between the syllabus and
contented of the slides you have just seen ;)
34

35. Check my book (in Polish)
35

36. Thank you
krystian.kaczor@qagile.pl
@krystian_kaczor
www.qagile.pl
Krystian Kaczor
36