Introduction to Software Quality Assurance

Sometimes, the software will work for its intended purposes, but there’s always someone who will force an unintended interaction (be it intentionally or by accident). If that person succeeds in doing so, what can we say about the quality of the software? That’s the topic I’ll try to explain in this post.

Quality is a complex topic because we measure it based on how we perceive it. The client won’t judge the quality of the software with the same metric as the developer. Different clients will have different opinions on quality, ensuring SQA is a never-ending, constantly evolving process.

This is why we can (and do) have different approaches towards defining a quality model. All of them could be considered correct. After all, we’ve already established that quality is in the eye of the beholder.

The models I’d like to mention are:

• Transcendental approach: This relates to the statement that quality is hard to define. “Although I can’t define quality, I know it when I see it.”. While we can all agree on this, it is a personal statement recognizable through experience.
• User-Based approach: Quality is defined by the user’s experience with the software. This one also implies that software quality is not absolute. It can change with the expectations of each user.
• Product-Based approach: A product-based definition is different from the rest; this is a view of quality as a measurable variable dependent on its attributes. A simple example would be a hard drive, where an HDD with more disk space and read speed is of higher quality than the rest. However, some of those attributes on software could be performance, features, reliability, aesthetics, durability, etc., some more ‘objectively’ measurable than others.
• Production-Based approach: This is also known as the ‘Manufacturing approach.’ This one views quality as conformance to requirements; any deviation from the intended requirements reduces quality. This one is also more objective than the others, as it seeks to objectively measure the degree to which a product complies with pre-determined specifications.
• Value-Based approach: Quality in terms of costs and benefits; the more benefits outweigh costs, the more a product increases in value. As a result of this ‘equation,’ the product that performs best may not provide the highest value; thus, it is not the highest quality.

It has to be noted that when talking about quality models, you’re not locked into using just one of those; on the contrary, the more approaches you can employ on your software, the better it should end up.

But of course, software, stakeholders, clients, and everybody else involved in the development/use of a product will have an opinion deviating into one of those models. So, a middleman is often required to focus on the product as a whole. This is where the QA Analyst shows up.

But even then, how does the QA Analyst define quality? Although not being involved directly in the project as a software engineer or as a client helps have an unbiased opinion, you have to empathize with both points of view to try and create the best possible outcome.

My experience as a QA Analyst at nowports

In nowports, I have the great pleasure of working as a QA Analyst for the data science team. My role is a bit more biased towards ensuring the quality of the software’s development-side requirements as opposed to viewing the software from the user’s point of view.

Those development requirements are split into three categories:

• Functional Requirements: The function that the software must be able to perform.
• Non-Functional Requirements: Not what the software will do, but how the software will do it.
• Performance Requirements: The measured quality of a function, how well it performs. This one is an attribute of a functional requirement.

Although I have to assure the quality of those development-side requirements, the approach I have to make is that of a user (or, better said, many users).

I like to compare the process to that of the scientific method: First, I learn about the subject; formulate a hypothesis on how it works; experiment with it; analyze the data obtained from such experiments and then report the conclusion.

There could (and should) be a lot of repetition of this process in my field, since the software is constantly evolving in search of refinement and always adapting to users’ needs that come up with more expectations. It isn’t an easy task to ensure that a product works not only as intended but that it doesn’t fall apart when someone tries to break it. This is why it’s essential to be surrounded by people that have a great understanding of the tools they use, what they use them for, and who they use them for, and that’s something that I am pleased to be able to say today.

I take great pride in how everyone at nowports works towards a high quality on every product we ship. Our motto is “Ship Happiness,” but this sign is accompanied by “Ship Quality” because the quality of our product ensures the happiness of our users.

That’s everything I can say to you today. I hope that I’ll be able to expand on my knowledge of this field and share it with you again in the future.