Is Your Project Ready for Quality Checking? Don't Forget to Do These FIVE Things

Quality checking is one of those things we all say we love but secretly hate. We send our work over to another developer, believing they won’t find anything wrong with it, only to discover there are A LOT of things wrong with it.

You then go through the various stages of grief - denial, anger, bargaining, depression - before reaching the final stage, which is accepting that you are not the great genius you thought you were.

While I can’t take that emotional roller coaster completely out of quality checking, there are things you can do to make a better experience for both you (the developer) and the person who quality checks your work.

#1 - Provide the Quality Checker a List of Helpful Items

When you pass off your project to the quality checker, take the time to provide them a list of helpful hyperlinks and contextual information. Spending five minutes on this list will save the quality checker fifteen minutes having to find that information themselves. It also makes you look more organized and professional.

Typically, I include the following:

• A brief description of the project’s purpose and the stakeholder who requested it
• Hyperlinks to requirement documents and mockups
• A link to any code commits in github
• A description of any deviation from requirements and / or mockups

It usually looks something like the following:

Hey Joanne, this project is ready for quality checking.

Some things to note:

• The report's intent is to show where social media is under and over performing other channels for the brand selected
• Here are the hyperlinks to helpful documents:
  • Requirements document
  • Mockup
  • Schema design
  • Github check-in
• One thing that's different from the mockup is how we displayed the channel comparison YOY. The stakeholder thought the finished product looked confusing, so they asked to remove the YOY comparison

It's best to post this in the project management tool, so that anyone who troubleshoots the report later can find it.

#2 - Consolidate the Quality Checker's Feedback

Some quality checkers are organized and will provide a single comment with a list of errors they found in your reporting or code.

It’ll usually look something like below:

• Row duplication is occurring because of your JOIN on line 145 of your stored procedure
• Is your WHERE clause excluding the right event category?
• The KPI for Total Revenue doesn’t match the bar graph below, where you break Total Revenue out by store location

Sadly, not every quality checker does that.

Many will write long, incoherent strings of text that have some feedback in it or will write a series of comments in the project management tool as they find things that need to be corrected.

If one of those two scenarios happen, it's best to consolidate all items into a nice, concise list.

This accomplishes three things:

1. It makes it easier for you to understand what you’ll be fixing
2. The quality checker can refer to the list as to what still needs to be resolved
3. Someone maintaining this solution in the future can easily refer to the list for additional context

#3 - Respond to Each Line of Feedback to Make Sure You Addressed Everything

After the errors are consolidated into a single list, respond to each individual item to indicate whether you resolved it or had follow up questions. Use bold font or a color font to distinguish your response.

Here’s an example of what I mean:

• Row duplication is occurring because of your JOIN on line 145 of your store procedure Updated
  
• Is your WHERE clause excluding the right event category? I had to check with the stakeholder on this. They told me to exclude “check-ins”, but after reviewing the results, I’m not sure that makes sense. I’m gonna talk to them again about it.
• The KPI for Total Revenue doesn’t match the bar graph below, where you break Total Revenue out by store location. I’m not sure what you mean. I don’t have the same issue. Can you send me a screenshot?

This makes it easier for both you and the quality checker to see what items are unresolved and which still needs a response.

#4 - Assume the Best in Harsh Sounding Comments

This is something I’ve seen many talented developers struggle with – taking quality checking comments as a personal slight.

It's incredibly easy to read comments from the quality checker as something that's mean spirited. Usually the quality checker writing those comments would find it surprising that people feel that way. And that same quality checker may have felt that way about other people's comments. So this isn't just limited to one person.

My best advice: assume the best in people. Recognize that most people aren’t trying to diminish you or your work. They genuinely want to improve the quality – just like you.

#5 - Push Back on Requested Changes (That Don’t Make Sense)

Sometimes the person quality checking gets carried away and starts writing up a list of things to change that are not actually errors, but personal preferences.

Sometimes they want you to re-write your SQL because they prefer their coding style over yours, even though your code is already optimized for performance and the numbers are accurate.

Or they want you to relabel a KPI on your dashboard, even though the stakeholder asked for that naming convention specifically.

This doesn’t mean you should outright reject their suggestions. Instead, ask why they think they’re necessary. They might be thinking of something you’re not.

But if their feedback doesn't improve the stakeholder experience, improve accuracy, or improve future maintenance (i.e., making it easier for developers to troubleshoot), then it’s okay to push back.

Lastly, definitely don’t make changes that contradict the requirements without asking the stakeholder first.