Unit 4 Agile Development Process · Unit 4 Agile Development Process Agile Development: Agile...
Transcript of Unit 4 Agile Development Process · Unit 4 Agile Development Process Agile Development: Agile...
Unit 4
Agile Development Process
Agile Development: Agile manifesto, agility and cost of change, agility
principles, myth of planned development, toolset for the agile process.
Extreme Programming: XP values, process, industrial XP, SCRUM - process
flow, scrum roles, scrum cycle description, product backlog, sprint planning
meeting, sprint backlog, sprint execution, daily scrum meeting, maintaining sprint
backlog and burn-down chart, sprint review and retrospective.
Agile Practices: test driven development, refactoring, pair programming,
continuous integration, exploratory testing versus scripted testing
2
Project Execution Traditional Approach
What comes to your mind ???
2
Project Execution Traditional Approach
• Big Bang / Code & Fix
• Waterfall 1950 - 1970
• Spiral Model 1980 - 1988 – Incremental
– Iterative
• RAD (Rapid Application Development) 1990
• Agile 2001
3
Typical Waterfall
4
5
Agile framework & principles
The concept of iterative and incremental approach to development started away back from 1950s.
• In 1950s – NASA and The United States Department of Defence (DoD) have used the incremental and iterative development (IID) approach.
• In 1960s – the concept of Evolutionary project management (Evo) recommended a one- to two-week iterations, delivery of product in each iteration.
• In 1986 – The “rugby approach” was discussed with dedicated, self-organizing teams. Here a team tries to go the distance as a unit, passing the ball back and forth—may better serve today’s competitive requirements.”
Origin -
6
Agile framework & principles
Rugby Approach –
(Photo from www.zimbio.com – Northland club Rugby)
What is “Agility”?
• Effective (rapid and adaptive) response to change!
• Effective communication among all stakeholders!
• Drawing the customer onto the team! Eliminate “us
and them” attitude
• Organizing a team so that it is in control of the work
performed!
• Yielding …!
• Rapid, incremental delivery of software!
Agility and the Cost of Change
• A well-designed agile process “flattens” the cost of change
curve
• Allowing a software team to accommodate changes late in a
software project without dramatic cost and time impact.
• You‟ve already learned that the agile process encompasses
incremental delivery.
• When incremental delivery is coupled with other agile practices
• such as continuous unit testing and pair programming the
cost of making a change is attenuated.
Agility and the Cost of Change
An Agile Process
• Is driven by customer descriptions of what is required
(scenarios)!
• Recognizes that plans are short-lived! (some requirements
will persist, some will change. Customer priorities will change)
• Develops software iteratively with a heavy emphasis on
construction activities! (Design and Construction activities are
interleaved)
• Delivers multiple „software increments‟!
• Adapts as changes occur!
11
Agile framework & principles
• 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 above states that while there is a value in the items on the right,
we value the items on the left more.
Agile Manifesto –
12
Agile framework & principles
Individuals and interactions over processes and tools –
• Promotes empowered, self-managing, cross functional teams • Advocates members to collaborate in person to solve a mutual problem • Tools support cannot replace individual interactions
Agile Manifesto –
13
Agile framework & principles
Working software over comprehensive documentation
Agile Manifesto –
• Status / progress should be measured on actual working product and not by percentage completion of the functional milestones
• Agile encourages teams for face-to-face communication over documentation which is simpler, faster, and far more reliable
• Documents usually gets out-dated as system design keeps on changing
14
Agile framework & principles
Customer collaboration over contract negotiation
Agile Manifesto –
• Customers become an integral part of the development process and not only during contract negotiation and defining specification
• Better way to deliver value instead of a carefully worded contract
15
Agile framework & principles
Responding to change over following a plan
Agile Manifesto –
• Agile plans follow more of a rolling wave approach using top-down planning
• Change management is easier when the organization and the customer share a clear understanding of the project’s status
• In plan-driven environments, all requirements are specified up front, broken down to the task level and estimated which is not the case in Agile developments
• Business needs and priorities can shift in the months or even years it can take for a large system to be fully built
16
Agile framework & principles
1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software
2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale
4. Business people and developers must work together daily throughout the project
5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done
6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation
12 Agile Principles –
17
Agile framework & principles
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
9. Continuous attention to technical excellence and good design enhances agility
10. Simplicity—the art of maximizing the amount of work not done—is essential
11. The best architectures, requirements, and designs emerge from self-organizing teams
12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly
12 Agile Principles –
Myths of Planned Development
Agile
development is
a methodology Agile is
undisciplined
Myths of Planned Development
Agile has no planning
Agile has no documentation
Myths of Planned Development
Agile has no upfront
design/architecture
Agile does not scale
Myths of Planned Development
Agile is just another fad
22
Toolset for Agile Process
The objective of agile development tools is to help in one or more activities in agile development. Due to use of such tools the operational development software can be created rapidly.
The agile tool set consist of automated support for project planning, use case development, and requirements gathering, code generation and testing.
Examples :
1) Actif Extreme :- This tool is developed by Microtool. It provides the support for various technical activities.
2) Ideogramic UML :- it is developed by Ideogramic. This tool is used with agile process.
3) Together Tool Set :- it is distributed by borland. It provides support for technical activities within the XP(extreme programming) and other agile process.
23
eXtreme Programming
The most widely used agile process, originally proposed by Kent Beck
in 2004. It uses an object-oriented approach.
XP Values :- Beck defined the set of five values that serve as a basis for the work performed in the xp. The values are,
1) Communication :- The effective communication must be established between software developers and stake holders in order to convey the important concepts and to get the important feedback.
2) Simplicity :- XP focuses on current needs instead of future needs to incorporate in design.
3) Feedback:- The feedback for software product can be obtained from the developers of software, customers, and other software team members.
4) Courage:- The agile xp team must be disciplined to design the system today, recognize the future requirements and make changes dramatically as per demand.
5) Respect :- by following the above states XP values the agile team can win the respect of stakeholders.
Extreme Programming (XP)
• XP Planning
• Begins with the listening, leads to creation of “user stories” that describes
required output, features, and functionality. Customer assigns a value(i.e., a
priority) to each story.
• Agile team assesses each story and assigns a cost (development weeks. If more
than 3 weeks, customer asked to split into smaller stories)
• Working together, stories are grouped for a deliverable increment next
release.
• A commitment (stories to be included, delivery date and other project
matters) is made. Three ways: 1. Either all stories will be implemented in a few
weeks, 2. high priority stories first, or 3. the riskiest stories will be implemented first.
• After the first increment “project velocity”, namely number of stories
implemented during the first release is used to help define subsequent
delivery dates for other increments. Customers can add stories, delete
existing stories, change values of an existing story, split stories as development
work proceeds
26
• XP Design ( occurs both before and after coding as refactoring is encouraged)
• Follows the (keep it simple) principle Nothing more nothing less than the story.
• Encourage the use of CRC (class-responsibility-collaborator) cards in an object-oriented
context. The only design work product of XP. They identify and organize the classes that
are relevant to the current software increment.
• For difficult design problems, suggests the creation of ―spike solutions‖—a design
prototype for that portion is implemented and evaluated.
• Encourages ―refactoring‖—an iterative refinement of the internal program design. Does
not alter the external behavior yet improve the internal structure. Minimize chances of
bugs. More efficient, easy to read.
• XP Coding
• Recommends the construction of a unit test for a story before coding commences. So
implementer can focus on what must be implemented to pass the test.
• Encourages ―pair programming‖. Two people work together at one workstation. Real time
problem solving, real time review for quality assurance. Take slightly different roles.
• XP Testing
• All unit tests are executed daily and ideally should be automated. Regression tests are
conducted to test current and previous components.
• ―Acceptance tests‖ are defined by the customer and executed to assess customer visible
functionality
Industrial XP
The industrial XP can be defined as the organic evolution of XP. It is customer centric. It has
expanded role for customers and advanced technical practices.
Various new practices that are as follows:-
1) Readiness Assessment :- in this assessment following issues are assessed-
- Proper Environment must be available to support XP.
- Team should contain appropriate stakeholders.
- The organization should support quality programs and continuous improvement.
- The organization culture should support new values of agile team.
2) Project Community :- Skilled and efficient people must be chosen as the agile team
members for the success of the project.
- The team is referred as the community when extreme programming approach is
considered.
The project community consist of technologies, customers, and other stakeholders who play
the vital role for the success of the project. The role of the community members must be
explicitly defined.
3) Project Chartering :- it means assessing the justification for the project as a business
application. That means, the IXP team assess whether the project satisfies the goals and
objectives of organization.
4) Test Driven Management :- for assessing the state of project and its progress the
industrial XP needs some measurable criteria. In test driven management the project is
tested with the help of these measurable criteria.
5) Retrospectives :- After delivering the software increment, the specialized review is
conducted which is called as retrospective. The intension of this is to improve the
industrial XP process.
6) Continuous learning :- the team members are inspired and encouraged to learn
new methods and techniques that can improve the quality of product.
XP and Scrum
• Scrum teams typically work in iterations
(called sprints) that are from two weeks to
one month long.
• Scrum product owner prioritizes the
product backlog but the team determines
the sequence in which they will develop
• Scrum teams do not allow changes into
their sprints.
• Scrum doesn't prescribe any engineering
practices
• XP teams typically work in iterations that
are one or two weeks long.
• XP teams work in a strict priority order.
• XP teams are much more amenable to
change within their iterations.
• XP prescribes engineering practices,
particularly things like test-driven
development, the focus on automated
testing, pair programming, simple design,
refactoring.
Scrum Methodologies
32
User Story Definition –
A user story describes functionality that will be valuable to either a user or purchaser of a system or software.
A User Story Is
• An agreements between customers and team members to discuss detailed requirements during an iteration
• Emphasize verbal rather than written communication. • Right size for planning
A User Story Is Not
• A Requirement document, requirement needs to be captured by discussion , if the discussion is not possible then should be augmented by documentation
User Story
33
• Your user story needs to have, at a minimum, the following parts
✓ Title: <a name for the user story>
✓ As a <user or persona>
✓ I want to <take this action>
✓ So that <I get this benefit>
• The story should also include validation steps. That step is worded as follows:
✓ When I <take this action>, this happens <description of action>
34
Scrum
• Scrum is a simple yet incredibly powerful set of principles and practices that help teams deliver products in short cycles, enabling fast feedback, continual improvement, and rapid adaptation to change. As the leading Agile development framework, Scrum has predominantly been used for software development, but it is also proving to be effective in efforts far beyond -- Source: Scrum Alliance
• Scrum is an iterative and incremental agile software development framework for managing software projects and product or application development. Its focus is on "a flexible, holistic product development strategy where a development team works as a unit to reach a common goal" as opposed to a "traditional, sequential approach". – Source: Wikipedia
• In short :
Scrum is an agile process that focuses on delivering the highest business value in the shortest time thereby rapidly and repeatedly inspect actual working software.
The business sets the priorities. Scrum teams self-organize to determine the best way to deliver the highest priority features. Time-boxed for two to four weeks, anyone can see real working software and decide to release it as is or continue to enhance it for another sprint.
What is Scrum?
35
Scrum
Picture source: www.agileforall.com
36
Scrum
• With inputs from business stakeholders, the Product Owner creates a prioritized business wish list called a product backlog
• Based on priorities set by product owner, the Scrum Team takes up a small chunk from the top of the product backlog, in sprint backlog, and decides how to implement those pieces
• Scrum team has a time-boxed period — a Sprint (usually two to four weeks) — to complete its work, but it meets each day to assess its progress (daily Scrum)
• The ScrumMaster keeps the team focused on its goal throughout.
• At sprint end, the work outcome is potentially shippable: ready to be handed over to customer, put on a store shelf, or show to a stakeholder
• A sprint review and retrospective concludes a sprint
• The next sprint begins with another chunk of the product backlog
Framework –
37
Scrum Framework –
• Product Owner
• Scrum Master
• Team
Roles
• Sprint Planning
• Daily Scrum Meeting
• Sprint Review
• Sprint Retrospective
Ceremonies
• Product Backlog
• Sprint Backlog
• Sprint Burndown Chart
Artifacts
38
Scrum Framework –
• Product Owner
• Scrum Master
• Team
Roles
• Sprint Planning
• Daily Scrum Meeting
• Sprint Review
• Sprint Retrospective
Ceremonies
• Product Backlog
• Sprint Backlog
• Sprint Burndown Chart
Artifacts
39
Scrum Roles 1. Product Owner – Responsibilities
• Define the features of the product
• Work on a shared vision as he represents the business stakeholders
• Manage and Prioritize features according to market value in Product Backlog
• Accept / reject the work at the end of each iteration
• Managing the release plan
• Responsible for the profitability of the product (ROI)
• Decide on release date and content
40
2. Scrum Master – Responsibilities
• empower and shepherd the Scrum team
• Represents management to the project
• Keeps the process moving by enacting Scrum values and practices
• Removes impediments
• Ensure that the team is fully functional and productive
• Enable close cooperation across all roles and functions
• Shield the team from external interferences
• Socialising Scrum to the greater organisation
41
3. Team – Responsibilities
• Typically a team of 5-9 people
• They are usually cross-functional: Programmer, QA, UX designers, Analyst, etc.
• Estimate size of backlog items
• Committing to increments of deliverable software and delivering it
• Tracks own progress
• Is self-organising—but accountable to the Product Owner for delivering as promised
42
Scrum Framework –
• Product Owner
• Scrum Master
• Team
Roles
• Sprint Planning
• Daily Scrum Meeting
• Sprint Review
• Sprint Retrospective
Ceremonies
• Product Backlog
• Sprint Backlog
• Sprint Burndown Chart
Artifacts
43
Scrum Artifacts Artifact stages –
44
1. Product Backlog –
• list of work items that need to be done over time. • Items may be added to the backlog by anyone • only the Product Owner has the right to determine the order in which they will be executed by the team and he negotiates this with stakeholders and the team. •The Product Backlog is a living document and requires constant grooming to keep it current and useful. •Many new items will be added over time; existing items are disaggregated to multiple, smaller items; some items may be removed on realising that a desired feature is no longer needed.
Good Product Backlog contains:
Good product backlogs should be DEEP (Coined by Roman Pichler and Mike)
• Detailed appropriately
• Emergent
• Estimated
• Prioritized
45
Contents of Product Backlog –
Type Example
Feature As a recruiter I want to search candidates using keywords so that I can find the suitable job seeker
Change As a job seeker I want default ordering job search results to be by freshness rather than location so that its easier to see latest jobs first
Defects Please fix defect #148 so that space characters in search wont crash the system
Technical Improvement Upgrade to the latest version of Internet Information Server
Knowledge Acquisition Create integration prototype using MSSQL Server and Salesforce.com and run performance test to check real time integration speed and reports.
48
2. Sprint Backlog –
•The Sprint backlog is more of like a task board •It the physical representation of the list of work that the Scrum team have committed to do during the current sprint. •It tells the whole team and anyone else what work they have planned or the sprint and their current status.
In short:
• The Sprint Backlog defines the work team will perform to turn selected Product Backlog items into a “Done” Increment
• The list emerges during the Sprint. • Every team member takes responsibility / ownership of each task in progress task • Each Tasks has information about estimated amount of work remaining on the
task on any given day during the Sprint
49
Sprint Backlog Management –
• Individuals take up work of their own choosing. Work is never assigned
• Estimated work remaining is updated on daily basis
• Any team member can add, delete or change the sprint backlog
• If work is unclear, define a sprint backlog item with a larger amount of
time and break it down later
• Update work remaining as more becomes known
51
Scrum Definition of Done –
• Everyone must understand what done means
• This varies significantly per Scrum Team, members must have a shared
understanding of what it means for work to be complete, to ensure
transparency
• This guides Development Team in knowing how many Product Backlog items
it can select during a Sprint Planning Meeting.
• The purpose of each Sprint is to deliver Increments of potentially releasable
functionality that adhere to Definition of “Done.”
• Definition of Done may change during the project
52
3. Sprint Burndown Chart –
The sprint burndown chart helps the Scrum team to monitor its progress and
works as an indicator of whether it will meet its commitment at the end of the
sprint.
It requires teams to estimate the duration of each task in hours and on a daily
basis to chart the total remaining hours for all uncompleted tasks.
Helps to:
• Estimate new tasks and re-estimating in-progress tasks requires effort
• Re-estimate inaccurate tasks
• Completion of tasks delivers no value; only completed stories (features) deliver value
53
Sprint Burndown Chart Sample –
Picture source: Wikipedia
54
Scrum Framework –
• Product Owner
• Scrum Master
• Team
Roles
• Sprint Planning
• Daily Scrum Meeting
• Sprint Review
• Sprint Retrospective
Ceremonies
• Product Backlog
• Sprint Backlog
• Sprint Burndown Chart
Artifacts
Scrum Ceremonies 1. Sprint Planning –
• The Team and the Product Owner collaborate to help the Team determine how much Product Backlog it can turn into functionality during the upcoming Sprint.
• The Team create plans (Sprint Backlog) by identifying tasks for converting selected Product Backlog into functionality
• Team selects items from the product backlog that they can commit to complete within a Sprint
• Sprint backlog is created
Tasks are identified and each is estimated (1-16 hours)
Collaboratively, not done alone by the Scrum Master
• High-level design is considered
55
2. Sprint Planning –
56
• Product Backlog
• Team Capacity
• Business Conditions
• Current Product
• Technology
• Analyse and evaluate product
backlog
• Select sprint goal
• Decide how to achieve sprint
goal (design)
• Create sprint backlog (tasks)
from product backlog items
(user stories / features)
• Estimate sprint backlog in
hours
• Sprint Goal
• Sprint Backlog
Inputs Sprint Planning Meeting Output
Sprint prioritization
Sprint planning
Sprint Planning –
57
Prioritizes
Product
Backlog
Develops
Sprint Backlog
Facilitates
3. Daily Scrum Meeting –
•The team meets daily to communicate and synchronise its work.
• Since the team is collaborating, it’s essential to ensure that continued project progress and avoiding work blockages.
•The team continuously assess its own progress towards achieving its sprint goal and NOT report progress to the ScrumMaster or Product Owner or anyone else.
58
Helps to: Parameters
• Fine-grain coordination
• Daily commitment
• Raising impediments
• Peer pressure
• Access Progress towards sprint goal
• Helps avoid other unnecessary meetings
• Daily 15-minutes Stand-up
• Not for problem solving
Only team members, Scrum Master, Product Owner can talk
Comprises of:
Story
To Do
WIP
Done
Impediment
Daily Scrum Meeting –
59
Observes
1. What have you done yesterday?
Facilitates
2. What are you going to do today?
3. Are there any impediments in your
way?
60
3. Scrum Board
61
62
4. Sprint Review –
•The focus is the product the team is building.
•While it does include a demonstration of the new features the team has completed
during the sprint,
•its primary purpose is to inspect what the team has delivered and gather feedback
from the attendees to adapt the plan for the succeeding sprint.
63
Helps to:
• Team presents to product owner, stakeholders and scrum master what it accomplished during the sprint
• Typically takes the form of a demo of new features
• It’s usually Informal
2-hour prep time rule
No slides
• Whole team participates
• Audience – Invite the world!!
Sprint Review –
64
Provides
feedback
Provides
feedback
Presents the new
development
Facilitates
5. Sprint Retrospective –
•final meeting of the sprint.
• It follows immediately after the sprint review and should never be omitted.
•The retrospective is focussed on the process—the way in which the Scrum
team is working together, including their technical skills and the software
development practices and tools they are using
65
Parameters:
• Periodically take a look at what is and is not working
• Done after every sprint
• Participants
Scrum Master
Team
Product owner (Optional)
Sprint Retrospective –
66
Observes
1. Start doing
Facilitates
2. Continue doing
3. Stop doing
Agile Practises
Test Driven Development
Test Driven Dvelpoment (TDD)
• The basic tenets are developing and implemen
ting
• unit tests before writing a line of code
• Unit tests will and must fail up front
• Code is developed after the test is developed.
• A unique idea that is still foreign to many
developers
TDD steps
• Quickly add a test just enough code to fail test
• Run testsuite to ensure test fails (may choose to run a subset of suite)
• Update your functional code to ensure new test passes
• Rerun test suite and keep updating functional code until test passes
• Refactor and move on
TDD and agile
• TDD implies agile.
• Strong emphasis on testing
• Tests should span entire breadth of codebase
• Once all software is ready for delivery, all tests
should pass
• A unique way to address modern challenges in
software development
Myths about TDD
• Myth: TDD is ok for small projects involving a handful of folks but won't sc
ale to large projects involving scores or hundreds of people.
• Answer: Not true.
Kent Beck worked on a pure TDD project developed in
• Smalltalk.
• 4 years and 40 man years of effort resulting in 250K lines
• of func code and 250K lines of test code
• 4,000 tests run in under 20 mins
• Full suite runs several times a day
TDD benefits
• Shortens the programming feedback
• Provides detailed (executable) specifications
• Promotes development of highquality code
• Provides concrete evidence that your code works
• Requires developers to prove it with code
• Provides finelygrained, concrete feedback (in mins)
• Ensures that your design is clean by focusing on creation of
operations that are callable and testable
• Supports evolutionary development
Refactoring
• Refactoring is:
– restructuring (rearranging) code...
– ...in a series of small, semantics-preserving transformations (i.e. the
code keeps working)...
– ...in order to make the code easier to maintain and modify
• Refactoring is not just any old restructuring
– You need to keep the code working
– You need small steps that preserve semantics
– You need to have unit tests to prove the code works
• There are numerous well-known refactoring techniques
– You should be at least somewhat familiar with these before inventing
your own
77
When to refactor
• You should refactor:
– Any time that you see a better way to do things
• “Better” means making the code easier to understand
and to modify in the future
– You can do so without breaking the code
• Unit tests are essential for this
• You should not refactor:
– Stable code (code that won‟t ever need to change)
– Someone else‟s code
• Unless you‟ve inherited it (and now it‟s yours)
78
The refactoring environment
• Traditional software engineering is modeled after traditional
engineering practices (= design first, then code)
• Assumptions:
– The desired end product can be determined in advance
– Workers of a given type (plumbers, electricians, etc.) are interchangeable
• “Agile” software engineering is based on different assumptions:
– Requirements (and therefore design) change as users become acquainted
with the software
– Programmers are professionals with varying skills and knowledge
– Programmers are in the best position for making design decisions
• Refactoring is fundamental to agile programming
– Refactoring is sometimes necessary in a traditional process, when the
design is found to be defective
Pair Programming
How does it Help? • Continuous Review.
• Less Defects caught early.
• Better Problem Solving.
• More Economical.
• “Pair-Pressure” ensures timely delivery.
• Rapid Hands-on Approach to Learning.
• Better Induction of new Team Members.
What is NOT pair programming?
• Splitting up the work
• Taking turns doing the work
• One person doing all the work
• Being located in different places
• Sitting at different computers
• (Exception – it‟s ok to use remote shared
desktop technology, such as VNC, if
absolutely necessary)
Continuous Integration
• software development practice
• members of a team integrate their work
frequently,
• usually each person integrates at least daily -
leading to multiple integrations per day.
• Each integration is verified by an automated
build (including test) to detect integration
errors as quickly as possible” – Martin Fowler
CI – What does it really mean?
• At a regular frequency (ideally at every commit), the system is:
• Integrated :All changes up until that point are combined into
the project
• Built: The code is compiled into an executable or package
• Tested: Automated test suites are run
• Archived” Versioned and stored so it can be distributed as is, if
desired
• Deployed: Loaded onto a system where the developers can
interact with it
CI - Workflow
CI – Benefits
• Immediate bug detection
• No integration step in the lifecycle
• A deployable system at any given point
• Record of evolution of the project
1-95
What is Scripted Testing?
• Small (but realistic) example:
• How to script and test this login?
(Functional tests only – not security!)
1-96
Sample test scripts (4 of “many”):
• Sample test script 1: – Launch the Login screen
– Enter User-id: “xyz”
– Enter Password: “zyx”
– Press <Enter>
– Expected result: login ok
• Sample test script 2: – Launch the Login screen
– Enter User-id: “xyz”
– Enter Password: “zyx”
– Click the “Login” button
– Expected result: login ok
• Sample test script 3: – Launch the Login screen
– Enter User-id: “”
– Enter Password: “zyx”
– Press <Enter>
– Expected: login rejected
• Sample test script 4: – Launch the Login screen
– Enter User-id: “”
– Enter Password: “zyx”
– Click the “Login” button
– Expected: login rejected
ET Workshop v. 1.20 -
Introduction ©2002 Amland Consulting 1-97
• Sample generic test script 1:
– Launch the Login screen
– Enter valid User-id
– Enter valid Password
– Press <Enter> or click button
– Expected result: login ok
• Sample generic test script 2:
– Launch the Login screen
– Enter invalid User-id
– Enter valid Password
– Press <Enter> or click button
– Expected result: login rejected
1-98
Sample test “Pattern” script (checklist)
• Input fields:
– Valid data
– Invalid data
– Length > max
– Length = max +1
– Length = max
– Length = max –1
– Combinations of above
– …
• Actions:
– Keyboard
– Buttons
– …
• Operations:
– Add, Modify, Inquiry, Delete • What to test for each…
– …
Manual v. automated
• Automation is cool, it gets respect … but …
– Automation is code
• like any code it will take time, have bugs, cause false
positives and require maintenance
• it will have an imperfect oracle
• Manual testing is tedious … but …
– It finds over 90% of the bugs in the system
Manual testing
• Scripted manual testing
– From rigid (click this button, enter this value) to
flexible (achieve this result)
– Requires preparatory work
– Scripts act as their own documentation
• Exploratory testing
– Minimizes preparatory work
– Documentation of testing is extra work
1-101
When to use Exploratory Testing?
• A common goal of exploration is to query for weak
areas of the program.
• Test team‟s resource consumption per week:
– 25% of the group‟s time developing new tests
– 50% executing old tests (including bug regression)
– 25% on exploratory testing
1-102
• When there is little or no specifications and / or requirements
• When you have little or no domain knowledge
• When you don‟t have time to specify, script and test
Uncertainty and Time Pressure!
1-103
• Exploratory Testing is extremely useful when
faced with software that is
– Untested
– Unknown or
– Unstable
• The tester must create a map of the
application as he goes on testing it.
1-104
• Take a more scripted approach when:
– There are little uncertainty about how to test
– New tests are relatively unimportant
– The need for efficiency and reliability in executing
tests is worth the effort of scripting
– We are prepared to pay the cost of documenting
and maintaining tests
Types of exploratory testing
• Freestyle
• Scenario
• Strategy
• Feedback
• Freestyle exploratory testing
– Ad hoc exploration of an application‟s features
– No rules, not necessary to account for coverage,
past tests, etc.
– Good for:
• familiarizing yourself with an application to prepare for
more sophisticated methods
• quick smoke tests, sometimes finds bugs
• Scenario-based exploratory testing
– An extension of traditional scenario testing
– Start with:
• user stories
• e2e scenarios
• test scenarios
– Then widen the scope and inject variation as you
execute the scenarios
• Strategy-based exploratory testing
– Freestyle testing combined with known bug finding
techniques
• documented strategies like boundary values and
combinatorial testing
• intuitive instinct from experience or familiarity with the
application
• Feedback-based exploratory testing
– Starts out freestyle until a test history is built up
– That feedback then guides future exploration
• Test history
• Coverage
• Churn
• …
– Tools are often an integral part of this type of
testing as they „remember‟ history for us
Obstacles to exploratory testing
• Where‟s the accountability?
• How do we track completeness?
• What metrics are important?