I just got back from Targeting Quality 2022, a lovely conference put on by KWSQA in Cambridge, Ontario. This was a great opportunity for me, because the early bird ticket was affordable, and I can drive there! Yes, it takes eight hours, and across the border. I’m from the West, so that’s no distance at all to me. As a huge bonus, I got to carpool part of the way with Fiona Charles (source of the 10+1 Commandments for Ethical Techies in the featured image here, and I’ve shared some notes from her awesome keynote at the bottom of this post!)
I have many pages of sketch notes from the sessions I attended. I’m going to share the best ideas and “aha” moments for me. Unlike many of my friends, my drawings and notes are intelligible only to me, so I will use only words here!
Day one of the conference was workshops. I’m going to only share about Day two, the track sessions and keynote.
The day got off to a wonderful start with KWSQA President Tina Fletcher explaining “Truth and Reconciliation”. She explained that KWSQA’s office is on land that belonged to indigenous people. KWSQA supports afternoon activities for kids with The Healing of the Seven Generations. I never heard anything like this at another conference in North America, I hope more conferences will adopt this.
Socializing for Heuristics
My first “aha” moment was that Powerpoint does live captions! Hilary Weaver-Robb used them in her session on “Socializing for Heuristics: How social media made me a better tester (and human)”. (That blog post includes links to slides and resources that include her Diversifying Heuristics Cheatseet, check it out!) She gave many examples of heuristics that can lead to biases, stereotypes, and harm. I encourage you to go read her post, so I won’t repeat everything here.
What I liked most about this presentation was this advice: Stop and think if the software you and your team are delivering makes someone feel excluded or invalid, Ask yourself, “How would I feel if it were me? Would I feel excluded if I encountered any biases like these? Would this product make me feel included?” Hilary concluded with tips on how we can broaden our world view and advocate for inclusion.
The 8 Commendments
Mazin Inaad came all the way from the Netherlands to share his 8 “commendments” for maintainable test automation. He went over some common issues that get in the way of successful test automation. Then, he explained his “commendments” – recommendations, not commandments! – for avoiding those issues and creating maintainable, valuable automated tests.
Using my own terminology, one of these was something my own teams have found effective – write your test scenarios in a declarative, rather than imperative, manner. Another that for me may be the most important is to keep each test to one clear purpose – a pattern proposed by Markus Gärtner several years ago. When your scenario only tests one thing, and it fails, you know exactly what “broke”! No need to spend minutes or hours going through umpteen steps to diagnose a failure.
All of the commendments are excellent practices, and I’m hoping Mazin will make his slides available. My biggest takeaway was this: Only control relevant test data, by keeping it versioned with the associated test code. Generate the rest. Test data can be such a headache, and I prefer that each test set up and tear down its own. Generating the data that doesn’t relate to the test’s purpose lightens the load. For example, you have a test to make sure a partner code entered by the user is valid. The test values for partner code, valid and invalid, are stored in the repo, but other fields on the page, needed to submit it but not relevant to the partner code, can be hard-coded or generated.
From Fear to Risk
I’m a fan of identifying and prioritizing risks for a new feature, and using those to help focus your testing. I got some new insights from Jenna Charlton ‘s talk (also with live captions! Hooray!) on identifying and measuring risk. One observation that struck home – lack of safety prompts testers to do more testing than necessary. Jenna asked us, how does fear feel? It helps to quantify, define and scrutinize the risks. Another idea which is not something I’ve always done is to re-measure the risk over time. Jenna recommended associating stories to one or more risks, and re-evaluating them as stories get delivered.
Thinking like an improv actor
I got so many takeaways from Glenn Anderson‘s presentation on what we can learn from improv comedy ensembles. I’ve heard about “Yes, and”, and, I have not practiced it enough. It’s not just for brainstorming meetings or ensemble programming sessions! We can take this attitude of affirming and building on the ideas of others and not tearing anything down to pretty much everything in life. Glenn pointed out that open source projects are “Yes, and”, which I like a lot. Glenn noted that saying yes is an act of courage by a person who is affirming the ideas of others. A person who says “no” is trying to take control, (Note the context here. You’ll see in my notes about Fiona Charles’ keynote, saying “no” is important for things like supporting ethical practices).
We can only embrace “Yes, and” in an environment of trust and support. Glenn said we should bring a brick to the conversation – help build the thing up step by step – rather than a fully finished “cathedral” where we are already biased about what to build.
Teams vs ensembles
Glenn noted that the concept of “team” can be adversarial and competitive. In sports, teams have starters, people on the bench. He prefers to use “ensemble”, which is used in improve. Ensemble means that each part is considered only in relation to the whole. All the parts are taken together. What does this remind you of? For me, it explains a lot about why ensemble work (aka mob programming) is so effective. Glenn’s advice for helping your team become an ensemble:
- Be in the moment
- Give and take
- Surrender the need to be right
- “Yes, and” builds better ensembles
Skills that help us collaborate
Skills that help us include great listening – I’m always needing to work on listening to understand, not to respond! “Follow the follower” is another improv technique that works for for software ensembles too. One person starts doing something, everyone follows along, another person has a new idea and does something new, everyone follows along. That gets a flow going. Understanding the status of the team is also key. Keep identifying the biggest problem and asking everyone for ideas to solve it. I have so many more notes here, but I don’t want this post to be too long, ping me if you want to know more.
Glenn recommended some books to learn more:
- Yes, and by Kelly Leonard and Tom Norton
- Getting to Yes, And by Bob Kulhan
- Improv Wisdom by Patricia Ryan Madson
What could possibly go wrong?
Fiona Charles delivered a thought-provoking keynote with examples (many of these were pretty horrifying) of software gone wrong. KWSQA recorded this and I will update this page when the video is available on their YouTube channel. I took copious notes, and, I highly recommend watching the video when it’s available. I’m sharing just a brief summary here.
There are many examples of where crappy software ruins lives. We need to keep these possibilities in the forefront of our minds as we build and deliver software. We’re all victims of software that harms – by accident or intention. As Hilary Weaver-Robb had said in her session, there are many victims of bias. AI and machine learning are huge perpetrators of harm today, we have to stop thinking that those are sentient entities. Data is not knowledge. We need to remain aware that technology has limitations.
Software does a lot for us, and, we humans need to be able to take over from the software when needed. Tech brings us good things, like quickly developing Covid vaccines, but there is so much potential for gloom. Fiona quoted Jerry Weinberg – “It’s a people problem”. We must ground our technical practices on ethical processes.
Ask good questions continually! “What could possibly go wrong?” “Should we build this?” Call out fake science, debunk snake oil, and resist surveillance and privacy invasion. Fiona’s “10+1 Commandments for Ethical Techies” gives great guidance to get us started. I’ll list them here for anyone who can’t read the featured image:
- Understand your basic professional obligations.
- Know your specific legal and contractual obligations and those governing your software and project.
- Know your own ethical bottom line.
- Understand whose interests your work serves.
- Know the harms your software could do.
- Maintain critical awareness of your whole work situation.
- Be good at saying “no” (hmmm, this conflicts with what I said above about “yes, and”, context matters!)
- Be good at speaking truth to power.
- Know your escalation path.
- Know your own tolerance for personal and career risk.
- Document your concerns!
As always, the informal conversations at meals, breaks and social events provided gems of inspiration. Too many awesome people to list here. Do consider participating – and maybe presenting! – in 2023.
2 comments on “New-to-me ideas from Targeting Quality 2022!”
I’ve just finished reading about the UK’s Great Post Office Scandal, where a flawed EPoS system recorded massive cash shortfalls that didn’t exist, but because neither the contractor nor the client management team had any idea about the 10+1 Ethical Commandments, this was turned round to be the fault of the people operating the system, who were all branded as criminals, Some of them went to jail.
The trouble is that if you had challenged the engineers or the Post Office investigators and Board members, they would have put their hands on their hearts and said that yes, they were “good” and “moral” people.
Yes, Fiona explained the Post Office scandal, really horrifying. And I suppose those people might be good and moral, and, they needed to think about what could go wrong?