We’ve written recently about how more and more Test Automation teams are climbing onto the Selenium wave. There is also a ready case for how well we play with Selenium – that being said a good story always has another angle right? A colleague was looking at some work we had done in the past on how testing teams can get a solid ROI from automating their testing and a pretty important point cropped up that bears being emphasized. To start this tale let us look at a test automation team that has already made the first right choice and picked Selenium as it’s weapon of choice. Let’s take a look at the route they would take first.
Selenium on their side
The first consideration for the “soon to be automated” team is the available resources and their skills levels. Do the development skills exist in-house – chances are you will need some Java experts and definitely need some expertise with the tool itself. If you do not have the skills in-house then get ready to hire them and / or train them.
Once the team is in place the next big decision is regarding the framework. This is shaping up to become an area that demands the maximum amount of attention. First up – what is the framework strategy? The framework is needed because the objective is to build a platform that allows ease of use, re-usability, easy reporting and so on. Automation teams have to build Object identification and Centralized object repositories as part of the framework given the lack of these within Selenium. Selenium’s relatively un-sophisticated reports mean that the team would be forced to develop better reports. A further element of complexity is introduced into the equation by the number of different framework approaches out there – data driven, keyword driven and hybrid among others. At this stage the most importance is given to coming up with a framework approach and design that is appropriate for your specific application, technology of choice and also the resource levels. After the framework strategy is decided the implementation / development of the chosen test automation framework starts.
Only after the framework is created is it then handed off to the test automation team for building the automation for the test cases. This is the fun part in many ways as it is when the testing team can start showing the results in terms of automating actual test cases.
There are some apparent challenges with the approach. For one it is clearly pretty resource intensive – quantity as well as quality of resources. Another issue is that in many cases the test automation team (should we call them the framework team given the balance of tasks?) are disconnected from the application under test or product roadmap. This leads to less than perfect knowledge of the product or app they have to test. As the product keeps evolving the framework has to keep evolving too leading to additional complications and wasted effort over the lifecycle of the product.
In our various interactions with test automation teams it is not unusual to find teams allocating as many as 3 months to get the framework ready. Remember that all the way till this stage no one has started automating anything – we are still only
laying the groundwork for the infrastructure on whose back everything will run. Is there a better way? The graph below shows the different stages of the process and the applicable time and resources at each stage.
With a little help from friends
Even the best tools can do with some help – let us look at how the story would have been different for this test automation team if they had used a combination of Selenium with Qualitia. The first point to make is that Qualitia brings in a ready recipe. This solution is tool, technology and application agnostic. Given that it is abstraction based it is not tightly coupled to any technology. It allows for selenium object identification so all the user has to do is point & click and the objects are stored by default in a centralized repository for all users to access. Detailed step-wise reporting is also built into the product. In essence the test automation team no longer has any need to invest time and money in developing the framework. Effectively they can start test automation from day one. The added benefit is since there is no framework to evolve as the product or application evolves – there is a saving of time and money over the continued life cycle of the product as well.
Now is that a good story or not?