Of course, sometimes all you need to do to discover issues is just click your way through the app (professionally called exploratory testing). But real quality can be achieved only by implementing several testing methods, a systematic approach combining know how and experience, caution, and by just doing a good job overall.

The general public takes for granted that the app will run flawlessly so we can’t expect them to understand the Software Tester role. Unfortunately, apps are not created without any flaws. The QA team is responsible for the final outcome even though they might not realize it.

SKODA OneApp, the winner of the IT Project of 2017 competition

What does QA mean to us? We want the app to be perfect and to offer a real added value to its users, for them to truly love the app. So the app’s overall functionality is very important. In other words, the app should be doing what it’s supposed to do. And it needs to do it seamlessly. We also focus on details, like elements displaced by one pixel, colours being a slightly different shade than designed, and other little things.

We commence testing in the early stages of a project here at eMan. The Tester assigned to the project is an important member of the team. He needs to know and understand the whole project very well. This is usually ensured by studying various specifications of the project (wire-frames, graphic designs, intended functionality, use cases and even some UML diagrams). We can identify the first few errors/mistakes/bugs just by understanding the specifications, which can save many wasted hours in the following stages of development.

It’s useful to consider the whole system and note down the individual test cases (TCs) before we start the actual testing. The focus of the TCs depends on the size of the project, but it’s always important to cover the basic SW functions and various edge cases, in case a backup needs to step in for you or to quickly get a new team member up to speed. As mentioned, we spend most of our time doing exploratory testing but it’s important to remember to create the TCs even if they’re to be used only for user testing.

If suitable for a given project, we take into account a long-term development or frequent updates of the app – frequent sanity, smoke and regression tests – we redesign the TCs suitable for manual testing to automated testing (the Android, API and web testing is happening at the moment). All three mentioned areas are integrated in our GitLab.

• Android: Android Studio, Java, and Kotlin
• API: The individual tests are designed in Ruby and we work on our own testing interface that’ll suit our needs
• WEB: Selenium + Capybara and Ruby

 
The actual testing starts in the following stage. Of course, it’s not as easy as it sounds but you get the idea. We test the app manually as well as by using automated tests. Since the automated tests are not very good at identifying new issues from a long-term perspective, we also implement exploratory testing. That’s the most interesting part of the whole testing process and it usually reveals the most issues (unless you use the automated tests for 100% of the app’s testing). When doing exploratory testing, the tester has to think about all possibilities and test them out because it might have happened that not all changes were put into the TCs, even if only due to changes in the specifications. Sometimes, you can’t test everything in the app. In such cases you have to think carefully about the possible worst case scenarios and thoroughly test these.

Our QA Tester Martin Matuna is testing a new app

If you identify an issue (defect, malfunction, it differs on a case to case basis), it needs to be thoroughly analysed and noted in Redmine, Jira or even in GitLab. The means of reporting depends on the project and client. We have templates for TCs as well as for defects that we are developing and improving over time and that reflect our long experience. We want the whole QA to have as detailed a test report as possible and to make the involvement of the other teams as easy as we can. Another important factor to consider when reporting issues is their severity. Obviously, an error that occurs on one phone out of a thousand is flagged with lover priority than a severe safety issue when logging in using a password.

Of course we have to deal with the reported issues, performing a new set of tests among other things. The tests are performed in cycles during development, so the process is repeated several times. The work is not over even after the app is released. You have to do customer care, manage, and fix any possible issues from production because the testing won’t always find all possible malfunctions and thus some issues might slip through all the way to the client.

Device room at eMan

How did the work in the QA Team influence its members?

We’re all influenced by our work to a certain degree. We succumb to a certain “professional deformation”. Here are a few examples of tasks that the members of our QA Team try in real life:

• withdraw 0 CZK from the ATM
• using a different RFID/NFC chip when paying by card to see what happens
• selecting the floor we are on when entering the elevator
• scanning QR codes when doing self-checkout and, when asked, entering “0” amount of bananas for checkout
• when riding the metro, pressing the door button after the voice reports the next station to see if the door opens again

 
In short, we try to “break” everything and see how a given system reacts. And it’s very nice to see when nothing happens and things still work as intended. 😉
 

Who’s a good fit for eMan’s QA Team?

The perfect member of our team wants the client to get a flawless product. He or she takes interest and is inquisitive, these are essential qualities. Sometimes, they want to break everything, mainly by trying unusual settings and situations. Because not all bugs can be identified by simply looking at the app. And the perfect member is also able to judge the severity of the identified issues. They enjoy seeing things all the way through and even further. The bug report doesn’t end when it’s reported to the developer.
 

What are the advantages of being part of eMan’s QA Team?

Up to 70% of your work-time is up to you and can be arranged as you see fit. Nobody plans your day for you, nobody tells you what to do tomorrow before lunch. And your work is seen, the final solutions are used by millions of people. You also get regular feedback from your colleagues and there’s a weekly meeting with your Team Lead where you can discuss whatever you feel like.

You don’t get bored; you work with others on large, diverse projects. And the sky’s the limit. You’re supported by senior members in your professional development and you quickly get more and more responsibility.
 

Would you like to be a part of eMan’s QA Team?

We’re hiring Testers! Find out if it’s the perfect job for you. Not that interested in testing? Have a look at all our job offers.