TL;DR
In the previous post, we gave a report on Taming the Quality Dragon by Jana Gierloff. Today we bring you a report on A Case of Failure: Pinpointing A Problem for Correction by Maaret Pyhäjärvi, the last session of Online Test Conf Autumn 2020 first day sessions. Maaret energy goes this time to thinking of our role as reporters of information to create change.
Takeaways
Thinking of our role as reporters of information to create change. What kind of information truly moves our colleagues and organizations and makes a difference, and when should we turn from information providers to full contributors on solutions?
Let’s Learn From Junior’s
Maaret is a great storyteller; I had the privilege to listen to her stories live during the European Testing Conference 2018 and 2020, and Testival 2015. And of course, on her blog, A Seasoned Tester’s Crystal Ball. Her story starts with junior software testers. They stuck with a problem. Robot Framework for Browser automation tests just stopped to work on their computer. The problem was caused by the new version of the Browser library upon which Robot Framework depends on. The problem’s root cause was identified in a conversation between three software testers, where one was just observing the conversation. Note observing, not just listening. Maaret noticed one common thing during root cause analysis conversations, and that is jump to conclusions. Remember the rule of three in such situations.
Let’s F.A.I.L.
FAIL is First Attempt In Learning Acronym. It means that it is ok to fail when you are learning something new because, during the process, you learn why you failed. Of course, as long as failure is not exploited for its own benefit. You still need to learn the topic. Maaret encourages Juniors to learn with FAIL.
Put Problems In Cynefin Model
Cynefin model helps us to learn by moving from Chaotic to Obvious. Maaret relates Cynefin quadrants with a “who build it” relation. For example, if we have a problem with something built by someone else, it is obvious how to solve it. Seek solution by asking the builder (this could be reading the documentation).
Software Testers Skill Growth
Maaret sets these stages of software tester’s skill growth:
How To Report A Problem
When we identify the problem, we need to report it. We usually call this bug report. These could be done unprofessionally, with headline Login page does not load, or professionally using RIMGEA acronym:
When you master RIMGEA, you will learn the following facts for excellent bug reports:
- To replicate the bug, set variables in the state before the bug, then change them.
- Which symptoms are important for the observed behavior
- Write a report for super tired developer
Quote Alert
Canvas For Experiments
Maaret finishes with Canvas For Experiments. It is a test strategy for hunting the root cause problems. She gave examples of problems hunted with this canvas:
- Change JIRA flow
- Late Automation when developers do not test late change
Conclusion
The truth is that everybody is afraid of changes. But when you set a change experiment with upfront notice that even a successful experiment could be rejected, it is much easier to start the experiment in the first place. Experiments should be directed in information discovery, so software testers could also have enough information to make decisions. And of course:
You can learn a lot from juniors.
I agree with that. While instructing the BBST AST courses, I learned a lot (from BBST topic juniors) from student answers on BBST topics. It is always a good thing to get another perspective on software testing topics.
Q&A
Testivator Session Score
For this session, I was using the Testivator Mobile application. I took 23 notes and 7 screenshots.
Here are note types by duration. Till the end is 3.9 %, and it is the ratio of duration from last note to session end and session duration.
