How to successfully QA your website remotely
A large part of any website development is ensuring it works as intended on all browsers, all operating systems and all devices.
At Arekibo, as part of our platform offering, we test all work we have done before we deploy it to live to ensure all bugs are caught and fixed before it’s live.
Pre-covid, QA was done in our testing lab with a number of physical devices, high quality monitors and both PC and MAC.
In March 2020 when we began working from home, I took the devices home assuming it would be a two-week assignment and then we’d be back in the office. Over a year and a half later and we have the remote testing process perfected.
Due to the realities of a remote working team, we no longer have access to our test suite in the Arekibo office so have had to pivot and continuously adapt. Our test strategy now involves a mix of testing on real physical devices and devices/browsers hosted on BrowserStack, a tool to test real browsers and devices instantly. We are currently looking into automation UI testing too to ensure we’re constantly improving.
Preperation
As with every task, preparation is key. Before I start testing, I ensure that I have the full picture, so I ask for the approved designs, what needs to be tested specifically, if there are any test cases to follow and if there are any existing bugs that we are aware of. Along with the standard devices and browsers, I need to know if the client has asked us to test anything specific to ensure I have access to that device or browser.
Test cases will be written in collaboration with development team on the project and include detailed steps to take, what to expect when I take those steps and what not to expect. The idea of a test case is to ensure the step-by-step process is working as intended and we can easily spot if there are any bugs within that process.
These test cases will be added to Devops.
Before I get into the testing process, I want to explain Azure Devops a bit more. Devops is the SaaS platform from Microsoft that can be used for end-to-end development and testing and in this instance, we use it to track any tasks or bugs through tickets. This is where I can track the number of cases, log bugs against these and the team can track the progress of the tasks or bugs provided.
The Devops board may vary depending on our project but we normally have a number of columns from New > Active > Resolved > Closed. See an example of the board below:
The New column would be where any new bugs or tasks are added and show that nothing has been done to that ticket. The Active column means whoever the ticket was assigned to is working on that ticket at the moment, they may add some comments to the ticket for further clarification or just leave it there which they work on it.
Once they’re happy that the issue is fixed and they’ve tested it, they will move it to Resolved where they would assign it back to me and I now know that they’ve fixed the bug, or done the task that is required. I would then retest the issue on the specific browser, and I may leave additional comments, move it back to Active if it isn’t fixed or move it to Closed if I'm happy that it has been resolved.
As I mentioned, I review any existing bugs, any open tickets or any tasks that haven’t been fully completed to ensure there’s no duplication.
Now that I have all the information that I need, I gather the physical devices I have, check what browsers are on my computer and log into Browserstack.
Testing
As the team is working remotely, we sometimes split up the testing requirements where a designer does a design review, a frontend developer does a functional test, a backend developer does a system test, and I may do either a visual test or a more interactive test where I check all widgets and forms are also working correctly.
If there are test cases, I work through those logging tickets specifically to the section of the process but if there are no test cases I would have the agreed list of URL’s or templates or widgets to test.
If the project just requires a visual test, I would use the browser that has been design reviewed as my comparison. For example, if the designer has reviewed Chrome and all updates have been made to ensure that browser is perfect, I will use that as my base.
Once I find an issue, I would log a ticket which as much detail as possible from the issue, the url, the browser or device, the operating system, screenshots and even videos are sometimes helpful. Once I add as much detail as possible, I assign it to the person and give that ticket a priority level.
Follow up
When I have completed the test and finalised the assigned bugs, I would schedule a call with the project manager to review what was found – especially if there were any P1’s or P2’s.
Along with that, recently we have introduced daily stand-up calls with the entire team including backend developers, designers and frontend developers as there is no face-to-face interaction. On these stand-up calls we would discuss any bugs, ask any questions and outline any issues or blockers.
Restart fixes
When one of the bugs I have logged has been fixed it gets assigned back to me in the “Resolved” column for me to confirm its fixed. From then I retest the issue on the specific device(s)/browser(s) ensuring the issue is resolved but also ensuring it hasn’t created another issue and I would move it to the Closed column.
Although we are eager to get back into the office to our testing lab I think we have adapted well and adapted quickly to working remotely. Even when we’re not working remotely, we will use some aspects of this process moving forward.
If you need help reinventing your digital presence or if you want to get more output from your website content, contact us today.