ABC of QA. Why do you need a Quality Assurance engineer?

That’s a lot to worry about! Fortunately, there is a person, called Quality Assurance engineer, whose job is to take care of those things. Rather than asking yourself do you need a Quality Assurance engineer in your development process, think about why your project doesn’t have one yet!

Expensive mistakes

You wanna know what happened to the space probe, don’t you? Climate Orbiter was sent to Mars in 1998 to learn more about the Martian atmosphere and climate. Mission failed because NASA engineering team forgot to convert from English units to metric. Eventually, spacecraft worth $125 million was lost in space.

What about Heathrow Airport? They got into trouble during the opening of a new Terminal 5 – things went downhill after the shutdown of a brand new luggage handling system. 42 thousand bags were left behind and 500 planes were stranded causing cancellations. Reason? The system wasn’t tested for real-life scenarios (e.g. customers demanding their bags back because they left their passports inside), and as a result, overloaded and died.

Those aren’t even the most expensive software mistakes in history, but you can paint the picture now – if it happened to NASA, it can happen to you. It’s time to meet the Quality Assurance engineer.

Who is a QA engineer?

Quality Assurance engineer makes absolutely sure that the developed software operates on the highest quality level, and doesn’t contain any elements discouraging from using the service. In order to do that, they carry out insightful and thorough tests.

Their inside-out expertise is based on vast knowledge, as they test code written by the developers throughout the project, combine different parts and check how/if they work together. Software development projects always have some common elements, therefore, the experience of Quality Assurance engineer grows with every new app they’re testing.

And, last but not least, QA engineer simply is proficient in UX and precisely know how it affects the quality of software.

To put it simply: Quality Assurance engineer is the first, the most demanding, and surely the most annoying user that finds every little flaw. And you’re gonna love them for it.

Awesome, but why can’t developers test their own code? It’s not a good software development practice and just doesn’t work. Devs are great at what they do, which is writing code during the development process. Since they create only a part of the whole project, they lack the big picture perspective and real-user experience.

After spending hundreds of hours on something, you just stop noticing little details and mistakes may be overlooked. Finally, no one likes to criticise their own work. That’s where the QA engineer role begins.

Quality Assurance is more than just testing

Quality Assurance engineer should be an integral part of a team and be involved in product development from the very beginning. At an early stage, QA engineers identify risks in the project, collect and adjust requirements, analyse customers’ briefs and advise better options if something is impossible to do.

You’re probably going to meet your Quality Assurance engineer on one of the first meetings, carefully reviewing every technical detail in order to make sure that the final product meets your business requirements. QA engineers are doing it for your (project’s) own good, so don’t be surprised if they have a lot of questions or suggestions.

Quality Assurance engineer has two main areas of interest: ensuring the highest quality of product/service by controlling product progress and testing the hell out of every feature.

Even before the project starts, QA engineers are responsible for defining and supervising quality standards, as well as Quality Gates – a list of quality checks that the product must pass in order to move to the next phase. The most important are:

• Definition of Ready – making sure that requirements are understandable, which prevents from implementing anything unclear.
• Definition of Done – ensuring that the requirements are adequately tested and meet customer expectations before the final presentation.

As far as the testing is concerned, QA engineers have a lot of work to do on a daily basis.

To begin with, Quality Assurance engineer validates newly created functionalities, which means that developers immediately get feedback on what needs to be fixed, rewritten or improved. Furthermore, Quality Assurance engineer tests non-functional requirements – security, usability, portability and performance. The latter is especially important when mobile applications are concerned.

Imagine how many different phones are out there on the market. All of them have different screen sizes and operating systems. And all operating systems have different versions. The finished mobile app has to be compatible and work flawlessly on EVERY phone, and EVERY version (well, at least the most popular ones) of EVERY operating system. Finally, they oversee and control automated tests. That’s a lot, right?

The last step is feedback. As a user, if your app crashed, you just say: “It doesn’t work”, delete the app or stop using it altogether. Luckily, QA engineers are much more thorough. The information you receive from a Quality Assurance engineer includes screenshots, device type along with the operating system version, description of what action was performed, that the error occurred, etc. In this way, developers are able to quickly locate the bug and fix it.

Why do YOU need a Quality Assurance Engineer?

As we’ve established before, Quality Assurance engineer on board improves the quality of the product from its very early stage by defining standards for testing requirements and the product itself. We’ve also explained that developers cannot test the code they have written because they become predictable in tests, often omits bugs which extends the entire process, causes delays, and just doesn’t work.

Developers are there to implement the given features, finish a specific task; not to verify the client’s ideas. Somebody has to do it though, and your guess it right – it’s a QA engineer.

Quality Assurance engineer is wise BEFORE not AFTER the event.

Apart from saving precious time, you also save money. Longer project means higher bills, and fewer mistakes mean less work time. Simple as that. Quality Assurance engineer offers consultancy regarding the project scope at its very beginning – it’s better to think the project through in advance, rather than endlessly correct mistakes during the implementation.

Developers’ hourly rates are high, and we know that you’d rather have more control over their work. QA engineers make that happen through software testing – everything is checked on a regular basis, right after implementation, rather than at the very end of the whole project.

If you still think that hiring a Quality Assurance engineer is an unnecessary cost, then think about the expensive examples we presented at the beginning of this article. Of course, you can always risk it and give up Quality Assurance altogether, but when production defects will materialise (and trust me, they will), it will cost you waaay more than QA engineer job.

Web applications are one thing, but mobile apps are another. The mobile market is booming, and everybody wants to be closer to their clients via smartphones. No wonder, as checking their phone is probably the first and the last thing customers do every day.

We’ll tell you an industry secret – it is important to test mobile applications on actual devices, NOT emulators only. There are too many variables: screen size, system versions, different models, etc., and emulators are simply unable to detect everything. Working station of a QA engineer look like phone stores – they need to make sure that the finished product will work on every device without any problems.

Do you know what happens if you neglect that? I’ll give you a real-life example. App Store or Google Play have so-called “reviews” – before your new app (or a new version of your app) is being updated, it’s being checked. If it’s legit, it’s being uploaded to the platform.

Let say users found a bug in your application, the rating is going down and naturally, you want to replace it with a new, fixed version. Surprise! It cannot be done automatically – you have to wait until platforms check the fix and replace the version. It can take a few hours, it can take days – you never know. 

It’s a huge waste of time, more and more users will download the defective app and, I guarantee, angry comments are going to appear. Errors can be fixed, but there’s always going to be a crack on your company’s reputation. Should have hired a QA engineer? Hindsight is a blessing!

TSH Bugbusters

Every project in The Software House has a Quality Assurance engineer on board. The Quality Assurance department was created due to the growing demand for high-quality software standards in the company. All technical departments cooperate closely, understand and help each other.

Every QA engineer is constantly raising the quality bar for developers by establishing appropriate procedures for the development process. What’s more, we update and enrich the list of Quality Assurance testing devices (e.g. smartphones), to make sure that applications we deliver to the customer will be tested in and out.

The main responsibilities of a QA engineer in The Software House are:

• performance tests,
• security tests,
• regression tests,
• business analysis,
• ensuring proper standards in the projects,
• keeping an eye on the Quality Gates in the development process,
• proposing adjustments in the project production,
• educating other team members in quality-related matters,
• writing project documentation,
• gaining new knowledge about test frameworks,
• introducing best practices in automated testing,
• creating internal systems.

Busy bees, aren’t they? Now you can see how much work of a QA engineer it actually takes to make customers happy and satisfied with the final product.

Not all heroes wear capes

Our QA engineers have already saved dozens of projects. You probably want to make sure that these aren’t just empty words. I’ll give you three different examples of how our brave engineers saved the day.

Let’s start with platform X (out of respect to our clients we won’t be disclosing names) which initially was developed by five people, but due to the projects’ rapid growth, eventually, 17 programmers were engaged in the development process. Each part of the platform was created by a different person.

If it wasn’t for a Quality Assurance engineer who was managing the process globally, linked all the parts, delegated tasks, quickly trained and introduced new devs to the project, the whole thing would be extremely painful to finish.

Another time, our Quality Assurance engineer caught a credit card problem in the food-ordering mobile app – when more than one card was linked to the account, only the first one was actually working. Moreover, another QA engineer found a few “empty” buttons, and completely different restaurant lists on iOS and Android versions. Unacceptable.

Sometimes we get a project which has already been “sort of finished” and we just need to polish it (not because we’re Polish, just because we’re good). In reality, it’s often far from it. Application Y came to TSH with a completely messed up backend.

The client wanted to add some more necessary functionalities, but somehow nothing was working. If it wasn’t for automated tests set by the QA engineer from the Quality Assurance team, this app would be released on the market as a sequel to “A Bug’s Life”. Because, you know, it was full of critical errors (dad joke intended. We like the movie though!).

Luckily, robots set up by our QA engineer caught up the problems pretty early, so we were able to fix everything nice and clean.