Back to Basics: Quality Assurance & Testing

By Taryn Engmark

Associate Editor

Embedded Computing Design

In our last article, we broke down the debugging process and its many woes, but also reviewed some tools and tips to make it as easy and painless as possible. Where debugging is the process of finding bugs that you know exist in your code, quality assurance testing is when you find bugs that you weren’t aware of.

Welcome to Back to Basics, a series where we’re going to be reviewing basic engineering concepts that may require a more complex explanation than a quick Google search could provide.

As with any product or service, you want to ensure your offering works the way it’s supposed to in any use case it can be implemented in. You’ve probably had the experience of downloading or even buying a piece of software only to realize that it’s full of bugs. To prevent users potentially handling your software from having the same experience, you’ll need to do some quality assurance.

By the end of your quality assurance testing, you should be able to confidently say that your code will work in almost every intended use case. We approach testing much the same as debugging — the scientific method.

(Gently) Take a Sledgehammer to Your Cod

As you test your code, it is best to think of yourself as a scientist creating simple experiments to prove the hypothesis that your code is bug-free. To do this effectively, your experiments must try to break your code, rather than prove what you know it can already do. Take, for example, a piece of software that adds together two user-inputted numbers. To test this effectively, you could input a word instead of a number. If this breaks the code, you’ll know you need a fix in place to safeguard against tampering.

Once a test like this is in place it’s important to remember, just like when you were debugging, to only change one thing at a time. If you run a test and find a bug, don’t change the test AND the code simultaneously. If both factors are altered, your experiment no longer proves which change fixed the code.

With those basic principles in mind, there are several aspects of code that can and should be tested depending on your design constraints. (Remember those?)

Simple Bug Catching

This process is just finding any pesky bugs that may still be hiding in your code. To test for these remaining bugs, stretch the boundaries of how you think the code will run. What happens if you use floats instead of integers or run the code for twice as long? Look for edge cases, and then test them.

Input Testing

Most software requires some kind of user input, which makes it prone to human error. To properly implement an input test, check that any inputted value does not cause an unexpected result like a crash or improper output. Use tools like value checking and error messages to tell users how to properly input data.

Load Testing

If your code is to be distributed on a large scale, load testing is a must. Load testing measures what happens when the software is run on either a small machine or at maximum capacity. Are there memory leaks in your code? What happens when 2,000 instances of your program are run synchronously? Load testing makes sure that your code is ready for any sized task it’s given.

Platform Testing

Oftentimes, your code may run on multiple platforms, whether that be multiple operating systems, browsers, or screen resolutions. Platform testing ensures your code behaves as expected on any device.

User Experience

What happens when someone other than you, the programmer, uses your code? User experience testing makes sure that your software is intuitive and friendly for external users.

Shh! Testing in Progress

While there are many more quality assurance tests you can run for a multitude of other factors, it’s best to keep your design requirements in mind and be confident that your code will meet them in any situation. In the end, your code should be a polished unit that you can be proud of.

Additional Resources:

When you’re finally finished with your QA and Testing, it’s finally time to move to our next step: releasing your software into the wild. So take a deep breath and trust the process, but for now, Happy Testing!

Click here to read the first installment of Back to Basics: Ideation & Requirements

Click here to read the second installment of Back to Basics: Development Stack

Click here to read the third installment of Back to Basics: Configuring the Development Environment

Click here to read the fourth installment of Back to Basics: Pseudo-coding

Click here to read the fifth installment of Back to Basics: Coding and Commenting

Click here to read the sixth installment of Back to Basics: Debugging Code