Wednesday, August 10, 2011

Automating Web Applications - How I Got Started

I am in software QA stream. And an Open Source company whose main product was a web application. I was asked to write functional test automation for the web application as the company wants to push in that direction. At the time of the request, i.e. early in 2010, functional test automation was not a high priority, but completing manual testing on new releases had higher priority. Functional test automation was a slack time task, and I was new to the company and web applications.

I had hands on experience in working in a full fledged functional test automation project, trying to automate IBM DataStage using Rational Functional Tester. We were doing automation as per the three tiered architecture. Three tiered architecture separates, appobjects into one layer, tasks into another and test cases into another. Test cases call tasks, and tasks are achieved by manipulating appobjects. Check this link out for more details on the architecture. Though I find the concept not being very much object oriented, still that solution was a good one, scalable and maintainable. So, my whole experience was around IBM DataStage, which is a desktop application.

Now, in the new company, it was about web applications. It is not a web site, to emphasize, but a real desktop like web application. They had done some automation already, which was selenium IDE recordings. I was told that selenium scripts would fail sometimes without proper reasons. I was OK with it because that is something common to any automation suite. But, the degree of emphasize they put on that fact was quite puzzling, and then when I tried things out some other interesting facts also came along. One of the colleagues, who had contributed a lot to the scripts, told me that when the scripts are run in high speed, things often fail. So, running in a slower speed would make many of the test cases pass. I did some googling and could not find such an issue with Selenium. And the scripts did not have verifications built in. Renaming a single texbox in the application would necessitate updating so many places in the scripts.

Slowly the responsibility of automating the entire product came unto my head. My previous experience and expertise taught me that record and play back is not the solution. A definite NO to that direction. Then I had to do some research, to find out a better way to automate the application. The company was willing to invest in commercial products, even though open source technologies are preferred. But, If I pushed them towards big commercial products, I knew there would be too much expectation on me. And if I later find out that we are not going anywhere with that tool, that would impact my career negatively. I wanted to stick to Open Source solutions for so many reasons, including my love towards Open Source. And I am still glad, that I didn't go behind any commercial software.

My research suggested WebDriver would be the best. I started with that, but there were two main problems. I was just a QA guy with some programming knowlege, and WebDriver was just a jar file without any IDEs and frameworks to kickstart. There was no one in the QA team, who could guide me how to proceed in this direction. We had a development team, and I had a good relationship with them, but they don't have the slightest idea of how a functional testing framework would look like. So, I could not talk to them about my needs. As I had been in an IBM Rational Functional Tester project, I knew how a matured functional test project would look like. The pretty fancy test reports, the ant commands that would let us run the test suite with different configurations, the object mapper interface which would give us the properties of the components, and so many other stuff. You can check this link to have a smell of it. All of them are missing, and all I was left with was one lonely jar file and the task of automating the entire product.

My stubbornnes asked me to write all the verifications using if conditions, and some research pointed me that firebug could show me the properties of the components. The dear Eclipse IDE was already there. And I started writing the code for functional testing.

That's how my journey began. Read the next post to see how things moved on.




No comments: