What do Mars Climate Orbiter spacecraft and Heathrow Terminal 5 have in common? They were both supposed to be ground-breaking projects, but instead, they brought massive losses. All because small software failures that could have been easily avoided by appropriate testing. High-quality products/services are free from basic errors that may cause financial or reputation losses, delivered on time with accordance to business requirements, well documented and supported. That’s a lot to worry about! Fortunately, there are people, called QA specialists, whose job is to take care of those things. Rather than asking yourself do you need a Quality Assurance engineer, think why your project doesn’t have one yet!
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 QA engineer.
Who is a QA engineer?
Quality Assurance engineers make 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 projects always have some common elements, therefore, the experience of QA specialists grows with every new app they’re testing. And, last but not least, they simply are proficient in UX and precisely know how it affects the quality of software.
To put it simply: Quality Assurance engineers are the first, the most demanding, and surely the most annoying users that find 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 practice and just doesn’t work. Devs are great at what they do, which is writing code. 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.
It’s 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 folks 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 them on one of the first meetings, carefully reviewing every technical detail in order to make sure that the final product meets your business requirements. They’re doing it for your (project’s) own good, so don’t be surprised if they have a lot of questions or suggestions.
Quality Assurance engineers have 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 specialists 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) and 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, QAs validate newly created functionalities, which means that developers immediately get feedback on what needs to be fixed, rewritten or improved. Furthermore, QAs test 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 QAs 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.
See also: Pros and cons of Jest Snapshot tests
Why do YOU need a Quality Assurance Engineer?
As we’ve established before, QAs improve 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 QA engineer.
Quality Assurance engineers are 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. QA specialists offer 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 QA 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 QAs altogether, but when production defects will materialise (and trust me, they will), it will cost you waaay more than their help.
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 stations of QA teams 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. Hindsight is a blessing!
Every project in The Software House has a Quality Assurance engineer on board. The QA 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. QAs are constantly raising the quality bar for developers by establishing appropriate procedures. What’s more, we update and enrich the list of QA 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 the QA Team 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,
- 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 test automation,
- creating internal systems.
Busy bees, aren’t they? Now you can see how much work 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 it. Each part of the platform was created by a different person. If it wasn’t for a QA specialist 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 QA specialist 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, they 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 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 caught up the problems pretty early, so we were able to fix everything nice and clean.
Let’s try this again: do you need a Quality Assurance engineer in your project? YES, you do! Otherwise, you seriously put your entire project in a danger zone. So, if you’re looking for the highest quality, The Software House and our Quality Assurance engineers are waiting for you.