What should someone do to really assure quality (QA)?

I am going to be practical here. Not sarcastic. No mocking at the title “QA”. I want to share what does it really mean to assure quality. If it is possible. In what context is it possible.

From my experience of

  • having reported a ton of bugs and getting at least 10% of them fixed
  • building a company whose vision is to prevent bugs
  • helping people move from “finding” to “prevention”
  • observing tech and business leaders make decisions that affect quality
  • seeing how the culture of the org affects lives of people who build software
  • being a customer support by evening and tester during the day at some of the startups
  • building software tools
  • building products
  • playing the role of product owner
  • running a business that helps people building software
  • having tested 100 different products across industries

What are examples of poor quality in software?

  • anything inconsistent with user’s expectation of what the software should have done
  • an error that makes no sense
  • a feature that makes it more harder to solve a problem
  • loss of data or privacy
  • human effort to perform an operation on software, wasted by a crash or delete of data
  • complexity to use the software
  • interoperability issues
  • slow response times
  • timeout before users can respond to something
  • unmaintainable code
  • lack of testability
  • lack of logs to debug or RCA issue
  • crash, hang, reboot while on use
  • infringements and violation of code
  • reliability issues
  • scalability issues

Do humans intentionally produce poor quality software?

Hell No!

Why do humans produce poor quality software then?

  • lack of skills
  • poor architecture
  • slack on code comments
  • lack of time to question, analyze and understand design and architecture
  • lack of code reviews
  • lack of unit tests
  • lack of depth in defining critical components
  • lack of team work
  • time pressure
  • obligated to finish something in a way someone has asked
  • oblivious to what they are doing
  • peer pressure
  • aping what they did in their previous job
  • it works for now
  • plenty of things on their plate
  • they said yes to doing something they should have said no to
  • things are changing way too fast
  • inherited someone else’s code
  • integration issues
  • lack of budget to invest on right tools
  • no time to learn, practice and hone skills
  • lack of observation skills
  • too fast to jump to a conclusion of what should be the solution
  • …and more

Does people in role of assuring quality fix the above items?

Hell No!

What do people in the role of QA do then?

  • put in or follow the processess
  • setup frameworks, test bench, labs
  • setup environments to test
  • write scripts to perform consistency checks
  • build tests to run
    • API
    • Functional
    • Front End
  • perform scripted or exploratory testing
  • find bugs and report them
  • triage bugs
  • *feel* or *made to feel* accountable for quality
  • do RCA’s
  • In some cases
    • write backend tests
    • write DB queries
    • write scripts and logs to sift data
    • build tools for dev
    • interact with customers
  • give a green for shipping / release
  • In rare cases
    • build or ask for testability
    • build or ask for observability
    • look at production data
    • do customer support to understand pain points
  • attend grooming meetings
  • interface with BA / PO / Tech / Devops Lead
  • mostly all of the above within one team / one product line / one feature set / set of modules

How much of all the above cover to “assure quality”?

Anywhere between 5 – 10%. Why 5-10? As you read above, to assure quality, one needs to plug the holes that are beyond code. Plugging what is inside code is a hard job, I agree. It is also a very skilled job. No denial on that. However, what creates poor quality code is not code itself. There are a number of things that are outside of code that creates poor quality code.

Can people in QA fix, skills, culture, timelines, architecture, teamwork, budgets, ethics, values?

To be able to assure quality of software products – one has to serve across the organization. Not just within one team. Assuring quality is an org level job not a team level job or a module level job. How many of us in the job of assuring quality are org level? For every 1000 QA I have come across, 1 does a sincere attempt to fix quality at org level. If supported well, the org benefits, otherwise downstream nothing can be achieved.

What should people really do to be able to work org level to influence quality?

Note that, I did move from the word “Assure” to “Influence”. Why? Quality is not one person’s job. It is a group of people who build quality and software. As a CEO, I can make any decision and expect people to follow it but I can’t assure that people know how to follow it or people will understand the vision and do it. I can only influence them to align towards a vision. By making it their vision. Like that, a Quality Influencer has to be able to bring people together to help them see why they need to build higher quality software. This may require to influence the CTO.

2 years ago, a super funded startup CTO office knocked my door for consulting. When I studied their problem statement – they made everything right to build high quality software but their regression issues were flying high. When investigated further, we understood that they had grown rapidly and 60% of their staff were new and they onboarded them very fast to start writing code in 2 weeks. 60% of them new in the system changed the culture of the way code is written and thrown out. Rapid growth without proper training, onboarding and culture coaching failed this startup code quality. This affected their scalability. They wanted to bring in someone who can coach people, bring the vision back because internally they couldn’t achieve this.

I wish to help more people become org level influencers of quality. Based on the posts I have seen from Abhijeet Vaikar he is doing that for Carousell. This is also what Pooja Shah did for MoEngage. As passionate hardcore engineers, their influence and inclination is tech and product. Less of business. (Unless they correct me). That brings us to the following point.

What should people who want to influence at org level do?

  • after the first 6-8 years of being an engineer, writing code and or being a hardcore tester
  • become a generalist (this is scary to many engineers)
  • spend time across functions
  • spend time experimenting with new roles
  • not be obsessed to always learning what is in trend
  • connect with all people in org
  • ask them questions (fundamental ones)
  • focus questions on preventing bugs and poor quality
  • run a side hustle (or better terms – business)
  • follow a diverse set of people
  • attend a diverse set of conferences
  • cofffee / party / work with Business, Tech, UX, Support, Ops and Finance
  • go wide (and deep when needed)
  • chuck the notion that jack of all trades and master of none isn’t bad
  • talk to C level folks
  • pick up a business role at least once
  • fail and recover
  • face a loss with trading
  • spend time talking and observing customers using the product
  • write
  • visualize
  • draw
  • consult
  • freelance
  • build tools
  • study a variety of subjects
  • study human behavior
  • build training plans and train people
  • study org charts of orgs that build high quality software
  • understand the pain across different functions and make decisions to ease them out
  • study tech
  • follow people for business, product and tech insights
  • have the power and mandate to make decisions that affect the org

Real life Quality Influencers

Anne-Marie Charret

She has been a tester. She has been a consultant. She has trained many leaders. She runs a business. She writes. She does marketing, sales, hiring, delivery, testing and ops too as needed. This gives her the ability to connect to people with different roles and functions. If one needs a Quality Influencer for an org, she fits in really well.

Rahul Verma

Rahul has been a developer. He consults, coaches, builds frameworks, runs a business. I know of organizations who consult him to influence change to their engineering strategies. He is an expert at code design and interfaces with devs and testers equally well. While his inclination is tech and frameworks, since he has consulted and runs a business, interfaces with other roles well.

Anand Bagmar

I hired Anand in Moolya to help us deliver a complex project. Complexity was not just because of tech but also the context of customer. Anand navigated their department by department, got people together and then got our team to write simple scripts that run. While he is a specialist – without having learnt other functions, it is impossible he would have been able to do what he did. Equally, he blogs and speaks at conferences. He organizes events and meetups too.

Do you see the common thread across all these people? They are both deep and wide.

Semi Final Thoughts

  • Assuring Quality is not QA role.
  • QA role at best is a Tester role.
  • The title QA has been stuck because it is shorter and easier than saying Tester.
  • Shift left is a fancy statement in most orgs.
  • To really shift left – one has to shake the “up” that is contributing to poor culture or systems.
  • Baking or fixing quality is an upstream job.
  • Fixing quality downstream is a heroic never ending unrewarding journey.
  • We need people to influence quality org wide.
  • Some people call the Quality Influencer role as Quality Coach.
  • “Quality is value to some person who matters” — Jerry Weinberg
  • Alignment of values and practices make quality happen.
  • People need to know that quality is as important as hitting the deadline.
  • Orgs who scale fast must put in readiness in place to retain culture of engineering.
  • Training systems are as important as the goals.
  • People should look beyond “what is trending in the market”.
  • Focus should be on preventing bugs.
  • Leadership coaching on quality is essential.
  • Quality isn’t going to be a constant for any org.
  • As a heuristic; fix culture, structure, systems and processes before fixing code.
You May Also Like