Recently I was challenged by a client to test a new web application in an Agile project. The team was new at working Agile and even more with working together with a functional tester, altogether this resulted in me getting very little development support from the team.
Because the lack of tooling and support I focussed my efforts on just recording test-scripts using Selenium IDE, hoping I would be able to reuse them once I got the development support I had been requesting. The plan was to integrate the pre-recorded scripts in a more extended test environment in a later stage of the project.

After having studied what my options were for successfully automating the test environment, I formulated a strategy to undertake this. Being used to having a powerful framework like Fitnesse, with Selenium IDE I missed about all the functionality to operate on the domain of the application itself. Such as test preparations steps, database access and calls directly to server processes. Besides using Selenium IDE by itself simply does not support the use of any other browser besides Firefox and the customer expected the application to be running on any browser and explicitly requested it to be tested on at least IE6/7, Firefox and Safari.

Quite a lot of blogs can be found on the net on how to integrate Fitnesse with Selenium. There is even the webtest fixture in Fitnesse that sets the basis for this integration.  All that is necessary is a fixture that is capable of calling Selenium and the pre-recorded Selenium scripts would have to be converted in a format that Fitnesse can understand. Fitnesse would than call Selenium RC enabling the browser support that was necessary for the job.

When a Xebia colleague joined the project things sped up and I got my implementation. It took him little time to write the fixtures I needed. In our experiment we found that in order for Fitnesse to work with selenium scripts, just a very simple driver could do the trick, the most important part was the ability for Fitnesse to understand the different Selenium commands. Fitnesse version 3.x contains a script fixture that makes it very simple to create a logical script in a readable way, that could also be based upon the pre-recorded Selenium scripts. A groovy script did the translation, the makeup of the script needed just minor adjustments to conform with the Wiki table and some basic commands that are used in Selenium IDE differ from what Selenium RC uses, so these needed translating.

That pretty much does the trick!

When I actually started using it I ran into some odd problems. For instance, when you try to test across domain borders, from our website to another and back (in our case this was a internet payment provider), Selenium RC just stopped with some unclear error, while IDE had worked perfectly fine. Again my colleague came to the rescue. At home he did some investigating and got the thing working. We just need to set the -proxyInjectionMode as we where working behind a proxy at the customer site.
Yet again this did not solve the problem entirely, Selenium ended in a strange session exception. Whenever Selenium crossed the domain it would start a new session, loosing the proxy settings of the original browser session. Now this problem was a bit more tricky, after doing extensive research we found that every-time firefox started a new session it did it from blank profile, causing our proxy settings to be lost. Turned out the guys from Selenium already implemented the solution to this problem, we just had to point it to the correct Firefox profile template using the -firefoxProfileTemplate parameter.

So the final startup command turned out to be something like:
java -jar selenium-server.jar   -firefoxProfileTemplate /Users/cirilowortel/Library/Application\ Support/Firefox -proxyInjectionMode’

Tags: Agile, fitnesse, Scrum, Selenium, Testing
Filed under Agile, Quality Assurance, Testing | 6 Comments »