This article is the 1st in the series of articles titled ‘Switching from Manual to Automation…The back-story!’
Do you ever wonder how different things would be if we never came up with the idea of automation testing? So many apps on your smartphone would never have seen the light of day and would still be resting somewhere in their respective office PCs as a trivial piece of code.
I am here to take you on a journey of how testing decisions are made for real-time products, the challenges encountered and conquered on the way, the complete testing process details, statistics and much more.
To start, let me give you the familiar introduction of testing, share a few insights on the significance of automation and invalidate a few myths surrounding automation testing.
As the adage goes that ‘necessity gives rise to invention’, the introduction of testing would be incomplete without discussing the problem.
As soon as a business deal is finalized, the concerned organization starts preparing to deliver a high quality and reliable product to the end-user market. With the competition escalating all around, organizations are in the run to deliver a quality product in limited time with limited resources. This is when the organizations realize that manual efforts in testing might not size up to delivering the expected results. And that’s how ‘automation’ enters the picture in the testing world. But the problem doesn’t end here, there’s a lot to be discussed and decided before selecting the right test automation strategy for the product.
As you ponder over this question, let me present to you my version of the answer.
I shall try to express my views by giving a gist of my experience with my current project. I am currently working on an Android-based project which is not like any regular Android application. Our team started off with understanding the requirements and creating the test cases. After some 50-60 test cases, we stopped to cover the basic sanity testing.
We had to start with manual testing. It covered all the test cases, analyzing the logs, logging the defects and creating test reports. This process was repeated with daily build releases. We also started creating more test cases for more feature coverage and the test case count was increasing rapidly and reached 200-250.
There came a point when we couldn’t complete all the test cases before the assigned deadline. Preparing test reports got delayed. Defect logging also took time even though we were using a tracking tool since there was a need to log the steps to reproduce, take screenshots and recordings in case of weird bugs.
Another huge task was retesting the complete feature to validate fixed defects and new bugs that might be introduced by the fix. We also started testing the same test cases on different environments and configurations just to find a couple of bugs at the cost of a complete test cycle. A few test cases needed minimal interactions but took hours to execute as they included downloading, uploading and a few setups for updates too.
This is when we began to talk about automation. Even though our chats on automation started on a non-serious note and were rather treated as a joke, each of us guarded some serious thoughts on automation in our minds. Finally, when we were already done with days of extended work hours and delayed test reports, we took cognizance of the fact that it was time to embrace automation in our testing!
As I have previously mentioned, our project was unlike any regular Android project you are aware of. Thus, we were skeptical of how successfully automation would work considering the atypical project requirements.
Nonetheless, we pushed ourselves.
We started searching for solutions, tools and frameworks. We looked through blogs, articles, and went through lengthy white papers only to find regular setup documents and theoretical tutorials. Finally, when we had already saturated the online research, we tried to think on our own without any influence of Google searches. We came up with a few ideas, documented them, plotted the ideas and somehow were able to decide the framework and start with the selected tools and approach.
Our first preference was to go with the open source tools. Thus, we chose Appium, selenium web driver and modular test framework.
Though you might feel that the aforementioned tools are supposed to be the immediate choices of any test automation developer, we had to be more anticipatory because of the product we are dealing with.
And then comes the real problem!
Appium takes a single apk/package, which is something we all are aware of. It creates a session enabling us to interact with the device. But as has been reiterated above, our product was unusual!
It included an assembly of apks/packages and services fused together and flashed to the hardware.
And thus, follows a series of questions…
How should we handle them?
What will be the best strategy?
What kind of framework should we use?
Are there any tools specifically designed for such products?
Well, we did find something….
By the time next article of the series comes up, I would love to know your thoughts on the need and significance of test automation…
Stay tuned… to be continued in the next article!
If you’d like to find out more about PathPartner and our expertise with respect to the complete product life-cycle, write to us at firstname.lastname@example.org Or if you’d prefer, why not arrange a call with us?