So, what do QA Engineers at OXD do?
Recently, an OXD client asked what a typical day looks like for me. As I answered, I realized it wasn’t a short description. So, what do OXD QA Engineers do? What perspectives do we bring to software quality? Where did we learn this stuff?
Let’s look at some of the things our QA Engineers take into consideration when testing.
Curiosity and constant learning
QA is not a single, well-defined process. At OXD, we work on a variety of projects, including complex applications with detailed user interfaces, business logic, and databases. We also work on simpler ones that retrieve and display information. These applications and websites can involve a variety of technologies, from familiar to new and leading edge. As a group, we are curious and always learning: tech stacks, programming languages, security, accessibility, usability, and continuous integration pipelines are a few facets we’ll discuss here. Whatever the project requires, we learn it.
How does the system architecture work?
Our QA Engineers must understand the underlying technology of a software system. How does data flow to and from the user in an application? Where in the system does data validation occur? How is data stored and retrieved? When we understand the architecture of a software system, we can better approach how to test it.
Do we need to learn a new language?
Software programming languages evolve constantly. Languages can become outdated (FORTRAN was my first), and updated ones appear on the scene. Our QA engineers need working knowledge of these languages in order to effectively test. We can read the code, and better yet, write test automation, which we will discuss further.
Can we automate the testing?
An exciting addition to software engineering over the past few years has been continuous integration. This is a framework in which a developer’s code change can automatically kick off a new build of the software. We augment this process by adding automated tests and security checks. The benefits of this are efficiency, repeatability, and rapid feedback if there are any problems. Here, QA Engineers contribute by adding the tests to the automated process, along with our regular manual testing.
Does the product meet security requirements?
After many high-profile software security failures, it’s no longer acceptable to build a product without security in mind. A catastrophic leak of users’ private information can damage a company’s reputation. Software Developers at OXD consider security when designing and writing code, and our QA team tests for it. We can test for many common and serious vulnerabilities using tools designed for the task. Security testing is often budgeted for in many of our projects.
Is the product inclusive and accessible?
Companies want to reach the broadest range of users with their products. Being a socially responsible, inclusive, and accessible brand is a good thing. Accessibility for users with hearing, motor, visual, speech, neural, or cognitive challenges is a key component of this goal.
As with security, OXD Developers and QA Engineers create software that addresses these challenges as required. This may entail building a user interface with suitable colour contrasts for the visually impaired. It may also include integration with screen readers for those with limited hearing, or navigation through simple keyboard access for those with motor impairments. Additionally, government websites in many jurisdictions are legally required to comply with accessibility guidelines. Our QA engineers test for these aspects of accessibility with specialized tools and knowledge built up through experience.
Before I had eye surgery, my deteriorating vision compelled me to use accessibility settings on my computer when I noticed a website was difficult to read. Bringing empathy into software testing is necessary.
Did we keep the user in mind?
Staying on the topic of empathy, our QA team always keeps the user experience in mind. We may test a website many times, but it’s critical to continuously ask ourselves about the product’s usability. Is this product difficult to use? Is there something about it that doesn’t look right? It’s easy to lose sight of things like these when testing to see if a product is working as expected. So, we need to step back and think from the user’s perspective. Here, we collaborate with UX designers to understand how the product will be used, what it will actually look like, and what are the most important needs our clients have. With this knowledge, we then determine how we will go about testing.
Have we communicated effectively?
Communication is the key to what we do. We know how to talk to developers about technical stuff. We know how to talk to UX designers about usability and accessibility. We know how to talk to project managers and scrum masters about risk. Our QA team also knows how to explain things in a way that is most helpful and digestible for our clients and the people who will use the software.
How do us QA Engineers keep our practice current and exciting?
QA challenges
We hold regular meetings where our team members share useful information, like showing new and interesting things they discovered. We also organize exciting team challenges focused on web security and testing automation.
Training
We take part in courses, including a multi-week training program to learn the most common security vulnerabilities, attacks, and how to apply state-of-the-art tools to enable this testing.
Read blogs
We like to read and learn from various sources about software testing. Some of the ones we follow include Stories from a Software Tester, an interesting blog that covers technical and philosophical aspects of testing. We also find StickyMinds, a website with both free and paid content on various topics related to software testing, to be helpful. Additionally, we visit Software Testing Weekly, a website that provides news, discussions, and information about automation and testing tools.
Watch webinars
We learn a lot from independent and vendor-sponsored webinars. Usually, one of our team members attends the webinar and then shares the information with our whole team. Here are some recent webinars we’ve watched:
- “The 2023 State of Software Quality Report,” sponsored by Katalon
- “Cypress vs. Playwright,” a comparison of two popular automated testing frameworks
- “You, Me, and Accessibility: Empathy and Human-Centred Design Thinking”
- “Introduction to Web Security with Postman,” which discussed leveraging one of our favourite tools for security testing
YouTube channels like Alan Richardson’s “Evil Tester” series are also great resources.
QA Engineers at OXD are committed to delivering excellence every day
Quality assurance is not something you learn in school. In fact, it’s often a computer science branch that’s learned on the side. At OXD, our QA team comes from diverse backgrounds, including information technology, cognitive systems, and pure and applied science. My background includes being a research scientist in laser spectroscopy, a software developer, a project manager, a musician, and a trained chef.
We gravitated towards QA because it’s what we love to do.
Our team enjoys our work, because while we’re serious and focused on what we do, there’s a sense of play in how we go about it. We are explorers, always asking “what if?”, and we enjoy learning something new every day.
The QA Engineers at OXD love taking things apart to see how they work—and then making sure everything functions properly. We not only test software but also the requirements and assumptions that go into the end product. This clarity helps us communicate better with developers and clients. The whole team is invested in building excellent and sustainable software for our clients and their users.