QA & You: The Testing Handoff

Author's Note: This is part 3 in an ongoing series on the importance of Quality Assurance/Quality Control (QA/QC) on your website. I still haven't decided how many posts will be included in this series, but feel free to check out part 1 and part 2 if you'd like to follow along.

I'M NOT IN QC, SO how does this apply to me?

Quality Control is a task for more than just a QA/QC engineer. The concept of quality control testing exists at all levels for everyone involved in a design project. Whether you are a developer writing code, a project manager responsible for presenting the finished product to a client, a client receiving the product, or a content editor adding new material to the site, the quality of the solution you are using should be of utmost importance to you.

While this post may seem to focus on the development side of QC, there are parts that apply to user acceptance testing (UAT) of a website or web application as well. I will try to highlight both.

What is a "Handoff"?

While one of the most common definitions of "handoff," per a quick Google search, refers to the transfer of a live cellular call or data session from one device to another, the sports-related definition that also shows in the search results is actually much more accurate as it relates to this post...

The difference being that, in this case, the "ball" is either an element of the website or the site as a whole. The "teammate" reference stands. We are all a single team working together to benefit our clients and end users.

What's the Purpose of a Handoff?

Everyone involved in testing should insist upon an official handoff meeting or call prior to the start of testing. The reason for this is simple... not all QA/QC team members are included in every single development meeting or planning session. Additionally, client-side team members may have moved on to other projects while their agency was developing the site and could use a refresher on what's going on.

Whatever the situation, it's important to insist upon a handoff to ensure all team members are on the same page prior to moving on to the QA/QC or user acceptance testing stages of the development process. 

How do I Prepare for a HandOff?

Believe it or not, it is very important that all parties to the handoff prepare for this meeting. It's not really as simple as just saying, "Here you go! Have at it!"

Developers and Project Managers

It is important to compile all information about this stage of the project and make sure that it is readily available. QA/QC might have initial information about the project or specs as they were originally conceived, but it is important to document any changes that occurred during the development process. Did something not work as expected during prototyping? Did the client make a change to their original request? How did these unexpected changes affect development? Be as granular as possible. You never know how even a tiny detail can cascade into a larger issue.

QA/QC Engineers

Prepare for the handoff by doing some research. Ask the project manager for the scope of work (SOW) ahead of time and preview it. Also, request the URL of the element/page/site being tested. Don't wait until the handoff. If this is an upgrade to an existing feature, review the original version and see how it compares. If there are hi-fis or prototypes available, check them out and see how they work. This may sound like you are doing your own handoff, but, really, it's simple due diligence. 

Most importantly, develop a list of questions based on this preview. If you can walk into the handoff with a page of intelligent and practical questions, it will prove to be a successful exchange because you will then have the answers you need and you hopefully will not have to bother developers (as much) later with questions you never thought to ask. Sure, a handoff won't necessarily cover all issues that arise, but if you can take care of even a handful of potential problems ahead of time, that's a win for everyone involved.

Client-Side UAT Teams

UAT teams should do a lot of the same thing that QA/QC Engineers are recommended to do above. Refresh your memory regarding the specifications that your team laid out to your design agency. Review your existing site or application and see how it works versus how you expect the revised version to work. Write questions! Lots of questions! No question is silly or odd. Honestly, if it helps you better understand the product for which you are paying hard-earned money, it's worth asking.

The Diagram Side of Things

Here at Diagram, we conduct handoff meetings both at the internal QA/QC stage and the external user acceptance testing stage. We also provide extensive training and site-specific documentation on how to maintain your website.

As a member of Diagram's QA Team, I prepare rather extensively for all of the above. Whether it's research to discover how a developed element works so I can properly test it or developing training or documentation for the client and summarily conducting training sessions, I am part of it all. And I love it.

Do you currently have handoffs prior to QA/QC and user acceptance testing? What do you do during these meetings that you find uniquely helpful? Let me know!