TestBash: Quality Does Not Belong With the Tester!
Download as PPTX, PDF1 like925 views
Quality does not belong solely with the tester. Adding a tester can sometimes make things worse by changing perceptions and creating a lack of shared understanding between developers and testers. It is better for developers to take responsibility for quality and think of testing as part of the development process through techniques like pairing with testers, considering broader concepts during development, and automating tests. Fostering a collaborative culture where roles are blurred and everyone shares responsibility for quality is most effective.
TestBash: Quality Does Not Belong With the Tester!
- 1. 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
- 3. DIFFERENT
- 5. 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
- 7. 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
- 8. 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
- #2: 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.
- #3: 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
- #4: 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.
- #5: 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
- #6: Fix one, break 2: brittle code from some of the developers Not getting good enough: having 2 devs dismissed from the product development teams
- #7: Continuous deployment with Git feature branches Focusing on throughput time makes fix cycles highly visible
- #8: 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
- #9: 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.