Underestimated Team Members: Why You Need Quality Assurance Engineers

(101)

Olga Demidenko , Author at Geomotiv
Reviewed by Egor Zablotski, Director of Engineering at Geomotiv
Published: Mar 29, 2019

Suppose you are having an important conference next week where you’re to act as a speaker. Obviously you need a great speech to be written to make an impression. You exert every effort and finally the draft is ready. After a quick review you find it quite satisfying. However, you decide to pass it to your colleague just to be on the safe side. 

Much to your surprise, he spots a bunch of problems. The problems vary from simple spelling mistakes to logical errors. You thank your coworker for help and ponder why you couldn’t find all those errors yourself during your check-up. But don’t blame yourself too hard. People are rarely unbiased in their view on the piece of work they’ve been working on for a long time.

This situation is common in many spheres including software development. That’s why big companies such as Geomotiv have a number of in-house QAs. They check the developers’ work to assure high quality of the end product. 

The Essence of Quality Assurance

Let’s clarify the role of QA Engineers. Quality Assurance is not only about bugs finding; the term has a broader meaning. 

First and foremost, the QA engineer is responsible for improving the quality of a product. Apart from testing the code, they must also make sure the final product is user-friendly. It implies efficiency in a number of aspects (processing speed, functionality, performance, design, etc). The tester will notice if anything works incorrectly or remains unclear to the user. 

Types of Software Testing

QAs don’t test randomly. There are a number of techniques they use extensively. Those may vary and some of them may even be automated. Now let’s consider the major groups they fall into:

  • Unit testing  runs tests on small code pieces, i.e. separate functions or components. The technique is easy to automate and is quite important to use.
  • Integration testing is based on the idea of testing components as they are tied together in clusters. The QA examines how two or more units would interact with one another. The Integration technique is used when Unit testing proves insufficient.
  • Functional testing focuses solely on functionality and whether it corresponds to the business requirements. In other words, the tester is supposed to make sure the database yields only the information as defined in the specifications.
  • Performance/Load testing runs system tests under the conditions of high load. QAs check the system response time, stability, general behavior, etc.

QA teams in big companies usually make use of several concurrent techniques. For example, Geomotiv uses Unit and Integration approaches. It allows the code quality to be improved, and the product, tested as extensively as possible.

Responsibilities of a Quality Assurance Engineer

Let’s classify the direct responsibilities of QAE into a list. So, the Quality Assurance Engineer is to: 

  • Take part in drawing up business requirements and test them later;
  • Work out test documentation such as test cases and checklists;
  • Identify bugs and defects in software (that’s just one of his many functions);
  • Assign bug priorities (from minor to critical);
  • Test the product at all the development stages;
  • Review new features upon implementation and perform regression tests afterwards;
  • Make sure the product complies with the agreed requirements.

As is seen from the list, the QAE mostly checks the work of other people. Many business owners think it would suffice just to hire experienced developers. They believetheir code is supposed to be perfect. But this approach almost never works. It's all because the present-day software is a complicated system. It consists of lots of interacting parts such as frameworks, libraries, side services, etc.

It’s difficult to keep all those things in mind and it is no surprise that ideal code remains only a pipe dream. Still, QA Engineers work hard to make it come true. 

Why Developers are not Good Testers

The question is quite popular indeed. First and foremost, developers can’t properly check their own code. As was already mentioned, people tend to treat their own work somewhat differently, and devs are no exception to the rule. Even though they would assure the code works well, they wouldn’t be able to provide sufficient proof. Developers simply can’t consider all the testing scenarios that QAs would use. 

The cause lies in the mindsets. Developers and QAs think different as their tasks are directly opposite. While software engineers tend to create, testers are supposed to find possible ways to break down.

But in no way are QAs evil. They are just the last bastion of quality. It is them who should assure high product performance at all costs.

QAs are Profitable

Now that the essence of QA should be clear, it is time to summarize the benefits the QA guys can provide your project with:

  • All aspects work properly as expected. Suppose you have a service that gathers ad impression statistics in European countries. However, a couple months after you launch it you find out the system mistakes Austria for Australia — a fatal error that could have been avoided with just a simple manual test. 
  • Cost are cut down. The later a bug is found, the more expensive it is. Each subsequent project stage requires more time, effort, and money, to fix an issue. It would be way better if there were someone to test the project from the very beginning, wouldn’t it? 
  • Project compliance with the requirements is assured. Developers are creative folks and they can sometimes allow themselves to depart from the requirements just a little bit. QAs should be there on the watchout to ensure the final result meets the set specifications.

Apart from technical background, Quality Assurance Engineers need theoretical knowledge to develop QA documentation and run proper tests — something not every developer can manage.

QA Means Quality in the First Place

Donald Norman, head of The Design Lab at UC San Diego, once said: “Good design is actually a lot harder to notice than poor design”. Put “quality” in place of “design” here and you’ll get the QAs’ motto. So next time you see a product that’s easy and enjoyable to use, remember it has all the hard work of QAs behind it. Never underestimate those guys’ role in getting a high-quality product.

SHARE THIS ARTICLE

Blog

Recommended Reading

The term “regression testing” is not always associated with Agile...

Let’s find out what is the difference between manual and...

In this guide, we’ll research whether investing in a custom...

Success lies in adapting to significant shifts within the retail...

How does data analysis aid in improving the bottom line...

01
/
05