How to successfully QA your website remotely
/testing_blog-min.png?sfvrsn=74462ca4_1)
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 we have had to pivot and continuously adapt. Our test strategy now involves a mix of testing on real physical devices and on devices/browsers hosted on BrowserStack, a tool for testing real browsers and devices instantly. We are currently looking into automation UI testing too to ensure we’re constantly improving.
Preparation
As with every task, preparation is key. Before I start testing, I ensure I have the full picture: I ask for the approved designs, what needs to be tested specifically, whether there are any test cases to follow, and any existing bugs 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 the development team for the project and will 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 works as intended and that we can easily spot any bugs in 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 a Microsoft SaaS platform for end-to-end development and testing; in this instance, we use it to track tasks and bugs via tickets. This is where I can track the number of cases, log bugs against them, and the team can track the progress of the provided tasks or bugs.
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.
/devops-board-test-image-min.jpg?sfvrsn=c77fe1a1_1)
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, and they will work on it.
Once they’re happy the issue is fixed and they’ve tested it, they will move it to Resolved, assign it back to me, and I'll know they’ve fixed the bug or completed the required task. 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, open tickets, or tasks that haven’t been fully completed to ensure there’s no duplication.
Now that I have all the information I need, I gather the physical devices I have, check which browsers are on my computer, and log in to BrowserStack. It's key to remember that an ongoing browser and device testing service is crucial, and we offer this service through our ArekiboCare managed support.
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 URLs, 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 applied all updates to ensure the browser is perfect, I will use that as my base.
Once I find an issue, I would log a ticket with as much detail as possible: the issue, the URL, the browser or device, the operating system, and screenshots; sometimes videos are helpful. Once I add as much detail as possible, I assign it to the person and assign a priority level to the ticket.
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, we recently introduced daily stand-up calls with the entire team, including backend, designer, 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 is fixed, it gets reassigned to me in the “Resolved” column for me to confirm it's fixed. From there, I retest the issue on the specific device(s)/browser(s) to ensure it is resolved and 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 want to get more value from your website content, contact us today.
/itil-certified-agency.webp?sfvrsn=d838cfa9_1)
/b2b-aiseo-yes.webp?sfvrsn=c1278e05_1)
/cludo-partnershipacfb0690-5725-4ecf-8f12-4ff81435119e.webp?sfvrsn=31f81c5b_1)