Quality Assurance

Quality Assurance (QA) is still seen somewhat as a dark art, or even worse an optional extra so this is an opportunity to dispel a few myths, and explain why QA should be an integral part of a project lifecycle.

Firstly, it’s important to remove a major misconception surrounding Quality Assurance. QA is NOT simply the testing phase at the end of a project just prior to release. Quality Assurance is a proactive series of tasks at various stages of the project lifecycle to ensure that the final product is of an acceptable quality, from defining the process for delivery, mitigating the project risk, through to the actual testing process. QA is also reviewing past projects, learning from mistakes and improving the overall project process.

The aim behind QA is to ensure that as a project moves through its various stages, it meets the quality targets set out, and any potential issues are addressed as early as possible. Failure to resolve issues early in a project can risk leaving them until they become far more expensive and difficult to deal with than they should have been – it’s easier, quicker and cheaper to resolve an issue in a website’s design when it’s on paper, rather than when the website has been built.
QA should be part of a systematic, repeatable process that ensures consistency of results across projects. QA should not just be the preserve of a QA department – every member of a project team should be involved in the QA process, from reviewing designs, wireframes and code, to checking the final product.

What is meant by “Quality”?

Quality is an extremely subjective term, so what might be considered an important quality characteristic for one industry, will be of less importance in another industry. For example, an acceptable number of defects for a small budget, marketing campaign micro-site will be drastically different to the acceptable number of defects for an air traffic control software system.

When talking from a digital agency perspective, the typical quality characteristics are:

• Minimal defects – Zero Critical and Major defects, as few Medium defects as possible, and an acceptable level of Minor/Trivial defects. The acceptable levels of Medium/Minor/Trivial should already have been defined in project planning documentation at the start of a project.

• User Experience – a positive user experience, which encourages repeat visits rather than scaring users away.

• Brand – a delivery which doesn’t have a negative impact on the client’s brand – for example a website which leaves the client open to litigation would be completely unacceptable!

• Timely Delivery – An on-time and on-budget delivery.

• Advert for the Agency – Something that other potential clients will see and that will encourage them to bring their business to the Agency.

Why Assure Quality?
In the current economic climate, overall advertising expenditure is down but digital, mobile and social spending is increasing as a percentage of advertising budgets. Companies are looking to achieve maximum return from their advertising spending and so often have to decide between a 30 second commercial which will be played a finite number of times against a long term, always available digital platform, or web presence. At the same time as this, a number of traditional “Above The Line” agencies are starting to provide digital services and a number of smaller, start up agencies are also entering the market. This increased competition means that agencies need to continually strive to ensure end-user and client satisfaction – failure to do so can and will see the agency replaced quickly.
Coupled with this is the fact that the complexity and number of delivery mechanisms to the end user are increasing – where once a website was the standard delivery mechanism, there’s now also email, social media, mobile applications, YouTube, etc. A mature QA process is important in ensuring that all of these different deliveries are of an acceptable quality.
Challenges
Successful implementation of a Quality Assurance process (as opposed to purely a testing process) is not easy! There are a number of challenges that will almost certainly have to be faced:

• Perception – As touched on earlier, the classic industry perception of QA is as an end of project task. This is Quality Control not Quality Assurance. If the QA process only begins after development has finished, the process is already broken and the QA activity is going to be stressful and include numerous late nights.

• Time Allocation – As above, when the QA department doesn’t get involved in a project until the final couple of weeks, by this time Creative and Development can and may have overrun. In these situations QA find their testing time compromised, there are generally more defects to be found as potential issues with wireframes & creative have not been addressed already, and new testing requirements tend to be discovered in the project brief. It’s important to resource Quality Assurance tasks as early in the project as possible.

• New Process Resistance – There’s always going to be some resistance to any new process from people if the purpose behind the process is not understood. Once Project/Account Managers realise that QA can prevent irate phone calls from clients or the Creative department realise that QA can help see through their creative vision for a project, this resistance should lessen.

• Project Documentation – If wireframes, copy decks, project briefs, visual designs etc are not under version control, potential issues can be caused by people working on different versions of a document. For instance, whilst the latest Wireframe version could be 3.5, the QA team may be testing using version 2.1, which is wildly different, leading to spurious bugs being logged against the system under test! The easiest way around this is to introduce a documentation management tool like Basecamp into your process.

• QA as a collaborative activity – In the same way that Technology and Creative teams should work in partnership to ensure better solutions for the client, so should the Technology, Creative and QA teams collaborate. The key is that everyone involved in a project should be responsible for Quality. It shouldn’t be left to one person to sit there with a few computers testing – everyone has their part to play ensuring that the solution delivered is as good as it can be. IA/Design need to be involved in making sure that they’re happy with the final solution as well as Tech and QA.

• Convincing everyone to use the bug tracker – Part of a collaborative process is ensuring that everyone is up to speed with the bug-tracking tool, and takes responsibility for logging their own defects. QA can and should give training and support on how to use the tool, but shouldn’t log everyone else’s defects otherwise they have no time to do their own job.

Finally, I don’t want to give away all the secrets but if you can achieve the following then you are heading towards a Quality Assurance process, which should help you meet your own quality goals

• Quality Assurance personnel involved from the early stages of a project, e.g. Project Briefing.

• Quality Assurance personnel given adequate time to effectively plan the necessary QA activities to meet that project’s quality goals.

• Suitable tools available – a defect tracking system, code version control system, automated testing tools, testing environments.

• All members of a project team involved in Quality Assurance
• All project documentation under version control.

About the Author:
Name: Neil Duggan
Bio:
Neil is the Head of QA at Dare. He has previously
worked on high profile projects for clients such as Nike, Nokia,
Starbucks, and Adidas.
Location: London, UK
Company: Head of QA @ Dare