TestBash: Quality Does Not Belong With the Tester!
Quality Does not Belong with
the Tester!
Maaret Pyhäjärvi
Email: <maaret@iki.fi> | Twitter: maaretp
Maaret Pyhäjärvi
Nimeä | Attribution (Finland)
http://creativecommons.org/licenses/by/1.0/fi/
http://creativecommons.org/licenses/by/1.0/fi/deed.en
Adding a Tester Can Make Things
Worse
• Perception change: from everyone’s work to
one person’s specialty
– Same work twice: the developer and the tester?
– Slap in the developer’s face with different results
• Feedback did not work well with lack of
design & programming skills
– F ear and Consequences of not getting good
enough
• The fixing backlog
– More developer work
Quality and the Developer
• From slap in the face to shared insight of
first experience through pairing
• Learning to think of connected concepts,
not just connected code both before and
after implementation
• Relying on ‘own testing’ and skipping
tester-testing as experiment
• Making testing a programming problem:
automation
Summary
• I’m not responsible for production quality,
developers are
– I help but my efforts are easy to attenuate with
what the developers do
• Working with the culture of collaboration
makes a huge difference
– Experiments with a reluctant team
– Avoiding clear roles keeps everyone alert
– Nobody is “just” something these days
Editor's Notes
Lean coffee this morning
A personal growth and learning story: from no testers to one to realize things have to change.
From consultant and test manager to the only tester in a team of 9 for first hand experience
Big fan of agile software development
“no longer a test manager” – same here (reference to an earlier talk)
Title change -> show there’s nothing I could do but there’s plenty some other’s in the team can’t do.
Always feeling responsible because I can and I will! – and have! A bit of a control freak… Higher expectations on myself than others.
So with this, the idea that there are problems in production, no-one needed to tell me that it was my fault. I would always analyze every one of those I could. And I don’t really recall ever hearing in a project the words “testers should have found this”.
Testers don’t break your code, they break your illusions about the code.
-- adapted from James Bach
I’ve worked with teams of testers, the context of being ALONE is a new experience
Only woman. Only one that does not stay in the expected box. Only tester. First tester ever. Not believing non-users can know. Knowing of problems without steps to repro.
First I found a lot of problems and we got into fixing them. The backlogs would grow… And With longer backlogs and more developer work, the less interest they would have on using time on test.
As there were so many problems to find, I felt we could use more testers – but that would just make the overall thing worse. So I adviced to hire fixers.
Systems thinking: testing serves a purpose of information for software development only if the information can be usefully consumed
Fix one, break 2: brittle code from some of the developers
Not getting good enough: having 2 devs dismissed from the product development teams
Continuous deployment with Git feature branches
Focusing on throughput time makes fix cycles highly visible
Needed to experiment with how the atmosphere would change, these I found that worked for us: me & my devs.
Connected concepts: it’s really about talking and creating understanding that is enactable by the developers who, in my team, seem naturally inclined to code not the business concepts
Devs will come in the middle of the night to fix it, I can still just say that it was already broken.
You can suggest things that are not “in your role”. I’ve changed project management. I’ve changed how we recruit and train developers. I’ve changed how we work as a team. I’ve changed how we do unit testing and test automation in general. Just a few examples.
And I still test in an exploratory fashion most of my days.