By using the suite of tools in Visual Studio Premium and Visual Studio Ultimate, and combining those tools with Visual Studio Team Foundation Server, you can apply proven practices to manage your application's lifecycle, from understanding customer needs through code design and implementation to deployment. You can use the instrumentation in these tools to trace requirements to checked-in code, builds and test results. These practices can help your team create software that is valued by your customers and that is faster and more reliable. You can use these tools to achieve the following results:
Plan and Track: Capture what is important to your customers, and track your project's progress. Enact processes and monitor their quality to help your team turn customer requirements into working software. Planning and Tracking Projects
Design: Design functionality either on top of existing assets or from scratch, using architectural diagrams to communicate critical information about your team's software. Modeling the Application
Develop: Write, unit test, debug, analyze, and profile your application using tools that are integrated with the rest of the application lifecycle so that your team can understand how your progress contributes to the project. Developing the Application
Using Version Control
Build: Build your application using the integrated build system so that your team can ensure quality gates are met and see what requirements have been fulfilled in each build. Building the Application
Test: Run manual or automated tests, including performance and stress tests. Manage testing systematically so that your team knows the software quality on any given day. Testing the Application
Deploy: Deploy into virtual environments to enable more sophisticated development and testing. Using a Virtual Lab for Your Application Lifecycle
Team Project Structure
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.
• What is Scrum?
Scrum is an agile approach to software development. Rather than a full process or methodology, it is a framework. So instead of providing complete, detailed descriptions of how everything is to be done on the project, much is left up to the team. This is done because the team will know best how to solve its problem. This is why, for example, a sprint planning meeting is described in terms of the desired outcome (a commitment to set of features to be developed in the next sprint) instead of a set of Entry criteria, Task definitions, Validation criteria, and Exit criteria (ETVX) as would be provided in most methodologies.
Scrum relies on a self-organizing, cross-functional team. The scrum team is self-organizing in that there is no overall team leader who decides which person will do which task or how a problem will be solved. Those are issues that are decided by the team as a whole. The team is cross-functional so that everyone necessary to take a feature from idea to implementation is involved. These teams are supported by two specific individuals: a ScrumMaster and a product owner. The ScrumMaster can be thought of as a coach for the team, helping team members use the Scrum framework to perform at their highest level. The product owner represents the business, customers or users and guides the team toward building the right product.
Scrum projects make progress in a series of sprints, which are timeboxed iterations no more than a month long. At the start of a sprint, team members commit to delivering some number of features that were listed on the project’s product backlog. At the end of the sprint, these features are done--they are coded, tested, and integrated into the evolving product or system. At the end of the sprint a sprint review is conducted during which the team demonstrates the new functionality to the product owner and other interested stakeholders who provide feedback that could influence the next sprint.
Scrum
Scrum is a framework for running projects that is based on agile principles and values. It defines a set of activities that can help your team deliver more value to your customers faster. These activities provide your customers with the opportunity to review, guide and influence your team's work as it progresses. This approach does not attempt to define everything at the start of a project. Instead, your team works in short iterations (also called sprints) and refines the plan as the team makes progress.
Iterative Development with Scrum
The Light Weight Scrum process template defines a number of predefined solution iterations, known as sprints, which define a set of activities and solution features that must be completed within a predefined period of time (sprint). Initially sprints will be focused on different deliverables such analysis and design, development, testing and deployment. Shorter duration sprints reduce the margin of error in team estimates and provide fast feedback about the state and health of the solution. It is imperative that each sprint is concluded with a working piece of the solution, which can be demonstrated during the sprint review meeting. The typical duration of a sprint is between two weeks and one month.
• Prepare for the project
• Plan the project
• Plan the Sprint
• Run a Sprint
• Track the project
Scrum has three artifacts: the Product Backlog, the Sprint Backlog, and a Burndown Chart.
Product Backlog
At the beginning of the project, the product owner prepares a list of customer requirements prioritized by business value. This list is the Product Backlog, a single list of features prioritized by value delivered to the customer. The Scrum Team contributes to the product backlog by estimating the cost of developing features.
The Product Backlog should include all features visible to the customer, as well as the technical requirements needed to build the product. The highest priority items in the Product Backlog need to be broken down into small enough chunks to be estimable and testable. About ten developer-days of work is a good size for a Product Backlog item that can be ready for implementation in the next iteration. Features that will be implemented further out in time can be less detailed.
Sprint Backlog
The Sprint Backlog is an artifact of the Sprint Planning Meeting. When the Scrum Team has selected and committed to deliver a set of top priority features from the Product Backlog, the Product Backlog's features are broken down into a Sprint Backlog: a list of the specific development tasks required to implement a feature. These tasks are broken down into pieces that will require less than two days (or sixteen developer-hours) of work. When the Sprint Backlog is complete, the total work estimated is compared with original estimates from the Product Backlog. If there is a significant difference, the team negotiates with the Product Owner to get the right amount of work to take into the Sprint with a high probability of success.
Burndown Chart
The Burndown Chart shows the cumulative work remaining in a Sprint, day-by-day.
At the Sprint Planning Meeting the Scrum Team identifies and estimates specific tasks that must be completed for the Sprint to be successful. The total of all Sprint Backlog estimates of work remaining to be completed is the cumulative backlog. When tasks are completed as the Sprint proceeds, the ScrumMaster recalculates the remaining work to be done and the Sprint Backlog decreases, or burns down over time. If the cumulative Sprint Backlog is zero at the end of the Sprint, the Sprint is successful.
The Product Backlog items brought into the Sprint are fixed for the duration of the Sprint. However, the Sprint Backlog may change for several reasons:
• The development team gains a better understanding of work to be done as time progresses and may find that they need to add new tasks to the Sprint Backlog to complete the Product Backlog items selected.
• Defects may be identified and logged as additional tasks. While these are viewed primarily as unfinished work on committed tasks, it may be necessary to keep track of them separately.
• The Product Owner may work with the team during the Sprint to help refine team understanding of the Sprint goal. The ScrumMaster and Team may decide that minor adjustments that do not lengthen the Sprint are appropriate to optimize customer value.
The Burndown Chart is used as a tool to guide the development team to successful completion of a Sprint on time with working code that is potentially shippable as a product.
Scrum has three roles: Product Owner, ScrumMaster, and Team.
The Product Owner has the following responsibilities.
• Define the features of the product;
• Decide on release date and content;
• Be responsible for the profitability of the product (ROI);
• Prioritize features according to market value;
• Adjust features and priority every 30 days, as needed; and
• Accept or reject work results.
The product owner is responsible for the first of the three Scrum ceremonies : Scrum Planning.
The ScrumMaster is a facilitative team leader working closing with the Product Owner. He must:
• Ensure that the team is fully functional and productive;
• Enable close cooperation across all roles and functions;
• Remove barriers;
• Shield the team from external interferences; and
• Ensure that the process is followed, including issuing invitations to Daily Scrum, Sprint Review and Sprint Planning meetings.
The ScrumMaster has three primary responsibilities in addition to leading the Daily Scrum meeting:
1. The ScrumMaster needs to know what tasks have been completed, what tasks have started, any new tasks that have been discovered, and any estimates that may have changed. This makes it possible to update the Burndown Chart which shows the cumulative work remaining day by day. The ScrumMaster must also look carefully at the number of open tasks in progress. Work in progress needs to be minimized to achieve lean productivity gains.
2. The ScrumMaster needs to surface dependencies and blocks which are impediments to the Scrum. They need to be prioritized and tracked. A remediation plan needs to be implemented for impediments in priority order. Some can be resolved with the team, some can be resolved across teams, and others will need management involvement as they may be company issues that block all teams from achieving their production capacity. For example, a telecom company recently implemented Scrum and found eighteen items on their impediment list, only two of which were directly related to Scrum teams. The others were company issues that needed management attention.
3. Last but not least, the ScrumMaster may notice personal problems or conflicts within the Scrum that need resolution. These need to be clarified by the ScrumMaster and be resolved by dialogue within the team, or the ScrumMaster may need help from management or the Human Resources. Certified ScrumMaster James Coplien developed over 200 case studies of notable projects while working at ATT Bell Labs. He reports that over 50% of productivity losses were caused by personnel issues. The ScrumMaster must pay attention to them to ensure the team is fully functional and productive.
The Team:
• Is cross-functional, with seven (plus/minus two) members;
• Selects the Sprint goal and specifies work results;
• Has the right to do everything within the boundaries of the project guidelines to reach the Sprint goal;
• Organizes itself and its work; and
• Demos work results to the Product Owner.
Scrum Work items
• Bug
• User stories
• Task
• Test Plan
• Test case
• Impediment
• Product Backlog
• Shared steps
• Sprint
• Sprint Backlog
• Sprint retrospective
• Other work items
User Story
A User Story describes a desired feature (functional requirement) in narrative form. User Stories are usually written by the Product Owner, and are the Product Owner's responsibility. The format is not standardized, but typically has a name, some descriptive text, references to external documents (such as screen shots), and information about how the implementation will be tested.
For example, a Story might resemble the following:
Name: Planner enters new contact into address book, so that he can contact the person later by postal or electronic mail
Description: Planner enters standard contact information (first and last name, two street address lines, city, state, zip / postal code, country, etc.) into contact-entry screen. He clicks "Save" to keep the data, and "Cancel" to discard data and return to previous screen.
Screens and External Documents: http://myserver/screens/contact-entry.html
How to test: Tester enters and saves the data, finds the name in the address book, and clicks on it. He sees a read-only view of the contact-entry screen, with all data previously entered.
The elements in this User Story are:
1. Name: The Name is a descriptive phrase or sentence. The example uses a basic "Role-Action-Reason" organization. Another common style, popularized by Mike Cohn, follows the template "As a
2. Description: This is a high-level (low-detail) description of the need to be met. For functional (user-facing) requirements, the description is put in narrative form. For non-functional requirements, the description can be worded in any form that is easy to understand. In both cases, the key is that the level of detail is modest, because the fine details are worked out during the implementation phase, in discussions between team members, product owners, and anyone else who is involved. (This is one of the core concepts of Scrum: Requirements are specified at a level that allows rough estimation of the work required to implement them, not in detail.)
3. Screens and External Documents: If the Story requires user-interface changes (especially non-trivial ones), the Story should contain or link to a prototype of the changes. Any external documents required to implement the Story should also be listed.
4. How to test: The implementation of a Story is defined to be complete if, and only if, it passes all acceptance tests developed for it. This section provides a brief description of how the story will be tested. As for the feature itself, the description of testing methods is short, with the details to be worked out during implementation, but we need at least a summary to guide the estimation process.
There are two reasons for including the information about how to test the Story. The obvious reason is to guide development of test cases (acceptance tests) for the Story. The less-obvious, but important, reason, is that the Team will need this information in order to estimate how much work is required to implement the story (since test design and execution is part of the total work).
Meeting Purpose Duration Frequency
Sprint Planning Meeting
Determine what work to do in the coming sprint. Two hours per week in the sprint, up to four hours Once per sprint
Daily Scrum Meeting
Allow team members to commit, collaborate, and communicate risks. Fifteen minutes Daily
Sprint Review Meeting
Show the customer and other stakeholders the work that the team accomplished in the sprint, and receive feedback. Two hours per week in the sprint, up to four hours Once per sprint
Retrospective Meeting
Identify and implement ideas for process improvement. Three hours Once per sprint
Scrum is a lightweight agile process framework used primarily for managing software development.
Scrum is:
Lightweight because it has few prescribed elements
Three roles: Team, Scrum Master (often a Project Manager), Product Owner (often a Product Manager)
Three meetings: Sprint Planning, Daily Scrum, Retrospective
Three artifacts: Product Backlog, Sprint Backlog, Burndown chart
Agile because it maximizes responsiveness to changing customer needs
A process framework because it is not a process, but a collection of practices and concepts around which a process can be built
Scrum is often contrasted with the so-called “Waterfall” approach, which emphasizes up-front planning and scheduling of activities, followed by execution. Both approaches require careful planning, followed by execution and tracking, but the details of how these steps are accomplished are different.
Scrum
Scrum processes are cyclical, repeating every few weeks. Product Owners provide requirements, in the form of Stories (short narrative descriptions). The Team of developers and QA engineers implements the Stories in a Sprint of 2—4 weeks in length. During the Sprint, Team members work with Product Owners to refine and clarify requirements, to ensure proper implementation. Final requirements are defined by test cases created by QA engineers, and are used to validate each story to confirm that it is complete.
Stories are implemented in rank order, one at a time, to ensure that highest-priority requirements are implemented first. This serialization of feature development ensures that some useful features will be completed even if less work can be accomplished during a Sprint than expected.
Why Choose Scrum versus Waterfall for Software Projects?
The two approaches make different assumptions about the priorities and practicalities of the work to be accomplished.
Waterfall Processes Assume or Require that
Success is defined by achieving the planned scope.
Tightest constraint may be on scope or schedule
Sometimes schedule is extended to achieve scope
Sometimes scope is reduced to achieve schedule
Requirements are well-understood and will not change
Change requests represent exceptions that must be handled by a change-request process
All steps are known and can be estimated with reasonable accuracy
Process is linear: Starts with requirements, leads to results, and stops
Some steps may involve long lead times, or lots of specialized resources
Incremental results (e.g, at 20% of scope) have little or no value
Scrum Projects Assume or Require that
Success is defined by responsiveness to customer requests
Requires quick turnaround (2—4 week Sprints) for high-priority requests
Tightest constraint is on schedule, to achieve quick turnaround
Scope is adjusted to fit schedule
Requirements change frequently, even from month to month
Change is the norm, and requests are re-prioritized at Sprint boundaries
Work requires constant invention, so all steps are not known in advance, and estimates are not expected to be reliable
Process is cyclic: It repeats every Sprint, and planning for next Sprint overlaps with the work on the current Sprint
No steps involve long lead times or lots of specialized resources
Incremental results (e.g., at 20% of scope) have significant value
Few of the criteria individually identify which process is more appropriate for a project, but taken together, the decision is usually straightforward. Some examples include
Deploying an ERP application, such as SAP. The vendor has done this many times, has a process with all steps clearly defined and understood, and can proceed with a well-practiced waterfall process.
Creating custom reports for the ERP application. This is likely to be an iterative process, as reports evolve towards greater usefulness over time due to user feedback, and is well-suited to a Scrum process.
In general, if you have to figure out how to do a significant amount of the work in the project because you haven’t done it before, so you cannot estimate accurately, go with a Scrum process. If you’ve done it many times before, and know how to do it again, go with a waterfall process.
The Benefits of Scrum
Different stakeholders want different things from a software development process.
Developers want to write code, not documents.
Quality Assurance engineers want to create test plans that ensure product quality, and have high-quality code to test.
Project Managers want a process that is easy to plan, execute, and track.
Product Managers want features implemented quickly, with no bugs.
Services and Support personnel want to know exactly what is in all product releases, and have a reliable means to satisfy customer requests for bug fixes and enhancements.
Sales personnel want to know what is “in the pipeline” for future releases.
Customers want all of their feature requests and bug-fixes done quickly.
Executives, Program Managers, and PMO personnel want to know exactly what is happening, and what is planned to happen.
Everyone wants happy customers.
The list seems long, but the key points are few:
Team satisfaction and productivity are maximized when effort spent on non-deliverable items (e.g., internal documentation) is kept to a minimum.
Maximizing quality at each stage minimizes re-work at following stages, and maximizes product quality seen by customers.
Responsiveness is best achieved by fulfilling customer requests quickly.
Project status and plans should be visible to everyone who has an interest in them.
Thus the best real-world development process devotes as little effort as possible to artifacts the customer doesn’t value, provides relatively bug-free code at the start of testing, delivers all relevant information to everyone who needs it, and fulfills customer requests quickly.
It is no coincidence that Scrum was designed to satisfy these points.
PM Term = Scrum Term
Schedule = Sprint (or Release)
Scope = Sprint Backlog
Work Breakdown Structure = Task Breakdown
Productivity = Velocity
Estimate to Complete = Burndown Chart
http://www.scrumforteamsystem.com/ProcessGuidance/v2/Scrum/Scrum.aspx
http://www.mountaingoatsoftware.com/topics/scrum
http://msdn.microsoft.com/en-us/library/fda2bad5.aspx
http://www.cprime.com/about/scrum_faq.html
Scrum Testing Methodology - Presentation Transcript
1. Agile Scrum Testing Methodology– an Overview - Gayathri
2. Agile Testing - Overview
o What is Agile Testing?
o Agile Testing can be defined as a
o Testing practice that follows the agile manifesto, treating development as the customer of testing
o Testing practice for projects using agile methodologies.
3. Agile Testing - Overview
o Process in Scrum Testing
o A Product Backlog of prioritized work to be done
o The entire product backlog items are split into a fixed set of items called Sprints
o A daily Scrum Meeting is organized where the team discusses three question.
What have you done since the last daily meeting?
What will you be doing until the next daily meeting?
What impediments, if any, are in your way?
o A Sprint Planning session where the Sprint Backlog items are split with the team members
o A Sprint Retrospective session where the team member would put forward the best practice they followed or introduce a process would need to implement for a successful Sprint.
o All the meetings will be facilitated by the Scrum Master.
4. Characteristics of Scrum Testing
5. Agile Testing – Process proposed
o Scrum Testing process workflow
Identify the Test Scenarios based on the BRD document
o Obtain sign-off of the Test Scenario document from the respective Business Owners
o Test Cases will be written for Sprint by Sprint basics
o Execution will be done by delaying a Sprint (When Sprint 2 items are developed we will be executing Sprint 1 functionality)
o A change in a requirement or a defect will be added to the product backlog
o A constant regression bed is identified for all the completed Sprints
o Since delaying the testing by a Sprint may provide a gap between the development team and the testing team, we will have a pre deployment in each Sprint which helps us to address the major issues pro actively.
6. Agile Testing – Process proposed Testing process workflow
7. Sprint Schedule with QA Tasks
8. Agile Testing – Process proposed
o Scrum Terminology
o Scrum Master: The person or persons in charge of the tracking and the daily updates for the
o scrum (equivalent to a project manager). Sometimes referred to as a Scrum Facilitator.
o Scrum Team: A cross-functional team (developers, B.A.s, DBAs, and testers) responsible for
o developing the product.
o Product Owner: The person responsible for maintaining the Product Backlog via continuous interaction with Clients and Stakeholders.
o Story: A customer focused description of valued functionality.
o Product Backlog: The stories to be completed.
o Sprint: A time period (usually 2 to 4 weeks) in which development occurs on a set of stories that
o the Team has committed to.
o Sprint Backlog: The Team's interpretation of the product backlog containing concrete tasks that
o will be done during the next sprint to implement some of the top items in the Product Backlog.
9. Agile Testing – Process proposed
o Scrum - FAQ’s
o What happens if you don’t finish on time?
o Scrum does not allow a delivery date to be altered! If you are behind, you delete items in the Scrum Team’s Sprint Backlog and if you are ahead you can ask the Product Owner for more tasks.
o Can Scrum only be used for smaller projects?
o No, the method can be up-scaled by putting together several smaller projects to form one larger. A so-called Scrum of Scrums can include hundred of programmers, organized in dozens of Scrum Teams.
o Where does the word Scrum come from?
o Scrum is a rugby term for the close-knit shoulder-to-shoulder formation a rugby team forms to jointly move the ball forward.
o The word was first used by Takeuchi and Nonaka in a famous article published in the Harvard Business Review in which they described the most successful product development projects in Japan.
10. Agile Testing - Overview
o How can Testers prove their value
o Demonstrate a helpful perspective in defining software expectations
o Provide information. Don’t act like a gatekeeper.
o Adapt to changing project goals.
o Work with what you have, ask for what you need to know, document what you can.
I actually enjoyed reading through this posting.Many thanks.
ReplyDeleteAgile Software Development with Scrum - cPrime