QA may be interesting with some interesting technologies and some creativity

March 30th 2020

By Emrah Dautbegović, Test Automation Engineer at Klika


When I got the job of Test Automation Engineer, I was not as excited as I thought I will be. After some “by the way jobs”, University, internships, a lot of work and whatever, I got the real job, which I studied for and dreamed about. Everyone who wants to be a Software Developer thinks that QA is not so exciting and doesn’t even try to learn about it and to like it. I wanted to work and to learn whatever I’m able to and for me it didn’t matter if it was QA, Dev, DevOps or some other IT call. I just wanted to be an IT professional and to be better than the day before.


I’ve started learning about QA, TCMS, Xamarin Test Cloud, Calabash, Cucumber, Gherkin, Selenium, Appium, Xamarin.UITest, about Continuous Integration and other things that became my reality.


Before this job, I wasn’t a QA Engineer at all, and I didn’t know almost anything about it. Now, five months later, one thing I can tell for sure: QA is definitely not boring! If you think about twenty or more people working hard every day, you can assume what changes they can make. So, if you’re only trying to meet all the new changes, you won’t be bored. Every day is a new opportunity to be better as a member of such a great team. Whatever you’re trying to make, those people will help you and soon, you’ll be a better version of yourself if you are honest, hardworking and responsible.


I’ll try to describe how “QA can be fun and improved”, from my point of view, through several stages of continual improving.


  1. Manual testingUsually, there is some kind of Test Case Management Software (TCMS) as an ultimate center of all QA processes. That’s the place where all test cases and test suites are written and defined. It’s possible to add, update, and delete test cases and test suites.

Test case contains several steps and expected application behavior after every step. Test suite is a group of test cases which are connected somehow, for example, test cases for some Application’s feature (Shopping Cart test cases, Sign Up test cases, Admin Panel test cases etc.). It is also possible to add different configurations, for example, devices, browsers and operating system versions etc. Test plan should contain test suites and configurations. So, TCMS is place where we should define what should be tested and how. Also, you should know how to make API calls (Postman). Technically, this is almost all we need for the first stage of QA, manual testing. Also, we must know everything about the project or, at least, the functionality that we are testing.

When we are starting to test some functionality, we create test run of plan we created and after every single test is finished, we mark that test case as failed, passed, or conditionally passed. Initially, all test cases are marked as untested. This process is displayed on the following diagram:


Diagram 1: Manual testing and TCMS

This looks simple, and it is when you’re working on a small project, but when you have so many functionalities and accounts, dozens of different hardware configurations, believe me, it is far from simple.


2. Fifty-fifty – It can become boring and hard to “Sign up” and to run the same tests thousand of times and QA team can try to do some stuff automatically and create at least scripts for “Sign Up" and several automated tests and run them from personal computers  just to make their job easier with not much effort. If tests are against some Web Application, this is stage where they need to learn some JavaScript and at least one test automation framework. For Web applications, there are Selenium and RSpec, and for mobile applications there are Appium, Calabash, UITest and other test automation tools on disposal. I use Xamarin.UITest and Xamarin Test Cloud. UITest is based on NUnit and it is a cross platform testing tool for Android and iOS applications testing where tests are written in C# programming language. XTC is cloud based platform which contains hundreds of Android and iOS devices and you can run compatibility and integration tests on multiple devices there. So, in this stage, process is almost the same as in the first one. The only difference is that some tests you will not have to do manually and that is already an improvement, but still, you need to prepare data for tests, create report and mark tests cases as passed or failed etc.


3. Almost automated – It is possible to decrease manual work to minimum. Almost everything can be automated. QA Team can automatically: prepare data, run tests, create report, fulfill report with results from tests run, send report wherever they want to, clean data after test run is finished etc. It is really hard work to achieve all these steps, but it can be done. When all this work is done, the only thing that you need is to schedule it on some server and there you are.


4. Integration – After stage 3, everything looks perfect. There are situations when testing can be done on the Cloud or locally, results of tests are reported somewhere and everything is fine. But sometimes even all this work is not enough and there are some additional requests. For example, application can depend on some hardware, no matter which and it can be hard to establish stable communication between application and hardware, to predict behavior and to create automated tests for that. That is the pinnacle of fun!

Thanks for reading and I hope I got you more interested in the job of a Test Automation Engineer!


Popular posts

Cookies help us deliver our services. By using our services, you agree to our use of cookies.