Why to Automate Software Testing

Here are some key reasons why we need to automate software testing:
Reusing the test scripts: When you want to execute the regression test scripts after every build it makes more sense to automate them. In case of testing web based application there is a more need to automate as the test suite has to be run on verious browsers like Internet Explorer, Firefox and other browsers.
It saves time: Running unattended automated test scripts saves human time as well as machine time than executing scripts manually
Better use of resource: While automated scripts are running unattended on machines, testers can do more useful tasks
Cost Saving: On test engagements requiring a lot of regression testing, usage of automated testing reduces the people count and time requirement to complete the engagement and helps reduce the costs

Reasons to automate the regression test suite

There are four reasons why you should automate the regression test suite
1. It increases the amount of time testers have to test new functionality. (That’s manual exploratory testing. Which requires intelligence, creativity and adaptability. Which requires a human being.)
2. It increases the level of confidence in the regression test results (Let’s be honest, humans are poor regression testers. Checking the same thing over and over is tedious. Unlike computers, we get bored, we get distracted, we don’t notice regressions slipping past.)
3. Once automated you can run them any time you want (No more worries resourcing regression testing, just press “start”.)
4. It increases testers job satisfaction – less context switching, no repetitive testing, more time to find bugs, greater use of mental abilities.


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.

What is Scrum?

Scrum is an agile project management approach that combines an empirical process model with clearly defined roles for the management and execution of that process. Within the Scrum framework, there are three roles: The Product Owner, the ScrumMaster, and the Team.

Work is performed iteratively and incrementally within repeatable 30-day work cadences known as “Sprints.” This process is managed through three primary meetings: Sprint Planning, which occurs at the beginning of the cycle and determines which work the Team will tackle; Daily Standups, which bring Team members together for a few minutes each day during the Sprint to communicate progress and dependencies; and Sprint Review, which occurs at the end of the cycle and is used to assess whether Sprint goals have been met. Finally, the process is managed through a handful of planning and progress artifacts, including “backlogs” (for planning) and “burndowns” (for reporting).