If you are working with SMILE on a project which is nearing the end of its delivery phase, you may have heard us talk about ‘testing’ or ‘QA’. This article outlines what we mean by testing, what happens during the testing phase and how you can help.
What are you testing for?
Testing is a crucial phase in the delivery of any project. Typically, it takes place after development and before pre-flight and launch. It is the window where the new site has been deployed onto a development environment in order that it can be put through its paces.
We engage in a bunch of behind-the-scenes testing while building the site including code quality and accessibility. But the kind of user testing we’re talking about here is the most exciting part of QA. It involves ensuring that your front end users have a visual experience that matches the designs and that everything works as expected from a functional perspective.
‘Testing’ is the window where the new site has been deployed onto a development environment in order that it can be put through its paces.
Can we get involved?
Yes! In fact, your contribution at this stage is incredibly valuable in our opinion.
Not only do more eyes mean more bugs caught more quickly, we find that the process is much more efficient when our clients are involved. Nobody knows your site like you do. You know how it should look; you know how it should work.
How do we get involved?
We aim to make it as straightforward as possible to log feedback on your development site. Not all of your testers will have been involved during the project up to this point and we don’t want that to be barrier. For that reason, we use marker.io as our bug logging tool which makes the process a simple matter of pointing and clicking.
When the testing window opens, we’ll activate marker.io on your development site. This adds an unobtrusive tab to every front and back end page on the site which invites users to log their feedback.
The 5-step process for logging a ticket with us can be summarised as below.
- Browse the front or back end of the site.
- Look out for anything that doesn’t look right or work as expected.
- Click the ‘Log your feedback’ tab.
- Give your ticket a title and description. Add annotations if useful.
- Hit ‘submit’.
How do I spot a bug?
The primary objective of the QA phase is to flag bugs. Any incidence where a cosmetic element doesn’t match the scope of designs or a functional element doesn’t work as outlined in the sprint briefs – that is what constitutes a bug.
While it is certainly the case that many testers will not be immediately familiar with the scope of the project, most bugs are discernible by matching common sense expectations against what is encountered on the dev site. If a button can’t be clicked, that is a bug. If a shape obscures some text, that is a bug. If a page fails to load, that is a bug.
Any issue we receive that does not fall into the category of ‘bug’ is considered ‘out of scope.’
We generally expect our clients to guide their testers through the scope of their project and to educate them on expected functionality. However, where we are looking to focus on anything specific, SMILE may provide a testing plan which provides some useful prompts. For example:
- “Try signing up”
- “Try navigating to a course”
- “Try submitting a piece of content”
I’ve spotted something I don’t like. But I’m not sure it’s a bug. What should I do?
Any ticket that is submitted will be triaged by the operations team at SMILE. For that reason, it is true that the bugfix phase runs more smoothly if we can focus our time and attention on bugs alone.
However, we are aware of two factors:
- Testers may not have had time to familiarise themselves with the scope of the project.
- Our clients’ project leads may want to collect feedback and feature requests from real users.
Therefore, we don’t put a hard barrier on the type of feedback we ask you to log. Please just be aware that it will take longer than usual to delegate bugs to the right developers if we receive a torrent of feature requests via marker.io.