By Justas Tamulionis, QA Automation Engineer at Kilo Health
Right away, I would like to ask you to spot a difference between these two values:
1.428234234995816237434112354534567 and 1.428234234995816237434112354524567
Mhm? Were you able to do so? Let’s just leave it for the user testing.
Please spare your keyboard or other surroundings and calm down! Kudos to those who used some sort of text/value comparison tool. That is partially what this task intended to show. Don’t leave, and I will explain why. Also – like, share, and subscribe.
Tasks and silly jokes aside, as you might have guessed, I will be talking about test automation. And, to be more specific, app automation. Hope none of you or your project manual QAs ever have to do this kind of task by hand. Seems like a waste of time when you can simply google “text comparison,” dump the values, and congrats – you just saved 10 minutes of painful manual value comparison.
For a business to succeed, it has to make a profit. And to make a profit, we need to spend time working on the idea. Aaand as all of you know:
time == money
Let me calculate some actual statistics for you:
Suppose your project QA spends around 3 hours on regression testing before each release.
On the other hand, covering the app regression suite with automated tests would roughly take around 25 hours. (These numbers may vary, depending on many things.)
Seems like a massive time difference, right?
Wait… I had to convince you that the automated part is better…
Let’s fast forward things 6 months into the future. You now have released the app every two weeks, or at least 12 times.
Now that’s what I like to see! Your manual QA spent 36 hours (12 releases x 3 hours) working strictly on the regression cases, doing the same thing repeatedly, ensuring that you haven’t broken the app with new releases (more about that later on).
While now, automated tests only took around 3 hours to run (12 releases x 15-minute run time) with precise robotic focus while your manual QA worked on your current burning ASAP tasks.
You have already seen that humans can’t be very accurate from my number comparison example. There are a lot of things we should just leave for the robots to do.
I won’t be giving you any more tasks to prove this concept – but it is one of the key automation benefits and has to be mentioned.
I am pretty sure that at least once in your lifetime, you have experienced a feeling when something that used to work all the time just stopped. It crashed or froze. Yeah, s**t happens.
Those things come in many forms and because of many reasons. But guess what?! App automation can catch it before you push it to production.
By now, you should be thinking, “Damn, the app automation seems pretty cool!”, “Why haven’t we done that sooner?”, “We need that in our project!”.
Let me tell you that, sadly, it might not be easy to do so in big companies…
Yeah great… So you just wrote about why the app automation is so fantastic and then ended with a sour note?
Wait, wait! There is still hope! I haven’t even told you why it is not so easy! I would love to keep the tension and say that you can find that out in my next post, but I’m not that evil. The key issue while implementing app automation is:
LACK OF SELECTORS / IDs IN THE APP CODE
To cover apps with tests, we somehow need to be able to access them through different app screens. We need to be able to click on different components. To scroll, to navigate… Long story short, we need to make a human-like robot that will be doing all those things for us.
We currently have an app automation engineer whose goal is to implement happy-path tests for all app regression suites. But there are more objectives for the future, and with a bigger team, we can code more detail-focused tests that would cover most of your repetitive task needs. There is practically no limit to what automation can accomplish.
There are plenty of benefits to why we should automate our apps. I have only mentioned three of them I personally think are the most important ones; the others are such as:
The list goes on.
The selector issue is currently being solved by a couple of teams already, and I am sure it will soon reach your team, too. To avoid this mess, teams should have good code practice and implement selectors straight from the app creation. Let’s keep moving forward where the sun shines and the gin and tonics are being mixed.
The APP automation department is also growing and is looking for new colleagues to join. So if you know someone, feel free to fill out the match form or contact the QA guild and let us know. (This is also true for the manual positions.)
One of the first experiences Romy Carlson had after she joined Kilo Health was flying out to Lithuania, going to the National Opera and Ballet Theater, and listening to an orchestra during an event presenting the future of health. While…
Hiring processes can be draining. With all the stressful stages, it feels like one big interrogation. As much as we love crime documentaries on Netflix, we try to take a different approach and make the experience as smooth as possible….
Kilo Health became Europe’s second fastest-growing company twice already. At first, Deloitte ranked us among the tech leaders in Central Europe, and then the Financial Times named us the runner-up in Europe. Growth is at our core, and we got…