Best practices for QA

This is for:

Developer

Intro

To ship professional code and mitigate risks to business operations, Qubit recommends a rigorous and comprehensive Quality Assurance (QA) process is included in your development cycle.

This article contains details of our recommended approach to QA and includes:

  • The areas to focus on when performing QA

  • How much time resource to invest in QA

  • Providing feedback

Focusing on core areas

Code reviews are often subjective. To deliver real value to the QA process, in our experience, it is useful to focus on some core areas that can have the highest impact on the final results.

Consider the following, in order of priority:

  1. Is any there any user data embedded in the code or any assets pulled in from other sources? Could personal data be exposed?

  2. Is there any logic in the code that could cause the site to malfunction?

  3. Will the code cause any unanticipated performance issues on the site? For example, will processing a large amount of data or pulling down large assets that aren’t on our CDN cause the site to lock up?

  4. Is there anything in the code that could cause a conflict with any on-site scripts or libraries?

  5. Will a segment and trigger correctly, only firing when a change occurs, based on the logic defined? Could it cause a bad split?

  6. If any Qubit APIs are utilized, is there proper caching of the response to reduce load on our servers, and is there a failsafe in place in case the data is not received as expected?

  7. Is there anything in the code that exposes any proprietary technology or systems?

  8. Will the code function on targeted devices?

  9. Are there any areas of the code that are not cross-browser compatible?

  10. Is the code written in an efficient manner in order to minimise execution time?

You can read more about these in greater detail in Performing a Code Review.

Dedicating resources

There is no set time you must spend looking at a task, neither is there a specific cap. If a piece of code is complex and difficult to review, we must flex to that.

However, we want to be sure that our QA remains focused on the core areas above. For this reason, we recommend using the following guidelines using the number of lines as indicator of the amount of time to invest:

  • 100 lines or less: 5 - 20 minutes

  • 250 lines or less: 15 - 30 minutes

  • 500 lines or less: 25 - 40 minutes

  • More than 500 lines: 40 - 60 minutes

Providing QA feedback

When providing feedback:

  • Try to keep your feedback clear and concise

  • Use markdown to make your items more actionable - [ ] do x, y, and z

  • For developmental points, don’t provide the answer, push down the right track