Scrum Master's experiences and thoughts
about modern tester
Henri Karhatsu
Testausyhdistys - iltaseminaari - 26.5.2014
Real experiences...
And I am...
10+ years of software development
Scrum Master, Java / Ruby on Rails developer
(never been a tester)
What's common in all of those projects?
Software works as wanted, few bugs, especially...
Really few regression bugs
(both during development and in production)
Regression bug
"This thing has worked before but
not anymore after the latest change."
Why regression bugs are especially important?
Because TRUST
("It's all about trust")
Example why trust is important
Initial plan:
After the "development" phase,
deploy new version every two weeks
during the "testing" phase.
Team shows that it can produce stable software all the time.
=> Deploy anytime you want, in practice twice a day.
=> Faster feedback and other benefits from smaller batches.
Way of working
Automated testing in two levels:
Unit tests by the programmers
End-to-end tests by the team
Great way to ensure good enough test coverage
End-to-end testing with Robot Framework
1 project: ATDD (test-before)
1 project: test-after by the developers
1 project: test-after by the tester
Feedback in many different phases
After planning (business stakeholders), during/after coding (TDD / code reviews / pair programming / Jenkins), after coding (tester), when probably done (business stakeholders)
Tester = feedback giver
Feedback most valuable when
you get it fast (tester part of the team),
you are told something you didn't know.
Building the test suite all the time.
When a tester finds a problem, write a failing test for it, fix the problem, and see no regression.
Good end-to-end test suite can also reveal regression in other systems.
We have automated tests, do we need a tester?
Don't worry, you are really important people in successful software development teams.
(But let computers do what they are best at
and focus on things where people are better than computers.)
Qualities of modern tester
Together with the other team members creates such conditions that regression won't be an issue
When regression isn't an issue, the tester can focus on more valuable things (exploration) than repeating the same checks all over again
Increases trust together with the team
Analytical thinking and calmness
How can we together solve this problem in a long-lasting way?
user > specification
Gives fast (system property) feedback in a way that gives the programmers good chances to continue from there.
Instead of "here's a bug",
"here's a bug that occurs in these conditions but not in these".
What is missing here?
How did we test in the projects that we were building the right thing?
Qualities of modern tester (bonus)
Provide tools and create conditions for testing if we are building the right thing instead of just building something right
Thank you!