Nobody with any experience in the digital space will argue against the importance of a strong QA process. We’ve all seen the results of skipping digital analytics QA or executing it very loosely. Yet it’s something that happens all too frequently. Why is that? The reasons it gets overlooked are often quite common. Fortunately, when you recognize them, it gets easy to put QA back on track.
1. Limited Resources
It is never fun when you are a man down or when resources are just not being approved, even though business analytics needs are on a never ending upward trend. Rather than overextending yourself to the point of a loss in quality, you may need to turn down project or extend deadlines. Rather than set yourself up for failure, you can help projects succeed by focusing on key points.
- Allot more time for completing the project and include plenty of QA time. Include the time you will need to resolve any bugs uncovered by QA.
- Create thorough documentation, especially with QA in mind. The documentation should include space for recording bugs found as well as resolutions provided.
- Ask for more time if needed. As this comes up more frequently, your need for more resources may be more likely to be approved.
- Enlist the help of developers.
2. Limited Time
It is very common, almost too common, that implementations only have a week or even days to be completed. This doesn’t leave much room for QA.
Sometimes this is just due to lack of understanding on the part of the development team. Another common reason is that the program manager wants to be able to tell a story about the success of the project afterwards and will ask for certain data to be collected. It may take some time for the team to figure out who to go to for the required analytics prowess (you!). There are two things you absolutely must do in this situation:
- Share with the team how much time you will need next time to ensure a thorough and accurate implementation.
- Make sure that they understand that there may be inescapable limits to what can be done within the time frame. Do not promise to deliver data when you will not have time to implement necessary tracking.
When you are in this position, there are some things that you can do to still make things go as smoothly as possible:
- Be sure to document what is being tagged very thoroughly. Create a document designed specifically for guiding QA and recording findings and resolutions.
- Try to enlist help from the developers on the project to help with QA. Usually, a 15-30-minute session is sufficient to train developers on analytics QA. They have the perfect skill set and can recommend resolutions as they find bugs. Another benefit is that they will become analytics subject matter experts within the organization and will look for opportunities to include you.
- Another action you can take is to simply request more time. You may not want to be the reason a project is delayed, but you also don’t want to be the reason it fails, either. Being brought in at the last minute is a perfectly valid reason for needing more time.
3. Laziness
This is not an easy topic to address, but it is a very concerning one. It could be simply rephrased as, “Do you like to eat and have a place to live?” There is so much opportunity in this thriving digital analytics space. If you do a decent job and make sure your implementations work, your pockets will be full.
This is also an indicator of a larger concern. Someone that does not care about the quality of their work and their craftsmanship may be telling you about what they think about you. They may be realizing that their values are not the same as yours. And it may be time for them to move on.
4. No QA Process
You may not have even considered this. Adopting a QA process can make your QA efforts more efficient by 50 percent (according to a study yet to be conducted). On a serious note though, introducing process is almost always a win. If you don’t have a QA process, there may be bugs that you are missing. Here are some things to include in your QA process:
- A timeline. Set a start and end date for when QA is to be conducted and completed. Be sure to include time for bug resolution and retesting.
- Documentation of new tags in a QA-friendly format. I prefer a spreadsheet. I have one tab containing pages/actions tagged along with what data is to be passed. I can then color cells red/yellow/green during the QA process. Red for a bug, yellow for an item needing clarification and green for an item that has passed QA. The second tab should contain the QA findings for the red/yellow items, e.g. the page/action containing the issue, affected events/variables, what was expected vs. what was found, a ticket number if a system like JIRA is being used, a description of the issue and how to reproduce it and a status column.
- A guide for how QA is conducted and what will or will not be tested.
5. Too Much To QA
This can definitely happen and should not be made light of. Here are some ideas to navigate testing a large implementation:
- Revisit your QA expectations and reduce the scope of QA, e.g. don’t QA for three browsers and two operating systems.
- Divide and conquer. Get everyone involved possible and divvy up QA tasks among them. This is where process is very important to ensure that everyone is following the same approach.
- Use an automated tool like ObservePoint to speed up your basic tag testing. Creating web journeys will help with regression testing for future releases.
When you are aware of the reasons that QA is being inadequately applied or avoided altogether, it’s much easier to find a way to repair the process. QA is too essential to ignore, but repairing an impaired system is a relatively simple solution.