Selenium was originally developed in 2004 as an internal web application testing tool by ThoughtWorks. After its release as an open source software it became very popular, especially after Google adopted Selenium for their own tests.
Selenium comes in two flavors: Selenium 1 and Selenium 2 –also known as Web Driver. With Selenium Grid, it is even possible to run your tests in parallel. Services like Browser Stack offer tons of different browser versions for you to check every combination you can think of.
Selenium also supports all the major programming languages like Java, C#, Ruby, Python, and so on – no wonder it’s so popular in the developer community. Furthermore, everything is based on a unit test framework, so integrating it into your Continuous Integration Environment is quite easy.
You may be thinking that this sounds like praise for Selenium. As always however, there are two sides to the story.
Let me tell you a story:
We recently decided to help our customers who already have tests using Selenium. I asked one of our developers, Alice*, to look into it. She started by using the Selenium IDE (this is available as a Firefox Add-on) to get an idea of how it works. Using the export feature to create C# code, she was initially quite happy because she could code with it. However then the problems started – in order to get a couple of test cases running stable and predictable, she had to spend considerable time on implementing a (small) framework so that the test case behaved like defined – failing when they are supposed to fail.
Does this sound familiar?
Selenium is a fine tool as long as you can develop and have time to develop or use a framework which helps. In most cases, this only works during the actual project time, but it all ends after the website is released, the project is finished, and the team is either dismissed or starts work on the next big project.
As long as nothing changes, Selenium test cases will still run fine – however every update will threaten the existing test portfolio and will most likely break existing test cases.
Let me continue the story…
Alice finally managed to create a small test set (basically 2 tests) which I could use for demos. We decided to use our trusty insurance calculator webpage, assuming that it was stable. It turned out that this was only an illusion. Another team had changed some technical information – I believe they corrected a spelling error – and suddenly the same test cases which were running perfectly a day before were failing. I needed them desperately for a demo the following day, but I was unable to fix it myself – I wasn’t even sure what exactly had caused this.
You know what happened?
In the end I had to ask Alice. She had to stop her other projects and spent almost two hours working before it worked again. If it happens with this small application, it is sure to happen with a real web page. You need to code in order to maintain your tests, or worse, you might not even know what has changed so that your tests are no longer running.
What is the solution?
With the new feature “Integrate Selenium”, you will be able to run your tests using Tosca and add Selenium test results to your overall test reports. You can gradually start replacing these tests with Tosca X-Browser tests (by the way have you seen our cool new X-scan?) and thus gain control over your test portfolio.
You can combine these tests with any other test scenario. Perhaps you want to check if your web application stores the data correctly? Simply combine it with a set of web service tests to check the data consistency.
We are even planning on enhancing our support, perhaps even migrating them to Tosca automatically. But it also depends on you – please let us know if you like this feature and what you additionally need….
*Name changed by the editor
Want to know more?
Click HERE for more information on Tosca Testsuite’s Integrate Selenium solution.