How to implement a bullet-proof QA process

Posted by Ariel Kidwell on 1 June, 2019

Bullet-proof quality assurance process

The development phase of your website or web-based application is complete and you’re ready for launch. However, before going live you need to engage in a thorough quality assurance (QA) process. This should be one of the most fun steps in the launch phase, allowing you to see the almost finished product and ensure it’s ready for liftoff

However, poor planning, or a lack of clarity around your team’s expectations, can lead to delays and budget overages. Entering a project’s kickoff meeting with a detailed timeline and clear communication strategies can solve most — if not all — future issues. Adding a tested QA process will both bolster alignment within your team, and ensure a seamless, painless launch. The following tips will provide you the knowledge to craft a QA process that ensures the successful launch of future web projects.

1. Understand what QA is and isn’t.

QA is your opportunity to compare the nearly-finished product to the original goals, design, and functionality, ensuring no details have been overlooked. The two key terms in this phase are functionalities and requirements, which will guide your QA testing as you search for bugs (aka issues, breaks, dead ends). You will test forms, links, slideshows, third-party integrations and videos to ensure they’re working as expected. If your website has a content management system (CMS) you will explore the CMS to make sure all requested requirements and options are available. It’s also recommended to create test entries in the CMS to ensure everything is functioning as expected.

During the QA phase, it’s possible your team could decide on new design elements, functionalities or requirements. This is completely natural now that you’re interacting with the final product. However, this is not the time to make these changes if you have a fixed budget and/​or timeline. These potential changes should be recorded during QA and addressed after launch as a follow-up project. Trying to shoehorn changes like this during QA creates unnecessary pressure on your development team and will inevitably create delays. Allowing the product to launch will also provide users the opportunity to provide feedback. Something you assumed would be helpful in QA might not be important once others interact with the product.

2. Pay attention to timeline expectations.

When creating the QA timeline you must be an active partner in setting turnaround expectations within your team. Check your team’s calendars against the timeline for holidays, vacations or busy work periods to make sure a deliverable date is possible, or a turnaround expectation is reasonable. Once the timeline is agreed upon, ensure these dates are placed on your team’s calendars well in advance so everyone can appropriately allot their time during QA periods.

3. Align your team before the QA phase.

QA is a team effort involving all stakeholders that have provided input or need final sign-off before launch. QA can be a tiered approach, assigning certain team members to dig through the product’s functionalities and testing, while others simply click around and review from a macro level. Make sure to designate who will be participating in QA, define their level of involvement and align their schedule with the project’s timeline well in advance of the QA phase.

4. Create clear documentation of bugs during QA.

Before beginning QA decide on a tool that will allow your team to easily record any found bugs throughout the process. This could be in the form of a third-party tool such as Bugherd or DebugMe, that automatically records your browser information, screenshots, and comments. Another option is a simple, internal spreadsheet where your team records bugs and phase-two recommendations.

Regardless of the tool, the key is ensuring your development team is provided a concise list of bugs they can address through collaborative, consistent feedback. Including details such as specific browser information (whatsmy​brows​er​.org), device details (phone, tablet, computer size/​type), and screenshots will create a clear picture of each issue and minimize the questions your development team may have. Before passing the information to the development team review the list and remove any redundancies, and make sure all listed issues are easy to decipher.

5. Use your rounds wisely.

Your QA process should include a fixed number of rounds for reviews and revisions. Utilize each round efficiently to ensure you stay on schedule and hit your ultimate launch deadline. The first round should be the most thorough review of the site, leaving no page unclicked and no form untested. Devote the majority of your team’s energy and time to this round. The next round(s) should be used to ensure prior bugs no longer exist and making a final pass at the entire product before approving its launch. Pushing extensive testing to later rounds places undue stress on your team and increases the chance of delays.

QA Checklist

Immediate

  • Develop a QA process for your team
  • Select QA collection tool

Project Kick-Off

  • Set the project’s QA timeline 
  • Designate team members that will be involved with the project’s QA based on availability, define their level of involvement and add dates to calendars

Pre-Launch

  • Make sure each team member is following their QA assignments as they begin testing all links, forms, third-party integrations, videos, CMS, etc.
  • Ensure all QA bugs are recorded in your collection tool
  • Ensure all phase-two recommendations are recorded in your collection tool
  • Review QA list after round one is completed to remove any redundancies, and ensure all necessary details are recorded for the development team
  • Begin final QA round(s) to test prior bugs before launch

Post-Launch

  • Gather stakeholder feedback
  • Plan and estimate phase two recommendations that were discovered during QA.