Vous êtes sur la page 1sur 38

Agile Testing Methodology

AGENDA
AGILE SCRUM XTREME PROGRAMMING AGILE TESTING

AGILE-In Brief by

Introducing Agile
Software development Life cycle model that focus on customers.
Iterative development, where requirements and solutions evolve through collaboration between self-organizing crossfunctional teams.

Why Agile????

3 KEYS
Incremental, Iterative, Adaptive
Incremental Build a system gradually Demonstrating progress Iterative Multiple releases or check points , closer to the target Iterations include requirements, development and testing Adaptive Goals change based on lessons from prior iterations, feedback and business opportunities

Process

Prioritize
How people spend their time in Agile:
Analysis 16% Design 17% Code/Unit Test 34% System/Integration Test 18% Documentation 8% Implementation/Install 7%

7 Principles
Satisfy the customer through The most efficient method early and continuous delivery of conveying information to of valuable software. and within a development team is face-to-face Working software is the conversation. primary measure of progress. Business people and Deliver working software developers must work frequently, from a couple of together daily throughout weeks to a couple of months. the project. Welcome changing Simplicity--the art of requirements, even late in maximizing the amount of development. work not done--is essential.

Benefits
Empirical (relies on observation and experience) Lightweight Adaptive Fast but never hurried Exposes wastefulness Customer-centric Pushes decision making to lower levels Fosters trust, honesty and courage Encourages self-organization

Scrum by,

Scrum - an agile process


SCRUM is an agile, lightweight process for managing and controlling software and product development in rapidly changing environments.

Team-based approach Controls the chaos of conflicting interest and needs Improve communication and maximize cooperation A way to maximize productivity
JASS 2006 Agile Project Management - Scrum 12

History of Scrum
1995:
analysis of common software development processes not suitable for empirical, unpredictable and non-repeatable processes Design of a new method: Scrum by Jeff Sutherland & Ken Schwaber Enhancement of Scrum by Mike Beedle & combination of Scrum with Extreme Programming

1996:
introduction of Scrum at OOPSLA conference

2001:
publication Agile Software Development with Scrum by Ken Schwaber & Mike Beedle

Successful appliance of Scrum in over 50 companies Founders are members in the Agile Alliance

JASS 2006

Agile Project Management - Scrum

13

Functionality of Scrum

JASS 2006

Agile Project Management - Scrum

14

component View

3 Men Army

Scrum Master -> a Project Manager or Team Leader and is responsible for enacting scrum values and practices Scrum Team -> 5-10 people who are Cross-functional, Working full-time and self-organizing Product Owner -> product manager works on what needs to be build and in what sequence this should be done

Process
Sprint Planning Meeting
Meeting in the beginning of each Sprint between the stake holders where the goal is determined and the project kickoff is done.

Sprint
A month-long iteration, during which is incremented a product functionality

Contd
Daily Scrum
Meeting to track the progress of the Team

Sprint Review Meeting


Business functionality created during the Sprint is demoed to the Product Owner

Scrum Artifacts
Product Backlog
Requirements and outcomes for a system, expressed as
a prioritized list of Backlog Items in Spread Sheets.

Sprint Backlog
Define the work for a Sprint, created and updated every day by Team members

Burn down Charts


Depicts the total Sprint Backlog hours remaining per day Shows the estimated amount of time to release
JASS 2006 Agile Project Management - Scrum 19

Sample Burn Down Chart

XTREME PROGRAMMING by,

XTREME PROGRAMMING
lightweight methodology for smallto-medium-sized teams developing software in the face of vague or rapidly changing requirements. promises to reduce project risk, improve responsiveness to business changes, improve productivity throughout the life of a system, and add fun to building software in teams

NEED
Software project failures are legendary Traditional software methodologies are unable to:
Handle faster delivery cycles Nor able to embrace frequent change They cant live in web world

4 principles
Communication Simplicity Feedback Courage

Basic Activities
Coding Testing Listening Designing

eXtreme programming - principles & practices

Release cycle

Practices 1
Incremental planning Requirements are recorded on Story Cards and the Stories to be included in a release are determined by the time available and their relative priority. The developers break these Stories into development Tasks . The minimal useful set of functionalit y that provides business value is developed first. Releases of the system are frequent and incrementally add functionalit y to the first release. Enough design is carried out to meet the current requirements and no more. An automated unit test framework is used to write tests for a new piece of functionalit y before that functionality itself is implemented. All developers are expected to refactor the code continuously as soon as possible code improvements are found. This keeps the code simple and maintainable.

Small Releases

Simple Design Test first development

Refactoring

Practices 2
Pair Programming Collective Ownership Developers work in pairs, checking each other work and s providing the support to always do a good job. The pairs of developers work on all areas of the system, so that no islands of expertise develop and all the developers own all the code. Anyone can change anything. As soon as work on a task is complete it is integrated into the whole system. After any such integration, all the unit tests in the system must pass. Large amounts of over-time are not considered acceptable as the net effect is often to reduce code qualit y and medium term productivity A representative of the end-user of the system (the Customer) should be available full time for the use of the XP team. In an extreme programming process, the customer is a member of the development team and is responsible for bringing system requirements to the team for implementation.

Continuous Integration

Sustainable pace

On-site Customer

Key Ideas
Code in Pairs Stay in Contact with the Customer Create Tests before Coding then Test Heavily Short Iterations Keep it Simple Dont Anticipate: Code for Current Needs Collective Ownership

Advantages
Built-In Quality Overall Simplicity Programmer Power Customer Power Synergy Between Practices

Agile Testing by,

Agile Testing
An iterative approach of software development involving all the stake holders right from the requirement phase of the development cycle. Test Driven Development test cases are developed, and often automated, before the software is developed to run the test cases.
Project Development Test Manager Manager Manager

Concept (Inception)

Deploy

I0

$ $ Marketing Key Stakeholders $ $


Senior Developer Business Rep / Customer Senior Tester

In

+1

Analysis
I1

In+1

Key Stakeholders

I1

Design (TDD)
Business Rep / Customer Security Tester Performance Tester
In+1

Showcase Tests

Final Acceptance Test

Senior Tester Test Team

Iteration Manager

I1

Architect

Develop & Unit Test


I1

Development Team Test Toolsmith Senior Developer

Business Analyst

Story Acceptance Test

I1

+ In

Integration / System Test


1 In+

Regression Tests

In+1

In+1

I1

3 Models
$ $

Concept
Marketing

Key Stakeholders

Concept
Marketing

Deploy
Business Rep / Customer

Marketing

Key Stakeholders

Key Stakeholders

Analysis
Business Business Rep / Customer Analyst

Concept (Inception)

Deploy

Design
Architect Senior Developer

Business Rep / Customer Business Analyst

Analysis
Senior Tester Test Team

Acceptance Test

Analysis
Project Manager Security Tester

Business Rep / Customer Senior Developer

Project Manager

Develop
Development Team
Senior Architect Developer

Design
Senior Tester Test Team

Test Manager

Senior Tester

Integration/ System Test

Final Acceptance Test

Performance Tester

Test
Test Toolsmith Senior Tester Development Manager Test Team

Design (TTD)

Business Senior Rep / Customer Business Developer Analyst

Acceptance Test

Project Manager

Test Team Performance Tester Security Tester

Architect

Deploy

Develop

Unit Test

Development Team
Test Manager

Development Test Manager Manager

Develop & Unit Test


Business Rep / Customer
Development Team

Senior Test PerformanceSecurity Test Team Tester Toolsmith Tester Tester

Testing Roles
Traditional Roles Test Manager Senior Tester / Test Lead Test Analyst Technical Tester Performance Tester Test Toolsmith Security Tester Agile Roles Test Manager Senior Tester / Test Lead Test Analyst Technical Tester Performance Tester Test Toolsmith Security Tester Iteration Manager Showcase Tester

Slide 34

Slide 34

Risks 1
Risk
Requirements changing.

Solution
Acceptance of change that is what Agile is about. Clear understanding of the features and stories by the entire team. Early team involvement in meetings, Wall ware all can see it. Just Enough documentation. Automated unit tests. Skilled testers using Exploratory Testing.

No documentation.

Testers not involved early in iteration lack of knowledge of testing = using Exploratory Testing.
Slide 35

Slide 35

Risks 2
Risk
Little or no unit testing.

Solution
Education of developers, experience and team maturity. More unit testing with tester involvement, more points allocated to testing. Provision for Smoke Tests

REGRESSION!

No clear definition of Done Regular involvement of and Burn charts not accurate. reporting to the Business.

Slide 36

Slide 36

Benefits
Early delivery of working software Quality is built into the products everyone involved in quality Defect prevention (stopping them from getting beyond the requirements) Clear acceptance criteria Early involvement of all key players No surprises to the business on delivery
Slide 37

Slide 37