Imagine you were chosen to join a project which is very mature and full of senior developers. You’ve heard that your company is proud of it. You are well informed that this client is a valuable asset. You’ve heard that this is a great privilege.
You are a lucky boy, my dear!
Except for one thing…
Everything is sunshine and rainbows 🌞🌈 until you discover that those three years were based only on exploratory testing. What’s even worse, is that they were done by a client who has no tech background. Developers have no idea what proper testing is, and everything is a black-box mess based on good will and luck.
Someone lied to you! Not the first time, not the last time… So, what would you do if you were in such a position and you wanted to show some testing magic? 💫
We could start by introducing some automation! Besides, so far, each build and testing phase is so random and long that the results are almost useless. But that’s not a problem as nobody uses them anyway.
Fast thinking and a fast google search propose the following combo for a test automation environment: Appium + Robot Framework + CI which sounds like a neat idea. Especially when you calculate the ratio of: time/visible results.
While downloading the software, you’ll need to prepare three things: Coverage matrix, environment and patience. The last item you will need for downloading. Especially Android Studio. That’s a heavy champion! Anyway, let’s focus our energy on the coverage matrix.
You know the drill, but let me refresh your memory if you forgot. You write down every single feature that exists in this project in a sweet, excel table. If a user can clicks, moves, switches or uses something, then this is a feature that can do something. Now, I know that you might feel intimidated by the scope and size of this task – but don’t worry! Create a beautiful tree! Let your inside kid out! 🙃
Feature > subfeature > sub-subfeature > … – the more the merrier. At some point, you will have an idea on how many different stories you will need to create. You can now show developers that this one strange, unpopular feature they forgot 30 commits ago, used only once in a blue moon, might be actually clicked 😲 You have clear steps and that’s what counts most.
Once this is done you can start preparing a proper test automation environment! Oh yes! Proper environment tastes like a healthy breakfast for every tester that wishes to achieve stars ✨ Let’s check the list – Appium for mobile testing, Robot Framework to have a framework, Git for commits, Android Studio for emulators, Jenkins for CI magic, Gradle to build the app. Yup, we are good to go!
We have limited space here so I will not change this article into a step by step tutorial, but rather give you some useful tips.
- Prepare tests in the easiest to read form. They will be checked by developers or someone else.
- Use the same titles and areas as you used in the coverage matrix. Don’t reinvent the wheel and be consistent with the naming convention.
- Speaking of which – Try to separate everything to absolute maximum. Clean, small, atomic test suits are our best friends. Not to mention it will be way easier to change one thing rather than copy and paste the same line over and over and over again.
From here life is quite simple – developers do their job, you do your job. You cover stories and each of you commit via git changes. I hope you didn’t think to store it locally on your hard drive, did you? 🤔
Every now and then, will come a moment in which both developers and testers will decide “it’s that time of the year”. Developers will trigger an app build and you will trigger the test project. All with clean tags you consulted and agreed with the whole team. From here, Jenkins will take care of your little baby. It will load the app to the cloud, trigger test execution and merge test results. Everything will be done in a clean, separate environment, far, far away from those pesky developers 😉
As a result you will be handled with a simple binary decision – Either your tests passed and can go with the flow, or your tests failed and the version will not be approved. In any case, there will be quite a lot of questions regarding debugging, updating and maintaining test cases. There will be also some questions about summary report which will be sent to the manager. From now on life can only get easier!
I know you might be thinking that in the first place we should introduce something else or in a different way. But let me stop here for a moment and explain my thinking process.
Our client and the whole team have no idea how to test, right? We want to introduce something that is easy, simple, fast, reliable and understandable for anyone who has never written a single line of code, right? We want the process to be shortened from one week of feedback to a matter of minutes, right?
Well, this is the best solution there can be (Unless you have money for a pricier option, though they are not always better). But in a normal scenario, such an environment can save our time tremendously. We can lose less time on reproduction of steps and root cause analysis, and spend more on project related tasks. Dev-tests can take more of our project time and context switching can be eliminated or even killed!
Sounds too good to be true but that’s actually how it works. I’ve been there, I’ve tested this and I can guarantee this will work like a charm. By the way, you can get some bonus points if you introduce a testing calendar in which you will mark how often and what products are covered with each test! Clients ❤ such solutions.
Anyway, the above scenario has also another great treat – it is a heavily documented, stable solution. You can prepare this environment anywhere and it will still work. Yeah, the process is a little dirty as it requires you to spend time on checking backward compatibility and installing everything by hand. But hey! On the other hand, you can tweak almost any parameter, you can trigger this CI easily and you can integrate this even further with espresso, XC test or any development tool you wish. Oh, and you can also see the effect in a relatively short period of time.
This would be a good time to mention that there are also other great open source and free automation platforms that can simplify this entire process as a whole test automation environment, and reduce the entire “dirty” initial setup time even further. One of them would be TestProject. Based on my experience with that platform, I can safely say that it can save A TON of precious time 💪
Look, there are no perfect answers but if you can have an elastic solution that can be supported by any language you want, with any add-on you wish, working on any OS and which is also fast, well-optimized and light for your system and servers, then I think we have a winner! 🥇
If you wish to meet the demands of a rapid release of high-quality applications, then this is a good starting point. No matter if you are a pro or a junior. Both of you will appreciate the beauty of this suggestion and solution. Trust me on this one.