Slow Ideas and Starting SQA

Introduction

Sometimes I find inspiration in unexpected places. Recently I was reading a fascinating article, Slow Ideas, about the growth and spread of beneficial practices in healthcare. This topic may seem like an odd way to start a post about software QA but reading it galvanized something inside of me that’s been coming together for several months. You really should read it yourself when you have a moment, but I’ll do my best to summarize the key points as I write.

Summarizing the Article

Sometimes introducing a new practice is easy

The first section of Slow Ideas is a story of the introduction and reception of anesthesia to the medical profession. Before anesthesia, surgery and other medical practices were brutal, painful sessions. As a result, doctors were often working at unsafe, fast speeds to complete the operation and end the ordeal. While this may have been a pragmatic decision for the time, it understandably reduced the success rate and increased complications with the procedures.

Enter anesthesia. Suddenly a patient could be zonked out for the entire thing. No more screaming. No more thrashing. Far less rush and forced urgency for the doctor. The situation had been improved for everyone, but most importantly for adoption, it improved the condition of the person performing the work. It made their job easier, less stressful, and more likely to result in positive outcomes.

Sometimes introducing a new practice is HARD

The second anecdote deals with the introduction of antiseptic practices like cleaning tools, clothing, and the surgeons’ hands. In the 1860s when it was coming onto the scene, Joseph Lister published a study of post-operation outcomes resulting in sepsis and death. The numbers almost immediately proved out the benefit of antiseptic practices, but for some reason, it didn’t catch on quickly.

The problem is that antisepsis was a harder idea to communicate the importance and more critically for adoption, it didn’t make the doctor’s work easier or more enjoyable. For full benefit of antisepsis, a lot of current practices had to be discarded. Not only were doctors expected to clean their tools, they now needed to wash their hands, disinfect their uniforms and even work in showers of carbolic acid (which was reported to burn and cause discomfort at even low concentrations). The benefit of all of this could be logically and scientifically understood, but it was nowhere near as obvious and immediate as the issue of pain. If sepsis happened it would be later and who could even say what caused it.

Introducing slow ideas

The remaining stories are about introducing best practices to areas of the world with less modern methods and fewer resources than you’d generally find in the United States. Volunteers and visiting doctors struggle with getting the people they’re trying to help to understand and follow procedures that may appear difficult or counterintuitive to them but which had already been proven effective elsewhere. I’m not going to summarize their entire experience, but I would encourage you once again to read it for yourself.

So what does that have to do with starting up QA?

I’ve been the first QA at two small companies. Neither had much in the way of testing process or tools when I arrived. Developers would sort of glance at each other’s work and say “good enough” because that was how it had always been. QA practices, much like antisepsis were things many of them understood academically, but in practice, it was just adding discomfort and more effort to their work. These were educational opportunities that I interpreted as puzzles for me to wrestle with myself. I did them a disservice with my initial areas of focus.

Maybe I felt this way because I’ve usually been hired because I’m a highly technical software tester relative to many of my peers. With this territory, I have a certain inclination to dive into the problem in the same way I believe a developer or engineer would approach it. I learn the system, I use my fancy tools and knowledge to do things others don’t understand, and I personally sling code to get new projects going. These may all be important things but it has consistently left me overextended, and the team is slower to adopt and understand best practices themselves. So what would I do differently?

Form relationships

People is what I should have been focusing on first every single time. You need your coworkers to be willing participants at worst and fellow advocates at best. Nothing makes things happen like a chorus singing that it’s the right things to do. Nothing kills momentum like anxiety, misunderstanding, and distrust. You should invest in the technical projects by earning trust, making friends, and talking nonstop about anything and everything QA.

• Learn everyone’s name, their role, and what makes them tick.
• Talk to people about what they do. Ask questions and show genuine interest.
• Never treat QA like a chore or drudge work. Opinions like this can be contagious for better or worse.
• Progress is exciting. Show it and celebrate victories with the team.

Make important problems visible

Many software development problems don’t get resolved because people suffer through them quietly. This inertia is often despite the issue being common, causing them pain, and being readily and permanently fixable with some small amount of effort. The problem is the right people don’t experience the pain themselves and it never gets communicated in ways they can understand. Make these problems visible for everyone!

• Make problems visible. Create a dashboard, make a chart, keep a tally on the dry erase board when it happens. Do whatever works for the team.
• Think about how you can make these accessible and understandable to people who aren’t experiencing the problem themselves.
• Keep bringing them up until they become a priority.

Get down in the mud and help

Don’t silo yourself or QA. Get down in the dirt with your team and understand what they’re going through. Get behind the cart and push while they pull. When you suggest a new practice, you should do it with the team or try it yourself first. If they complain about doing something you should do it too until you understand their concerns. Acknowledge the squeaky wheels and encourage them to keep telling you what’s wrong. These people are your counterparts and allies, and it’s critical you develop trust and empathy between you.

• Never discourage feedback. Do gently nudge people to make their input more thoughtful and effective.
• Shadow what your peers do. Help them do the work and even try it yourself. Don’t just listen, participate.
• If they’re in crunch time and you aren’t, try to lighten the load in nondisruptive ways. Bring them coffee or lunch when they can’t leave. People remember these things.

Get people involved in the work

Real quality is only achievable as a team goal. To mature the team, you must include them in your work as well as showing interest in theirs. Testing is something that anyone with an opinion about software can and should occasionally do. Using the system more helps everyone improve their understanding of the scope of changes, areas of concern, and currently available functionality. All of this is going to make planning easier and implementation better and lower risk.

• Reinforce and repeat QUALITY IS A TEAM PRIORITY. It’s not just for QA. It’s for everyone.
• Cycle participants into accessible events. Include them occasionally in UAT or release testing.
• Celebrate their work and growth. Compliment the awesome bugs they find. Make testing fun.
• Ask for help when you’re underwater. Make your trust in their work real and tangible. Provide support when asked.
• Find some disciples. Some people already believe, and some can become believers. These are your allies to spread quality habits to other groups.

Create space to do the right thing

Great, so now your coworkers love you, and you’ve developed a mutual understanding of how things are going. Maybe they’ve learned a little about testing along the way. Your job is done, right? Wrong. There will always be someone out there with priorities that aren’t aligned with what the team believes is right. Don’t let them railroad you. You’re one of the primary stakeholders in the software development process, and if you’re focused on improving quality, it’s all about carving out time for investment.

• Understand where distractions are coming from and why. You can’t fight every battle, but you need to understand which ones matter.
• Get people comfortable with the idea of slowing down in individual situations to realize acceleration overall.
• Don’t be a jerk. Don’t condescend. Do stand your ground.

Closing

Thanks for reading. I’d love to hear from you about your own experiences going from zero to “some” QA.

Finally, if the individuals in Slow Ideas made an impact on you too, please consider a donation to an excellent organization working to raise the standard for everyone like Doctors Without Borders.