Difference between a Quality Assurance Specialist and a Tester

Tester, Quality Assurance Specialist, Software Tester, QA Engineer, QA Tester… The position of a person whose main responsibility is to find bugs in software has many names. Their multitude often makes the heads of people outside the IT industry spin. So, today we’re going to look at the first two of the names listed above.

About a tester’s and quality assurance specialist’s job in a few words

The word ‘tester’ is associated with a person who performs some sort of tests, so simply checks something. It can be a test of a device, objects, or even chemicals. In IT, the tester is responsible for checking the software made by developers. They spot and report bugs so that the user can use apps after publication without problems. A tester most often verifies the test cases manually (this depends on the company they work for), which means that they checks given functions by themselves manually (without using automation tools).

The most basic form of verifying software are functional tests. Let’s say that an app has a logging in and registration module. A functional test here will be about checking if the whole module works properly. The first thing the tester has to check is the so-called ‘happy path’, i.e. the easiest, most obvious path for the user to take (in this case it will be registration and logging in with the right data). Next, they have to check cases which should not enable the user to go further (e.g. registration/logging in without entering the email address/password, the wrong format of the email address) and verify if the right message is displayed. Then, they need to make sure that the app won’t stop suddenly at any moment while conducting the test.

The tester also verifies the UI (user interface) looking for discrepancies with the graphic design, such as e.g. wrong placement of a button, wrong icon or missing icon, other type of the font or the wrong color of it – all differences should be communicated and explained. A good practice is to report your suggestions about the UI, i.e. what can be changed, what is not readable and may pose a problem for the user.

Another kind of tests are integration tests which are about verifying the information flow between modules and different systems. They are used, among others, when the app connects with different external systems or programs (e.g. a country’s banking system) or when one module downloads data from another within one app, also using information from yet another one.

A tester also runs exploration tests (you can read more about them in this article), which means they try to find an error based only on their own knowledge and experience, without a specification or documentation. Such tests can be complementary to the existing cases which have been taken into consideration and written down earlier. The tester always assumes that there is something which hasn’t been found before. This way, they keep being alert which enables them to find the app’s undesired activity. Moreover, with these types of tests you can update the base of cases for regression.

Before sharing the program in its newest form, they also run regression tests, i.e. checks if the app’s most important modules haven’t broken while making fixes and building specific app functions. These tests, considering their repeatability, are often automated in order to minimize the risk of overlooking an error by the tester due to having to repeat the same test over and over again.

So, what’s the difference between the job of a tester and a quality assurance specialist?

When reading this description a lot of people might think ‘alright, but a QA specialist does the same thing’. It is true, people on this position also run such tests, but it’s not the most important part of their job (at least it’s not according to the definition of the position). The scope of a QA specialist’s responsibilities is much broader – their priority, beside the tests, is to measure general quality of software and optimize processes and the whole software life cycle. During each of these stages, they have one question that determines the overall objective: ‘Will the client be happy with this app?’. Naturally, part of the answer is given by statistics in the form of the app’s errors caught and crashes that have been prevented. But with numbers alone, you can’t describe the ‘wow’ effect which goes with a well-built, intuitive and fluently working app.

In short, a good QA specialist should not only break the app in every way possible, but also make sure that in certain conditions and strictly defined environment (or environments), it will be characterized by the highest quality and reliability, and the set criteria will be met.

The most important thing, however, is to remember what the common characteristics of QA specialists and testers is – providing the product of the highest quality. There are different ways to do that, but the priority is the same.

What does the work of Quality Assurance Specialist in Appchance look like?

Working with testing apps also requires constant attention in searching for bugs (and often patience) and openness to all kinds of suggestions. Regardless of whether it is just a suggestion of a better translation of a document (many people seeing a poor translation assume that the rest of the app is equally poorly written), or rebuilding the whole function in an app, every suggestion is appreciated. Developing the ability to listen, promoting a mutual feedback culture, transparency in information exchange and an exquisite attention to details all contribute to the one result: creating a product of the highest quality.

How do we do it at Appchance (in a nutshell):

The team familiarize with the app specification presented by a Project Manager and user stories and design project. At the same time, any uncertainties are reported, we ask for missing details (e.g. details of validation of fields in forms, target group for the product, use cases for the app, types of users, target market for the app) to prepare the ground for tests, i.e. test data as well as possible.
We prepare scenarios and test cases which are supposed to cover the basic use behavior path for every functionality in a given sprint (the so-called ‘happy path’, i.e. the desired behavior of the app, with the omission of non-standard behaviors), and then pass it to the developers.
After completing the first tests run during a given sprint, the team goes on to exploration tests to find bugs and behaviors that haven’t been considered, completing the test scenario for them.
During the tests of functionalities and retests, further cases of behavior in the app are prepared (mainly for the new functionalities) and previous test scenarios are updated (if there have been changes in the assumptions of the stages carried out before).

It happens that some queries to QA regarding the small errors are viewed as nitpicking. You need to remember, that if the tester doesn’t submit their remarks, most probably the client will. It is commonly known that it is the small elements that define perception of the whole – if there are small bugs that are easy to fix or avoid, the client may very well assume that the rest of the program is also done just as sloppily. This in turns affects negatively the reception of the whole product, which the QA specialists try to prevent. After all, it’s the client’s and end users’ satisfaction that we care about the most.