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.

Automation in each sprint (Scrum)

The question is should there be a separate product backlog item (PBI)/ User story for test automation in each sprint.

The answer to the above question is YES. There should be a separate PBI/ User story for test automation in each sprint.

In the first sprint when thinks are still evolving you may not want to have a PBI for test automation. But from sprint two you should have a separate PBI. I feel that there should be two PBI for test automation; one for the test automation of the current sprint items and one for the updates that you may have to do the old test scripts.

The time or the story points depends on the sprint velocity. Once the sprint is completed and the build is in QA; the automation scripts should be ready.

Prioritising the work (Stack ranking the work) is another very important task; first finish automating the current sprint items and then allocate the time to updates the old test scripts.

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.

Responsibilities of ScrumMaster

The ScrumMaster is a new management role introduced by Scrum. The ScrumMaster is responsible for the success of Scrum. Given that explanation, there really is no analog of the ScrumMaster in traditionally managed projects. Further, “The ScrumMaster is responsible for ensuring that Scrum values, practices and rules are enacted and enforced. The ScrumMaster is the driving force behind all of the Scrum practices.” Thus most of the ScrumMaster’s responsibilities fall entirely within the purview of Scrum itself.

The ScrumMaster facilitates communication between individual team members, between the team and the PO and the larger organization. The ScrumMaster is also responsible for advocating continuous improvement in quality and the process itself. The ScrumMaster makes the progress reporting mechanisms and metrics in Scrum visible and educates the PO (and the larger organization) in their meaning and use. In short, it is the responsibility of the ScrumMaster to create and foster the environment in which the PO and the Scrum Team can take charge of all the project management responsibilities they have in a Scrum context and discharge those responsibilities effectively and successfully.

It is important to note, however, that the ScrumMaster DOES NOT have any authority and IS NOT a manager of people or projects. The ScrumMaster doesn’t, for example, assign tasks to team members or monitor team member performance and the team doesn’t report to the ScrumMaster.

What Is Agile?

Agile methodology is an approach to project management, typically used in software development. It helps teams respond to the unpredictability of building software through incremental, iterative work cadences, known as sprints.

But before discussing agile methodologies further, it’s best to first turn to the methodology that inspired it: waterfall, or traditional sequential development.

Where Did Agile Come From?

In 1970, Dr. Winston Royce presented a paper entitled “Managing the Development of Large Software Systems,” which outlined his ideas on sequential development. In essence, his presentation asserted that a project could be developed much like an automobile on an assembly line, in which each piece is added in sequential phases. This means that every phase of the project must be completed before the next phase can begin. Thus, developers first gather all of a project’s requirements, then complete all of its architecture and design, then write all of the code, and so on. There is little, if any, communication between the specialized groups that complete each phase of work.

It’s easy to see how this development agile methodology is far from optimized. First of all, it assumes that every requirement of the project can be identified before any design or coding occurs. Put another way, do you think you could tell a team of developers everything that needed to be in a piece of software before it was up and running? Or would it be easier to describe your vision to the team if you could react to functional software? Many software developers have learned the answer to that question the hard way: At the end of a project, a team might have built the software it was asked to build, but, in the time it took to create, business realities have changed so dramatically that the product is irrelevant. In that scenario, a company has spent time and money to create software that no one wants. Couldn’t it have been possible to ensure the end product would still be relevant before it was actually finished?

Why Agile?

Agile development methodology attempts to provide many opportunities to assess the direction of a project throughout the development lifecycle. This is achieved through regular cadences of work, known as sprints or iterations, at the end of which teams must present a shippable increment of work. Thus by focusing on the repetition of abbreviated work cycles as well as the functional product they yield, agile methodology could be described as “iterative” and “incremental.” In waterfall, development teams only have one chance to get each aspect of a project right. In an agile paradigm, every aspect of development — requirements, design, etc. — is continually revisited throughout the lifecycle. When a team stops and re-evaluates the direction of a project every two weeks, there’s always time to steer it in another direction.

The results of this “inspect-and-adapt” approach to development greatly reduce both development costs and time to market. Because teams can gather requirements at the same time they’re gathering requirements, the phenomenon known as “analysis paralysis” can’t really impede a team from making progress. And because a team’s work cycle is limited to two weeks, it gives stakeholders recurring opportunities to calibrate releases for success in the real world. In essence, it could be said that the agile development methodology helps companies build the right product. Instead of committing to market a piece of software that hasn’t even been written yet, agile empowers teams to optimize their release as it’s developed, to be as competitive as possible in the marketplace. In the end, a development agile methodology that preserves a product’s critical market relevance and ensures a team’s work doesn’t wind up on a shelf, never released, is an attractive option for stakeholders and developers alike.