“QA Engineer? Who’s that? Why do I need one? Oh, I can do it by myself”.
Excuse me, Sir, but you can’t. Have you ever heard phrases like:
- Car crash test? Oh, I’ll do it myself, that’s easy.
- Testing guitars? Guitars?! These are just sticks with strings, what can go wrong?
- Testing these batteries? Who’s ever done that?! — Okay, the last one goes to Samsung. They exploded the market last year, you know.
Quality assurance is more than just running an app on a device and saying that it works in the app development world. That’s something any of us can do, but it’s not about QA testing. Today I’d like to give an answer to the old question: what does a QA engineer do, what’s his role, mission, and responsibilities? Here we go!
The beginning
A customer usually comes with the basic idea of an app — it may be a messenger, a social network, etc. He may know basic functions and some innovative “killer” features, but there are still a lot of details and things to discuss.
Let’s say you want to create a messenger which, well, sends messages. What type of messages? Do you want private, public, group chats in your app? Encrypted ones? Voice messages? Calls or video calls like the ones on Viber or WhatsApp? It’s one of QA engineer responsibilities to ask those questions. They figure out all nuances of the future application, like the type of registration, payment systems needed, type of contact list and whatever else the customer wants to see. Project managers aren’t technically qualified enough to do it, that’s why you need QA engineers to gather all these details and write them down in the documentation which will be discussed later. There’s only the idea of an app at this stage and the more details the team will know, the better result the customer will get.
Creating user stories and documentation
Then we create user stories.
QA’s goal here is to check the conformity of customer’s dreams and ideas with their possible realization and to set terms that will be clear to every team member. QA engineers also help to make customer requirements clear for developers by interpreting them into user stories, which have to be performable. After user story is created, QA can set its severity, so the team can see that any changes in that part of an application can heavily change or affect other parts in some way. They save developer’s time by doing that.
QA engineers begin to write documentation at this point, which is a little different from a classic brochure with notes like “do not put in water” and “not for kids”. It’s more like the encyclopedia with a collection of knowledge, rules and ideas of the current project. Documentation will be more detailed if there are more specialists working on it. Its size may vary from a simple checklist to a pack of test suites with dozens of test cases.
You also can use it as FAQ which will make it easier to add new team members. The test case is like a screenplay of an app. It has the list of all functions and the way they should work. So all the answers your team could look for are already written down. This also saves a bunch of time and give a better knowledge of the project to the team. Saving time is important because startups are competitive. While you are having your ideas in your head, they may already have been implemented in someone else’s products, that’s how the market works. Having QA on board will boost the development process and make your project progress faster than anyone else’s.
Let’s talk about types of QA testing we provide.
Functional tests are basically an imitation of user’s activity in the system. It’s the best way to prevent disappointment of users after they meet unexpected errors and not making the job harder for your team.
Does the final product meet customer’s requirements? That’s up to QA to figure it out and write the results down in the documentation. Even if you are sure of your code, only a functional test will show if your app works correctly.
Another type is regression testing. A developer can miss the aftermath of changes in the code he adds. Fixing one bug can create another one and adding new features can break the ones that already exist.
That’s why regression testing is needed from time to time. It allows you to make sure that old features perform correctly after new changes. It’s really important for huge apps with tangled or unobvious connections between its parts. It also saves time, because everyone is doing their job: developers are developing and quality engineers are checking quality. Just how it should be.
Then QA engineers write bug reports — the list of the things that went wrong. Bug reports allow you to locate broken parts. A developer will get a full description of a glitch which contains the following:
- Location of a bug;
- What steps should be taken to reproduce the bug;
- Results of the error;
- Estimated results after fixing the error;
- How critical this error to the whole application is.
It’s not alright if app logo moved a couple pixels to the right, but it’s much worse if a user can’t log in or user data can be lost because of the bug.
QA engineers set Acceptance criteria. If user story meets the criteria, you can mark it as “completed”. It helps developers to see their task clearly and fully understand what they need to do and what kind of result is expected. It also allows them to see the severity of user story. If the task is difficult and any changes can affect the whole app, it’ll go to trained and experienced team members and vice versa.
So, to sum up, QA engineer is a really important team member. While developers build a car, QA team will make sure that not only the final product — that every detail the team produces works correctly. With such an attitude you truly can bring your dream to life without year-lasting struggle with errors, wondering where and when things went wrong.
Thanks so much for reading and subscribe to Anadea blog for more IT-related articles.
Originally published on the Anadea blog: QA Engineers: What Are They Doing?
