Selenium the Agile automation testing tool

Test automation is usually lagging behind development of new functionality. The tools that are used to automate are dependent on the UI and this causes automation of the functionality to start only after the environment and the UI are stable.

Selenium is the test automation tool that helps test below the UI layer. The automation can be done earlier even before the UI is completely ready or matured.

Selenium is language independent and this makes to unique as testers/ developers can start coding as they code the application. You can code the Selenium automation scripts in PHP, Java, C#, Ruby, Python. Selenium uses locator – an element locator on a webpage to identify the element on the webpage.

Ideally its good to code the test scripts in the language the web application is built; by doing so you can integrate the test scripts in your nightly build and help speed up the QA process.

If you found this solution helpful or have something extra to add, feel free to share it here by commenting below.

Selenium in Scrum

Automation is an integral part of a scrum development environment. Selenium is an automation tool that can be used to test the functionality in a web based project.

The automation scripts should be coded based on the manual test cases. They should be modularised. The code should be reusable and it’s a good practice to write small functions to test each requirement.

In a scrum environment the requirement is broken into Product backlog items (PBI) or User stories. When automating the test script should be able to test each PBI or user story or even the individual tasks in the PBI.

In some cases it will be difficult to test individual tasks or PBI’s; in such cases group them based on the functionality.

The advantage of breaking the test scripts into functions is that you can make changes to the functions when there is changes to the requirement that affect the test script or any enhancements to the functionality.

I have seen that when you write a test script in sprint 2 and if there are changes/ enhancements to the functionality of xpaths (element locators) in sprint 4; it will become easy to change a test scripts when you write them as small functions and not a one single test script to test all the functionality on a web page or functional module.

The automated test scripts can be used by the developers to test if the functionality they have changed does not affect the other functional areas.

If you found this solution helpful or have something extra to add, feel free to share it here by commenting below.