The job of QA testing is to force website issues to the surface for the sole purpose of ensuring users don’t face these same problems.
Anyone who works in the world of web knows that projects running exactly as planned is rare. The last stages of a project can be particularly frantic. Everybody is eager to launch and there’s the added pressure of those fast-approaching deadlines. The result is that timescales get squeezed, but this is exactly the right moment to take a step back and ensure quality.
Launching a site that isn’t quite ready can cause irreparable damage to your brand. After all, you only have one chance to make that first impression and a poor experience could cause you to lose that customer for good.
In this blog, you’ll learn about…
- What QA testing covers and why it’s so important to a web project
- The difference between test cases and test suites
- Why regression testing should always be done
- Forms of testing including user acceptance testing, negative testing and mobile testing
When a new project begins, a functional and technical specification document will be produced and are essential to the testing that will follow.
Detailing what the project is about, the functionality that will be included, an understanding of said functionality, amongst other project requirements, they must be solid and complete to allow the necessary test to be created.
Writing test cases
You may hear the term ‘test case’ used. A test case is exactly what it says on the tin: it outlines what is going to be tested and how to ensure each element of your website works as it’s supposed to.
Once the functional specification document has been created, it’s time to start writing out test cases. These can then be recorded and linked back to a particular requirement in the technical specification document as part of the QA testing process, showing each of the test cases that have been conducted.
Creating test suites
A test suite is a collection of test cases grouped together that explore a particular area of the website. Each test suite will contain the test cases involved with that area of the site. For example, you may have test suites for the:
- Checkout: If you need to test the checkout area of the site, test cases that cover the basket and the different stages of the checkout process would be grouped together.
- Design: You may have a test suite for the site design which could be broken down into a mobile test suite for the homepage and desktop test suite for the homepage.
- Account: For this area of the website, your test cases would cover various functionality such as creating an account, logging in and viewing orders.
Typically, when tests suites are completed for the first time, a higher percentage of failures will be seen. The idea is that as you rerun those same tests throughout your project, you’ll see the progress in your test scores.
Test suites are also a great way to spot if something has suddenly gone wrong following the rollout of a fix to your website. If there’s a substantial change that sees failure rates sharply rise it would indicate a problem. This allows testers to advise the development team so that they can roll back the changes made and work through the issue.
When a fix is rolled out, it shouldn’t just be tested in silo to simply check it now works as it’s supposed to. Instead, regression testing should be undertaken. This is the process of testing all other functionality that interacts with the fix to ensure that the change hasn’t impacted anything else.
We always test critical functionality as part of our regression testing too, such as the checkout, sign up functionality or ‘my account’ area. Essentially anything that is deemed critical to your site functioning.
Regression testing is all too often given a back seat as the pressure of project time constraints mount. But it’s important to remember that regression testing is just as critical in those final project stages. Even though it’s tempting to think “my website is pretty much finished” and only minor tweaks are being made, there’s still the potential that these minor tweaks could have a knock-on effect on something that had previously worked seamlessly.
Mobile centric testing
In our experience, bugs found on mobile tend to be trickier to fix than on desktop. Given that, on average, 80 percent of traffic on eCommerce stores is driven by mobile devices, there is greater commercial importance for the site to operate perfectly on mobile. As such, the impact on your success due to a problem with your mobile experience could be significantly more detrimental to your brand, reputation and sales.
For these reasons, we complete our mobile tests first to give the development team plenty of time to work through any bugs found.
Negative testing is the process of testing the website using ‘bad behaviours’. Involving a lot of clicking, back and forth between pages and fast movements, conducting actions that the system shouldn’t really do helps to find ‘edge case bugs’.
While these actions are something a user may never do, it allows us to identify what will cause the site to freeze and eventually crash to prevent users from ever being affected in this way.
User Acceptance Testing
The final stage in testing, User Acceptance Testing (UAT) is when the site is passed over to you, the client, to check. You know your website inside and out including how it should operate and that’s why it’s vital that you’re part of the testing process.
During UAT, a communication channel opens between the client and the QA team. This stage gives you the opportunity to confirm you’re happy or advise on changes. A sufficient resource to thoroughly test your site is needed and we’d also recommend that client’s give focus to regression testing too.
Close communications allow bugs to be quickly confirmed and passed to the development team to be scheduled. If multiple issues are found, those that are blockers to the launch will be prioritised.
Why your website needs QA testing
There’s huge value in thorough testing and equally huge impacts of not giving it the time and attention it deserves. If you continuously deploy bad code, your reputation will likely be damaged.
By having solid processes in place, your web development agency will be able to avoid the need to ‘quickly test’ something which could see potentially important issues missed.
QA testing is all about prioritisation. There will always be something that needs to be tested post-launch but, by following the right processes, it won’t be anything that blocks your site launch or affects overall functionality.
At Pinpoint, QA testing is non-negotiable. If you want to know more about how we ensure quality through our approach to testing, don’t hesitate to get in touch with Team Pinpoint for a chat.