Quality assurance has had a slightly murky history. It’s a part of the production process that is often poorly defined, and has sometimes been seen as little more than a necessary but annoying hurdle to be rushed through before a course is released into the wild. At Kineo, we have always resisted this way of thinking and have embedded quality assurance throughout every stage of what we do. The last ten years of elearning and LMS production have taught us that if you want people to keep coming back, ensuring quality isn’t just an obligation to fulfil: it should be an integral and essential part of everything you do – at every stage of production.
What does a QA tester actually do?
If you produce learning in-house or partner up with a learning provider, you’re probably doing some degree of quality assurance. But it’s a common misconception that QA can just mean a quick proofread of a course to ensure there aren’t any spelling mistakes in the text. Our testers carry out a wide range of tasks: everything from proofing copy and ensuring it conforms to a client’s style guide to testing upgrades and LMS customisations.
How to ensure the quality of your learning
Kineo has put a real emphasis on quality assurance, having evolved into a global team of testers over the years. But why did we do it? Because quality assurance can flip around what would otherwise have been a complete flop. Let’s take a simple 30 minute compliance course as an example to highlight where and how quality assurance comes into play.
- Before we start any project, we get the full picture of our clients’ expectations from the onset. This covers everything from style and branding to functionality requirements and industry-specific jargon. By ingraining this process in the earliest stages, we’re able to ensure that it's not just the QA tester ensuring quality, but also our designers, graphics and development team.
- Once your compliance course has been built, all the graphics and content have been added - what should happen next? Before a QA tester gets formally involved, the designer should review the course one last time. Having worked so closely on the project, they are usually best placed to assess whether the look and feel of the course matches the client’s or their colleague’s expectations. Is the branding right? Are the images appropriate? Once they are happy, the QA tester can take over.
- There are several quite different aspects to how to test the course. Yes, they should be proofreading the content - but this is always just more than spotting typos. Are there client-specific terms in the course? Job titles, department titles, perhaps product or service names - have these been written correctly? Have these been written consistently? Who is the audience for this course? Are they likely to be non-native English speakers? Is the language suitably clear and accessible to such an audience? Obvious text errors in the finished product can be a clear indication that your production process isn’t working as it should be.
- Once the course has been proofread, thought needs to be given to more technical considerations. What will the audience for this course be using to access the learning? Establishing an agreed ‘tech spec’ of what will be supported is crucial and has big implications for how long quality assurance tasks are likely to take. If your client or colleague knows that their workforce will only be viewing the course via desktop PCs running Internet Explorer 11, that means just one platform to test to ensure every aspect of the course functions as expected. But what if that workforce are being encouraged to access the course via their own devices or home PCs? Suddenly your QA tester’s workload is increased exponentially, as they must test using Chrome, Firefox, Safari - and on an iPhone, iPad, Android phone, Android tablet etc. This can be a significant piece of work! It’s also important to note that shrinking down your desktop browser window to the size of a smartphone screen is no substitute for testing on the actual device. Your QA tester’s first question when given a course to test should always be: ‘Which platforms does this need to work on?’
- Once a course has been proofed and tested, the diligent QA tester’s job is still far from over. Where will the course be launched from? Are you launching an LMS alongside the course? Is there already an LMS in place? In either scenario, your tester needs to ensure it’s tested in situ. There can be nothing more frustrating for a client or colleague than to have signed off a course they are happy with and have worked hard on, only to find that as soon as they put it into the live environment it completely fails. Testing how the course behaves in an LMS, and crucially, how it behaves in the client’s specific environment is absolutely essential. Does the course retain the user’s progress if they exit and re-enter? Is there an assessment? Does the LMS correctly record both a user’s failing and passing scores?
If your test team is being deployed effectively, they will always be busy! On any given day your tester could be proofreading the first version of a course, ensuring client amends have been correctly implemented in a second version and checking issues related to a specific browser have been fixed in a third. The key to this workload running smoothly is communication. Your testers will be talking to everyone from designers to developers to ensure quality is second nature, something that everyone naturally embraces. Quality assurance shouldn’t be a tick-box to check off at the end of a project, but a mindset that your production team lives and breathes – and your test team will be there to reinforce that every step of the way.