When first seeing the Friction commentary, a specific moment came to mind. Often friction is a call to improve. The friction exists due to a need not being met, a shortcoming in your practices or understanding.
Years back I had just joined a new company and was given a senior mentor. As I set about my work, I was rapidly sending out pull requests for test automation, contributing to a large library of tests. At the same time as my tickets piled up, the 'Mentor left a comment', 'PR marked as Needs Work' or 'PR Rejected' emails stacked higher still. I talked to him frequently, tried to resolve his comments as quickly as I could, make the requested changes, but not fast enough to clear the ever growing stack along with my own frustration. The tests passed - why couldnt he just let me merge already?
Eventually I began pro-actively adding detailed notes to my pull requests. Long comments explaining why I was using a given architecture, why this test was needed, why it took this path through the system, etc etc. With that, and some more time, my code did pass through review almost silently, approved quickly with few comments
It took many years to reflect back on this. The feedback I was being given tacitly was to think critically about the tests and be able to explain and defend them. My mentor did not think I was wrong per-se, he didnt know better then me all the time, nor did he simply want everything done his way. He simply needed to know I could defend my tests. If I could defend them to his scrutiny, he and I both could defend them to others together.
In QA, we are the last line of checks to be done. There are no further checks on our tests, so our test have to be right - well architected, meaningful, written correctly, easily explainable, and well understood. These tests would be maintained by the entire team, potentially years into the future. If the tests fail (or pass when they shouldnt), we have to be able to defend them. If I could not explain them adequately, if I could not defend them under scrutiny, they were no good no matter how well intentioned I was in creating them.
Years back I had just joined a new company and was given a senior mentor. As I set about my work, I was rapidly sending out pull requests for test automation, contributing to a large library of tests. At the same time as my tickets piled up, the 'Mentor left a comment', 'PR marked as Needs Work' or 'PR Rejected' emails stacked higher still. I talked to him frequently, tried to resolve his comments as quickly as I could, make the requested changes, but not fast enough to clear the ever growing stack along with my own frustration. The tests passed - why couldnt he just let me merge already?
Eventually I began pro-actively adding detailed notes to my pull requests. Long comments explaining why I was using a given architecture, why this test was needed, why it took this path through the system, etc etc. With that, and some more time, my code did pass through review almost silently, approved quickly with few comments
It took many years to reflect back on this. The feedback I was being given tacitly was to think critically about the tests and be able to explain and defend them. My mentor did not think I was wrong per-se, he didnt know better then me all the time, nor did he simply want everything done his way. He simply needed to know I could defend my tests. If I could defend them to his scrutiny, he and I both could defend them to others together.
In QA, we are the last line of checks to be done. There are no further checks on our tests, so our test have to be right - well architected, meaningful, written correctly, easily explainable, and well understood. These tests would be maintained by the entire team, potentially years into the future. If the tests fail (or pass when they shouldnt), we have to be able to defend them. If I could not explain them adequately, if I could not defend them under scrutiny, they were no good no matter how well intentioned I was in creating them.
Shawn Vernier
Quality Engineer
He/Him
The answer to quality is context.
Rosie Sherry
Create a bit of friction now to avoid it in the future. 📈
It will be interesting to hear stories of how code / software is reviewed in the age of AI, how can QA and the rest of the team sync and unite in a way that gives us that sense saftety.
Sign in
to comment
Create E2E tests visually. Get clear, readable YAML you can actually maintain.
Explore MoT
Tue, 17 Mar
Thunders Connect – Mar 17, Station F, Paris: QA & testing future, certification, product updates, panel, Station F tour & first-ever Thunders Awards. RSVP if in Paris!
Boost your career in software testing with the MoT Software Testing Essentials Certificate. Learn essential skills, from basic testing techniques to advanced risk analysis, crafted by industry experts.
Debrief the week in Quality via a community radio show hosted by Simon Tomes and members of the community
