Agile and Scrum

Agile testing is dynamic approach for testing. In this testing requirement does not stable mean to say it keeps change according to customer so in this situation we need to use dynamic approach for testing and this approach called Agile testing. These days almost companies are using agile testing

Or

A software testing practice that follows the principles of agile software development is called Agile Testing. Agile is an iterative development methodology, where requirements evolve through collaboration between the customer and self-organizing teams and agile aligns development with customer needs.

 

Need of Agile

In waterfall and V models, it is no easy to manage the frequent changing in functionality and requirements. To short out this issue Agile mythology came into the picture. Agile methodology provides a process through which, we can manage the requirement changes easy. Agile testing is used whenever customer requirements are changing dynamically, or the high level documents, related to requirements are not available.

Features of Agile methods

1.      Iterative development – Tested features developed in order of business priority.

2.      Responsive to changing requirement – Many opportunities to re priorities and re-evaluate.

3.      Product owner (client) is the part of the team.

4.      Focus on delivering business values.

5.      Test driven.

6.      The team review and improve their own processes regularly

 

Advantages of Agile Testing

• Agile Testing Saves Time and Money
• Less Documentation
• Regular feedback from the end user
• Daily meetings can help to determine the issues well in advance

 

Principles of Agile Testing(Culture 1)

Testing is NOT a Phase: Agile team tests continuously and continuous testing is the only way to ensure continuous progress.

Testing Moves the project Forward: When following conventional methods, testing is considered as quality gate but agile testing provide feedback on an ongoing basis and the product meets the business demands.

Everyone Tests: In conventional SDLC, only test team tests while in agile including developers and BA's test the application.

Shortening Feedback Response Time: In conventional SDLC, only during the acceptance testing, the Business team will get to know the product development, while in agile for each and every iteration, they are involved and continuous feedback shortens the feedback response time and cost involved in fixing is also less.

Clean Code: Raised defects are fixed within the same iteration and thereby keeping the code clean.

Reduce Test Documentation: Instead of very lengthy documentation, agile testers use reusable checklist, focus on the essence of the test rather than the incidental details.

Test Driven: In conventional methods, testing

 

Principles of Agile Testing (Culture 2)

• Satisfy the customer through early and continuous delivery of valuable software.

• Working software is the primary measure of progress.

• Deliver working software frequently, from a couple of weeks to a couple of months.

• Welcome changing requirements, even late in development.

• The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

• Business people and developers must work together daily throughout the project.

• Simplicity--the art of maximizing the amount of work not done--is essential.

Role of Team Members in Agile method

• Customer (Product Owner):  The person responsible for defining Requirements (Product Backlog items) and prioritizing items for each Iteration / Sprint.

• Coach (scrum Master): The person whose primary role is to remove impediments blocking the team.

• Team of Developer and Tester: Collaborating to produce running, tested features. 

 

Agile Development Methodology

Agile is a iterative development methodology, where requirements evolve through collaboration between customer and self-organization team Agile business approach aligns development with customer needs.

Agile Testing Process

Value of Testing in agile development

• Testing in agile software development should provide the information that stakeholders need to make decisions and steer the development into the right direction        

• This information must be provided promptly

• Testing provides data on the status of the deliverables and generates project intelligence

• Project intelligence is knowledge of risks and benefits

• Knowledge of risks, benefits, test records and results are more valuable than test documentation and infrastructure

Best Practices in Agile Testing

1. Automated Unit Tests

2. Test Driven Development

3. Automated Regression Tests

4. Exploratory Testing 

Tester – Developer cooperation 

In Waterfall Model

1. Different Team.

2. Mostly communication only by management tools.

3. Different Aims

4. Not involve in requirement analysis and planning.

5. Time delay between coding and testing.

 

In Agile Model

1. One project team.
2. Close communication with team.
3. The same aim.
4. Together analyze requirement and plan.
5. Parallel with developer.  

 

Scrum

Scrum is a lightweight agile project management framework mainly used for software development. It describes an iterative and incremental approach for project work.

Overview of Scrum Framework

Scrum can be used in all kinds of software development: for developing complete software packages, for developing only some parts of bigger systems, for customer or internal projects.

The Scrum Framework implements the cornerstones defined by the agile manifesto:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

The Scrum Framework itself is very simple. It defines only some general guidelines with only a few rules, roles, artifacts and events. Nevertheless each of these components is important, serves a specific purpose and is essential for a successful usage of the framework.

The main components of Scrum Framework are:

• The three roles: Scrum Master, Scrum Product Owner and the Scrum Team
• A prioritized Backlog containing the end user requirements
• Sprints
• Scrum Events: Sprint Planning Meeting (WHAT-Meeting, HOW-Meeting), Daily Scrum Meeting, Sprint Review Meeting, Sprint Retrospective Meeting

Important in all Scrum projects are self-organization and communication within the team. There is no longer a project manager in a classical sense. In the Scrum Framework the Scrum Master and the Scrum Product Owner share his responsibilities. However, in the end the team decides what and how much they can do in a given project iteration (Sprint).

Another central aspect within the Scrum Framework is continuous improvement: inspect & adapt. The Scrum Teams have to frequently inspect and assess their created artifacts and processes in order to adapt and optimize them. In the midterm this will optimize the results, increases predictably and therefore minimize overall project risk.

The Scrum Framework tries to deal with the fact that the requirements are likely to change quickly or are not completely known at the start of the project. The low-level requirements are only defined at the time when they are going to be really implemented. In Scrum, changes and optimizations of product, requirements and processes are an integral part of the whole engineering cycle.

Another cornerstone of the Scrum Framework is communication. The Scrum Product Owner works closely with the Scrum Team to identify and prioritize functionality. This functionality is written down in user stories and stored in a Scrum Product Backlog. The Product Backlog consists everything that needs to be done in order to successfully deliver a working software system.

The Scrum Team is empowered to only select the user stories they are sure they can finish within the 2-4 weeks of Sprints. As the Scrum Team is allowed to commit their own goals they will be more motivated and work with best possible performance. The Scrum Master is another important role in the Scrum Framework as it works as a servant-master with the Scrum Team. His/her main tasks are to make the Scrum team understand how Scrum operates, to protect the Scrum Team from external interruptions and to remove impediments that hinder the Scrum Team to reach its maximum productivity.

The Scrum Framework in its simple form is best used for smaller, one-team projects. But with the introduction of additional roles like the "Chief Scrum Product Owner" it is also usable in bigger multi-teams and/or distributed-team projects.

 

 

Introduction To Scrum - A Real World Example

Before starting the first Sprint
Alex is assigned as the Scrum Product Owner of a new software development project. One of his first tasks is to start requirement engineering. He writes down the most important use-cases and discusses them with the architects, customer representatives and other stakeholders. After collecting the high-level use-cases and requirements, he writes them into the Scrum Product Backlog and initiates an estimation and prioritization session with the architects and some senior developers. As a result of this session all the items in the Scrum Product Backlog have an initial rough estimation and a prioritization. Now he starts to break-down the high-level requirements into smaller-grained user stories. With this list he then calls for the first Sprint Planning meeting.

Introduction to Scrum – A Real World Example across various Scrum Phases and Sprints

Sprint 1 - Day 0
During the Sprint Planning meeting Alex presents the Scrum Product Backlog items from the highest priority to the lowest. The team clarifies open questions and for each item the team discusses if they have enough capacity, the required know-how and if everything else needed is available. After this discussion they commit to complete the stories 1,2,3,6,7 and 8 until the end of this sprint. The items 4 and 5 cannot be realized in this sprint, as some technical infrastructure is not yet in place.

After the Sprint Planning meeting Frank - the Scrum Master of the team - calls the team to define the details of how the committed items are going to be implemented. The resulting tasks are written down on the cards at the prepared Sprint Task board. Now everyone of the Scrum Team selects a task to work on.

Sprint 1 - Day 1
In the morning the whole team gets together for their Daily Scrum Meeting. Everyone gives a short statement what has been achieved so far, updates the estimation of remaining hours on the cards of the Sprint Task board, tells what he or she is planning to do today and tells if there are any impediments that hinders him to continue his work. Today one of the team members tells that he has problems because he needs a new license for one of the software tools he is using. Frank checks if other team members have the same problem and says that he'll take care of that after the meeting. After 15 minutes everyone goes back to work.

After the meeting Frank updates the Sprint Burndown. Then he calls the software vendor of the tool, orders licenses and forwards them to the people that need them.

Sprint 1 - Day 2
In the morning again the whole team gets together for their Daily Scrum meeting. In the afternoon one of the Scrum team members is unsure about the details of one of the user stories. He calls Alex –Scrum Product Owner- and discusses the open points with him. After the team member finds out what to do, then he can continue with his implementation.

Sprint 1 - Day 28
This is the final day of the first Sprint and Frank –Scrum Master- has invited the team for the Sprint Review Meeting. The team has prepared a machine with the current software implementation. Alex –Scrum Product Owner- sits in front of the machine and checks if the implementation meets his expectations and if the features are documented as required. At the end of the Review Session he concludes:

• Stories 1,2,6 and 7 are finished as expected.
• Story 3 couldn't be finished in time and was not presented at all.
• Story 8 has some points that have to be re-factoring.

In the afternoon the team gets together for the Sprint Retrospective Meeting and discusses what went well during the sprint and what could be improved. One of the feedback is that the team has the feeling that they do not know enough about the overall system architecture. Frank takes the task to invite the system architect to give a more detailed introduction.

Sprint 2 - Day 1
Alex –Scrum Product Owner- adds new items to the Scrum Product Backlog based on his recent customer meetings. Moreover, he adds additional items for the re-factoring of story 8. Alex then invites the team for the Sprint Planning Meeting for Sprint 2. The team discusses and commits to stories with the guidance of Frank –Scrum Master- and the second Sprint begins.