Click here to Skip to main content
Click here to Skip to main content

Agile Testing, Scrum, and eXtreme Programming

, 22 Feb 2013 CPOL
Rate this:
Please Sign up or sign in to vote.
An agile team works as a single team towards a common objective of achieving quality.

Table of Contents

Introduction

Scrum is a software development process. In today’s rapid world stakeholders want immediate return on their investments. They don’t want to wait for longer periods to get full featured product. As a result, nowadays new software development and testing framework is catching momentum i.e. Scrum approach.

In scrum, projects are divided in small features to be developed and tested in specific time-frames called as sprint (small cycles). Features should get developed and tested in specified small time-frames.  This agile scrum team is handled by scrum master.

Scrum is an iterative, incremental framework for projects and products or application development. Scrum has become more and more popular software development and testing framework among organizations. Many small to large sized IT companies have started to embrace Scrum framework, as this can create excellent quality products in less time than other traditional methodologies. This framework can save companies both time and money.

Pre-Requisite Soft Skills for a Scrum Team

Team Spirit

Cross functional Team work is at the heart of Scrum.  There is no “my work”, “I have finished my work” and “your work”. On a Scrum team we find only “Our work”, “we have completed our Sprint”.  Individuals will have helping tendency for sharing technical knowledge. Scrum Members are always available to team members rather than locked away behind closed doors.  Scrum Master will always motivate the teams and create a Supporting learning environment. Team will always be sprint-oriented and often discuss smooth run of the sprint. A scrum team’s job is to self-organize around the challenges and management’s job is to remove impediments to self-organization.

Communication

Good communication must exist among team members of development team, testing team, business analysts and stake holders. There must be highly collaborative interaction between client and the delivery teams. More client involvement implies more suggestions or changes from the client.  It implies more bandwidth for communication.

Commitment

Agile Teams needs periodic re-energizing to renew their commitments to their purpose and to each other.  Scrum Masters can help by ensuring that the team embraces the concept of whole-team responsibility and whole-team commitment to deliver working software at the end of each sprint. With the whole-team commitment, the team member who has completed his tasks will help the one who has not completed so that hopefully each finishes on time.

Problem Solving

Scrum does not simply focus on developing just any type of end product.  Instead, the Scrum method allows the team to focus on creating a product that fulfills the customer’s highest value priorities which are defined by product owners.

Transparency

Transparency among team members and management gives a real momentum to the scrum team. Scrum Master encourages people to ask for help, surface roadblocks, and give public recognition for those brave enough to do so. At the same time, Scrum Master also understands the time wasted and impact on the team when individuals sit on or ignore problems.

The Roles of Scrum

Scrum has three fundamental roles: Product Owner, Scrum Master, and team member.

  1. Product Owner: In Scrum, the Product Owner is responsible for communicating the vision of the product to the development team. He or she must also represent the customer’s interests through requirements and prioritization. Because the Product Owner has the most authority of the three roles, it’s also the role with the most responsibility. In other words, the Product Owner is the single individual who must face the music when a project goes away.The tension between authority and responsibility means that it’s hard for Product Owners to strike the right balance of involvement. Because Scrum values self-organization among teams, a Product Owner must fight the urge to micro-manage. At the same time, Product Owners must be available to answer questions from the team.
  2. Scrum Master: The Scrum Master acts as a liaison between the Product Owner and the team. The Scrum Master does not manage the team. Instead, he or she works to remove any impediments that are obstructing the team from achieving its sprint goals. In short, this role helps the team remain creative and productive, while making sure its successes are visible to the Product Owner. The Scrum Master also works to advise the Product Owner about how to maximize ROI for the team.
  3. Team Member: In the Scrum methodology, the team is responsible for completing work. Ideally, teams consist of seven cross-functional members, plus or minus two individuals. For software projects, a typical team includes a mix of software engineers, architects, programmers, analysts, QA experts, testers, and UI designers. Each sprint, the team is responsible for determining how it will accomplish the work to be completed. This grants teams a great deal of autonomy, but, similar to the Product Owner’s situation, that freedom is accompanied by a responsibility to meet the goals of the sprint.

The Core Process

Sprint Planning Meeting

The work to be performed in the Sprint is planned at the Sprint Planning Meeting. This plan is created by the collaborative work of the entire Scrum Team.The Sprint Planning Meeting is time-boxed to eight hours for a one-month Sprint. For shorter Sprints, the event is proportionately shorter. For example, two-week Sprints have four-hour Sprint Planning Meetings.

The Sprint Planning Meeting consists of two parts, each one being a time-box of one half of the Sprint Planning Meeting duration. The two parts of the Sprint Planning Meeting answer the following questions, respectively:

  1. What will be delivered in the Increment resulting from the upcoming Sprint?
  2. How will the work needed to deliver the Increment be achieved?

Part One: What will be done in this Sprint?

In this part, the Development Team works to forecast the functionality that will be developed during the Sprint. The Product Owner presents ordered Product Backlog items to the Development Team and the entire Scrum Team collaborates on understanding the work of the Sprint. The input to this meeting is the Product Backlog, the latest product Increment, projected capacity of the Development Team during the Sprint, and past performance of the Development Team. The number of items selected from the Product Backlog for the Sprint is solely up to the Development Team. Only the Development Team can assess what it can accomplish over the upcoming Sprint. After the Development Team forecasts the Product Backlog items it will deliver in the Sprint, the Scrum Team crafts a Sprint Goal. The Sprint Goal is an objective that will be met within the Sprint through the implementation of the Product Backlog, and it provides guidance to the Development Team on why it is building the Increment.

Part Two: How will the chosen work get done?

Having selected the work of the Sprint, the Development Team decides how it will build this functionality into a “Done” product Increment during the Sprint. The Product Backlog items selected for this Sprint plus the plan for delivering them is called the Sprint Backlog,The Development Team usually starts by designing the system and the work needed to convert the Product Backlog into a working product increment. Work may be of varying size, or estimated effort. However, enough work is planned during the Sprint Planning meeting for the Development Team to forecast what it believes it can do in the upcoming Sprint. Work planned for the first days of the Sprint by the Development Team is decomposed to units of one day or less by the end of this meeting. The Development Team self-organizes to undertake the work in the Sprint Backlog, both during the Sprint Planning Meeting and as needed throughout the Sprint. The Product Owner may be present during the second part of the Sprint Planning Meeting to clarify the selected Product Backlog items and to help make trade-offs. If the Development Team determines it has too much or too little work, it may renegotiate the Sprint Backlog items with the Product Owner. The Development Team may also invite other people to attend in order to provide technical or domain advice. By the end of the Sprint Planning meeting, the Development Team should be able to explain to the Product Owner and Scrum Master how it intends to work as a self-organizing team to accomplish the Sprint Goal and create the anticipated Increment.

Sprint Goal

The Sprint Goal gives the Development Team some flexibility regarding the functionality implemented within the Sprint. As the Development Team works, it keeps this goal in mind. In order to satisfy the Sprint Goal, it implements the functionality and technology. If the work turns out to be different than the

Development Team expected, then they collaborate with the Product Owner to negotiate the scope of Sprint Backlog within the Sprint. The Sprint Goal may be a milestone in the larger purpose of the product roadmap.

Daily Scrum

The Daily Scrum meeting is a 15-minute time-boxed event for the Development Team to synchronize activities and create a plan for the next 24 hours. This is done by inspecting the work since the last Daily Scrum and forecasting the work that could be done before the next one. The Daily Scrum is held at the same time and places each day to reduce complexity. During the meeting, each Development Team member explains:

  1. What has been accomplished since the last meeting?
  2. What will be done before the next meeting?
  3. What obstacles are in the way?

The Development Team uses the Daily Scrum to assess progress toward the Sprint Goal and to assess how progress is trending toward completing the work in the Sprint Backlog. The Daily Scrum optimizes the probability that the Development Team will meet the Sprint Goal. The Development Team often meets immediately after the Daily Scrum to re-plan the rest of the Sprint’s work. Every day, the Development Team should be able to explain to the Product Owner and Scrum Master how it intends to work together as a self-organizing team to accomplish the goal and create the anticipated increment in the remainder of the Sprint. The Scrum Master ensures that the Development Team has the meeting, but the Development Team is responsible for conducting the Daily Scrum. The Scrum Master teaches the Development Team to keep the Daily Scrum within the 15-minute time-box. The Scrum Master enforces the rule that only Development Team members participate in the Daily Scrum. The Daily Scrum is not a status meeting, and is for the people transforming the Product Backlog items into an Increment. Daily Scrums improve communications, eliminate other meetings, identify and remove impediments to development, highlight and promote quick decision-making, and improve the Development Team’s level of project knowledge. This is a key inspect and adapt meeting.

Sprint Review

A Sprint Review Meeting is held at the end of the Sprint to inspect the Increment and adapt the Product Backlog if needed. During the Sprint Review, the Scrum Team and stakeholders collaborate about what was done in the Sprint. Based on that and any changes to the Product Backlog during the Sprint, attendees collaborate on the next things that could be done. This is an informal meeting, and the presentation of the Increment is intended to elicit feedback and foster collaboration. This is a four-hour time-boxed meeting for one-month Sprints. Proportionately less time is allocated for shorter Sprints. For example, two week Sprints have two-hour Sprint Reviews.

The Sprint Review includes the following elements:

  • The Product Owner identifies what has been “Done” and what has not been “Done”;
  • The Development Team discusses what went well during the Sprint, what problems it ran into, and how those problems were solved;
  • The Development Team demonstrates the work that it has “Done” and answers questions about the Increment;
  • The Product Owner discusses the Product Backlog as it stands. He or she projects likely completion dates based on progress to date; and,
  • The entire group collaborates on what to do next, so that the Sprint Review provides valuable input to subsequent Sprint Planning Meetings.

The result of the Sprint Review is a revised Product Backlog that defines the probable Product Backlog items for the next Sprint. The Product Backlog may also be adjusted overall to meet new opportunities.

Sprint Retrospective

The Sprint Retrospective is an opportunity for the Scrum Team to inspect itself and create a plan for improvements to be enacted during the next Sprint. The Sprint Retrospective occurs after the Sprint Review and prior to the next Sprint Planning Meeting. This is a three-hour time-boxed meeting for one-month Sprints. Proportionately less time is allocated for shorter Sprints.

The purpose of the Sprint Retrospective is to:

  • Inspect how the last Sprint went with regards to people, relationships, process, and tools;
  • Identify and order the major items that went well and potential improvements; and,
  • Create a plan for implementing improvements to the way the Scrum Team does its work.

The Scrum Master encourages the Scrum Team to improve, within the Scrum process framework, its development process and practices to make it more effective and enjoyable for the next Sprint. During each Sprint Retrospective, the Scrum Team plans ways to increase product quality by adapting the Definition of “Done” as appropriate. By the end of the Sprint Retrospective, the Scrum Team should have identified improvements that it will implement in the next Sprint. Implementing these improvements in the next Sprint is the adaptation to the inspection of the Scrum Team itself. Although improvements may be implemented at any time, the Sprint Retrospective provides a dedicated event focused on inspection and adaptation.

Development and testing goes hand in hand

Case Study for Agile / Scrum Process

Quality Assurance activities in Scrum

Scrum is a management methodology. It has some important rules and practices for management, and management can get help to organize and better handle their processes by using this methodology. So, it is not an engineering process with some defined quality assurance activities. Management can introduce any activities by their own to get a quality product.  Dr. Ralph van Roosmalen says that, Scrum is a framework for project management and it does not contain any help for testing or development practices. Mostly companies working in Scrum use its combination with XP(Xtreme Programming). In this way Scrum assist in the project management and the practices of Xp are used to guide development.

Working step in Scrum are:

  • Unit testing
  • Continuous integration
  • Regular sprint meeting
  • Regular daily meeting
  • Strict to coding and design standard
  • Acceptance testing
  • Test automation
  • Exploratory Testing

Iterative lifecycle and frequent communication are the important aspects of SCRUM for a tester. There two require some adjustments from the tester’s side, and they can keep the some things in mind. Testing of the product is done during the iteration and not at the end of the development life cycle. It is the duty of the tester to decide that what to test when the product is still unfinished. Scrum is all about working as a team, and collaboration is the basic idea. So, for a tester it is highly recommended that he/she must work closely with other team members rather then working in isolation. Testers should be given an active participation in the daily meeting and a tester should be present at daily status meetings that and it is maximum of 15 minutes long. For a tester perspective it is worthy and quality oriented if he/she works with other testers and figures out that what to test, instead of testing from the requirements documents.

Best practices for Agile Testing process

  1. Integrate the testers in the development teams
  2. Teams are responsible for delivering software that meets expected requirements and quality. However, if we want teams to test the software, we must give them the knowledge to do it right. Testers have that knowledge. By integrating testers into the development teams, teams obtain the skills they need to test their software. When you try this, make sure you choose the right mix: one tester on three programmers is a fair but minimal number.

  3. Use risk based testing
  4. You can never test everything with the same (extensive) depth; even in a waterfall project you have to make choices. In an agile project all the activities are time boxed so you have to make choices about how extensively you want to test each feature. We use a risk based approach to determine which test activities we are going to carry out for a feature during the iteration. The risk level of every feature is determined by the customer and the teams. It is a very transparent process so the customer knows exactly which test activities are executed for every feature.

  5. Have testers review unit tests

    In our organization the developers are responsible for creating and maintaining the unit tests. Unit tests are a very important part of our test harness. Developers often have a different way of thinking; for example, they tend to test only the success scenario. To create unit tests that are as good as possible, our testers review the unit tests for all our high-risk items. The review has two advantages. First, the unit tests are improved because testers and developers supplement each other: the developer knows where the weak places in the source are, and the tester can use his knowledge of testing to give tips to improve the unit tests. Second, the testers know exactly which test cases are executed in the unit tests and can concentrate on executing other (e.g. higher-level) test cases.

  6. Create a test automation framework and appoint a tool smith
  7. Automated testing is very important because new features and refactoring can introduce problems that can be difficult to find. By using an automated test framework, we can maintain quality levels during the iteration. Our testers are able to create new tests easily and quickly in the framework. We have a dedicated test engineer (we call him a tool smith) that maintains and optimizes the test automation framework, reviews the new automated tests of the testers and analyzes the daily test results. Testers in the teams can spend more time creating and extending automated tests because the tool smith supports them.

  8. Display quality metrics in a public location
  9. Almost every software project has a problem registration system, automated test results, and in some cases nightly or continuous build results. But how often do team members look at the results or count the open problems? We installed a monitor in the coffee room that displays the actual metrics of the currently open problems, the percentage of successful unit tests, the percentage of successful nightly builds, and the current state of the continuous build. By displaying the metrics in public the teams are confronted with the information. The information is no longer just a number in a system or a record with some information in a metrics database.

  10. Add a test scrum
  11. One advantage of having a separate test team in one room is that the communication between the testers is good. When you have a project like ours where the testers are distributed across several teams, the communication becomes more difficult. To solve this problem, we use a test scrum to align the test activities. Our test scrum is held twice a week and every team is represented by one tester. The test scrum is a scrum like the daily team scrum but focused on test activities. The test manager is the scrum master of the test scrum.

  12. Implement test retrospectives
  13. Every team in our project holds a retrospective meeting at the end of the iteration. In the retrospective, the team discusses the process: what went well and what went wrong. The testers in the team learn and discover new ways to improve their tests; it is good when they share this knowledge with testers from the other teams. We have a test retrospective every iteration so the testers can exchange knowledge and experience and discuss problems they have. It is important that the retrospective is only related to test issues; you shouldn’t discuss team issues (they should be discussed in the team retrospective). As with the test scrum, the test manager is the scrum master of the test retrospective.

  14. Plan open problems
  15. We try to fix all the problems that we find during the iteration in that same iteration, but sometimes we end the iteration with open problems. The best way to handle those problems is to add those problems to the sprint backlog for the next iteration. By explicitly planning those problems, the chance that they are “forgotten” and pile up is very small.

  16. Remember: Testing is still testing
  17. When you test in an agile software project you can still use the “traditional” test techniques. We use exploratory testing but also apply test techniques such as boundary value analysis, equivalence partitioning, cause/effect diagram, and pair-wise testing. Which test techniques we choose for a feature depend on its risk category. Exploratory testing is used in every category; but if the risk is higher we also apply more formal test techniques. The challenge for the tester is to use a formal test technique without delivering extensive test documentation.

  18. Start doing it!
  19. The last but most important tip is start doing it! Don't talk too much about how you are going to introduce testers, or which test approach is perfect for your organization. You are going to make mistakes or discover that the chosen approach doesn’t fit your organization. That’s a given. But, the sooner you start, the sooner you can begin learning and improving your test approach. With the retrospective meetings, you have the opportunity to adapt your test approach every month.

License

This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Share

About the Author

Rohan_Jain
Tester / Quality Assurance
India India
No Biography provided

Comments and Discussions

 
GeneralMy vote of 5 Pinmemberjawed.ace26-Feb-13 21:13 
GeneralRe: My vote of 5 PinmemberRohan_Jain26-Feb-13 21:35 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.

| Advertise | Privacy | Terms of Use | Mobile
Web04 | 2.8.141223.1 | Last Updated 22 Feb 2013
Article Copyright 2013 by Rohan_Jain
Everything else Copyright © CodeProject, 1999-2014
Layout: fixed | fluid