ISTQB Foundation Agile Tester 2014 Training, Agile SW Development

Objectives
 Build on ISTQB CTFL in the area of agile testing
 Prepare for the ISTQB CTFL – Agile Tester exam
ISTQB CTFL Agile Tester 2 November 17, 2014

Prerequisites
 ISTQB CTFL or equivalent
 Practical experience in SW testing

Notes
 Ask any time.
 Turn your cell silent.

References
 Foundation Level Extension Syllabus Agile Tester version 2014

Outline
 Agile Software Development
 Fundamental Agile Testing Principles, Practices and Processes
 Agile Testing Methods, Techniques and Tools

Agile Software Development
 The Fundamentals of Agile Software Development
 Aspects of Agile Approaches

Learning Objectives
 FA-1.1.1 (K1) Recall the basic concept of Agile software development
based on the Agile Manifesto
 FA-1.1.2 (K2) Understand the advantages of the whole-team approach
 FA-1.1.3 (K2) Understand the benefits of early and frequent feedback

Agile Testers Work Differently
 Testers must understand the values and principles that underpin Agile
projects.
 Testers are an integral part of a whole-team.
 Members in an Agile project communicate with each other early and
frequently, which helps with removing defects early and developing a
quality product.

Agile Manifesto
 In 2001, creators of most widely
used lightweight SW
development methodologies
agreed on a common set of
values and principles (Agile
Manifesto).

Agile Principles
 From the manifesto, 12 guiding principles were created.
 They form the foundation on which all agile methods are created.

Whole Team Approach
 Involves everyone with the knowledge and skills necessary to ensure
project success
 Includes customer representatives and business stakeholders who
determine product features
 3 – 9 members
 Co-located
 Daily stand-up meetings

Whole Team should be Cross
Functional

Power of 3
 The whole team is involved in any consultations or meetings in which
product features are presented, analyzed, or estimated.
 Involving testers, developers, and business representatives in all feature
discussions is known as the power of three.

Why Whole Team Approach?
 Promotes more effective and efficient team dynamics
 Enhancing communication and collaboration within the team
 Enabling the various skill sets within the team to be leveraged to the
benefit of the project
 Making quality everyone’s responsibility

Example: Tester Work with Others to
Achieve Desired Quality Levels
 Supporting and collaborating with business representatives to help them
create suitable acceptance tests
 Working with developers to agree on the testing strategy, and deciding on
test automation approaches
 Testers can thus transfer and extend testing knowledge to other team
members and influence the development of the product.

Early and Frequent Feedback
Iterations
in Agile
Projects
Early &
Continuous
Feedback
 Continuous integration is a way to provide rapid feedback.
 In sequential approach, customer often see the product when the project
is nearly completed.
 Too late to address customer issues effectively

Agile vs. Sequential Waterfall

By Getting Frequent Customer
Feedback, Agile Teams
 Can incorporate most new changes
 Focus on the features with the highest business value, or associated risk,
and these are delivered to the customer first
 Are managed better since the capability of the team is transparent to
everyone

Early and Frequent Feedback Benefits
 Avoiding requirements misunderstandings, which may not have been
detected until later in the development cycle when they are more
expensive to fix.
 Clarifying customer feature requests, making them available for customer
use early. This way, the product better reflects what the customer wants.
 Discovering (via continuous integration), isolating, and resolving quality
problems early.
 Providing information to the Agile team regarding its productivity and
ability to deliver
 Promoting consistent project momentum.

Exercise: Draw Something

Learning Objectives
 FA-1.2.1 (K1) Recall Agile software development approaches
 FA-1.2.2 (K3) Write testable user stories in collaboration with developers
and business representatives
 FA-1.2.3 (K2) Understand how retrospectives can be used as a mechanism
for process improvement in Agile projects
 FA-1.2.4 (K2) Understand the use and purpose of continuous integration
 FA-1.2.5 (K1) Know the differences between iteration and release
planning, and how a tester adds value in each of these activities

Aspects of Agile Approaches
(Methods)
Collaborative
User Story
Creation
Common
Agile
Practices
Retrospectives
Continuous
Integration
Release and
Iteration
Planning

An Agile Method is
To Give
Working
SW
Iterative
and
Incremental
Cooperative
Adaptive

An Agile Method is Not
 Compressing the project schedule
 Removing all existing SW development processes
 Throwing out all documentation
 Writing code up to the last minute
 An excuse for doing anything

Mostly Used Agile Methods
 Scrum
 Extreme Programming (XP)
 Lean SW Development
 Kanban
 Dynamic System Development Method (DSDM)
 Adaptive SW Development
 Crystal Methods
 Feature Driven Development
 Agile Unified Process

Extreme Programming
 Introduced by Kent Beck to deliver a financial system in 2 years which
previously had been undelivered over a number of years with a team of 30
 Described by 5 values, 14 principles and 13 development practices
 Many of the Agile approaches in use today are influenced by XP and its
values and principles.
 For example, Agile teams following Scrum often incorporate XP practices.

XP 5 Values Guiding Development
• Everyone is a part of the team.
• Face to face and daily communication Communication
• Start with simplest solution 1st
• Extra functionality can be added later
• Doing what is needed and asked for, but no more
Simplicity
• From the system
• From the team
• From the customer
Feedback
• Telling the truth and no excuses
• Refactoring
• Persistence
Courage
Respect • Respect other team members’ work

XP Additional Guiding 14 Principles
 Humanity
 Economics
 Mutual benefit
 Self-similarity
 Improvement
 Diversity
 Reflection
 Flow
 Opportunity
 Redundancy
 Failure
 Quality
 Baby steps
 Accepted responsibility

XP 13 Development Practices
 Sit together
 Whole team
 Informative workspace
 Energized work
 Pair programming
 Stories
 Weekly cycle
 Quarterly cycle
 Slack
 Ten-minute build
 Continuous integration
 Test first programming
 Incremental design

XP Rules
Managing
• Give the team a
dedicated open work space.
• Set a sustainable pace.
• A stand up meeting starts
each day.
• The project velocity is
measured.
• Move people around.
• Fix XP when it breaks.
Planning
• User stories are written.
• Release planning creates
the release schedule.
• Make frequent small
releases.
• The project is divided
into iterations.
• Iteration planning starts
each iteration.

XP Rules cont’d
Designing
• Simplicity
• Choose a system metaphor.
• Use CRC cards for design sessions.
• Create spike solutions to reduce
risk.
• No functionality is added early.
• Refactor whenever and wherever
possible.
Coding
• The customer is always available.
• Code must be written to
agreed standards.
• Code the unit test first.
• All production code is pair
programmed.
• Only one pair integrates code at a
time.
• Integrate often.
• Set up a dedicated integration
computer.
• Use collective ownership.

XP Rules cont’d
Testing
• All code must have unit
tests.
• All code must pass all unit
tests before it can
be released.
• When a bug is found tests
are created.
• Acceptance tests are run
often and the score
is published.

XP Project

XP Iteration

XP Development

XP Collective Ownership

Scrum
 An iterative, incremental methodology for project management.
 Scrum (as opposed to XP) does not dictate specific SW development
techniques (e.g., test first programming).
 In addition, Scrum does not provide guidance on how testing has to be
done in a Scrum project.
 Scrum is composed of:
 2 Backlogs
 5 Time boxes
 Definition of done
 3 Roles

Scrum cont’d

Scrum Roles
Product Owner
• Represents
customer
• Product
backlog
owner
• Not a team
leader
Scrum Master
• Ensures
scrum is
followed
• Resolves any
issues
• A coach and
not a team
leader
Team
• Develop and
test the
product
• Self organized
• Cross
functional
• No team
leader

Kanban (Visual Card or Board)
 A management approach sometimes used in Agile projects
 In a value-added chain, Kanban is used to:
 Manage the work in progress visually on a board
 Optimize the work by limiting the work in progress to match the team
throughput (WIP limit)

Kanban Board
 Each column shows a station (a set of related activities)
 Items to be produced or tasks to be processed are symbolized by tickets
moving from left to right across the board through the stations.

Work-in-Progress Limit and Lead Time
 WIP limit is a limit of parallel activities controlled by max number of
tickets allowed for a station.
 Whenever a station has a free capacity, it pulls tickets from the previous
one.
 Lead time for the complete value stream minimization is main objective of
Kanban by optimizing the continuous flow of tasks.

Kanban vs. Scrum
 In both, visualizing active tasks provides transparency of content and
progress of tasks.
 Tasks not yet scheduled are waiting in a backlog and moved onto the board as
soon as there is new space (production capacity) available.
 Iterations or sprints are optional in Kanban.
 Allows releasing its deliverables item by item, rather than as part of a release
 Timeboxing as a synchronizing mechanism is optional.

Poor Specifications
 A major reason for project failure
 They result from users’ lack of
insight into their true needs,
absence of a global vision for the
system, redundant or
contradictory features, and other
miscommunications.
 Specifications are poor when the
vision of a feature is not shared
among developers, testers and
business representatives.
 Lacks the power of 3 

Power of 3 is Achieved by
In Sequential Development
 By formal reviews
 After requirements are written
In Agile Development
 By informal reviews
 While requirements are written
 In the form of user stories
 That capture requirements from the
prospective of:
 Developers
 Testers
 Business representatives

User Stories
 Document minimal requirements
 Functional & non-functional
 Should include acceptance
criteria defined in collaboration
between business
representatives, developers, and
testers
 Acceptance criteria extend vision
of developers/testers about the
feature that business
representatives will validate.

Testers Improve User Stories
 Identifying missing details or non-functional requirements
 Asking business representatives open-ended questions
 Proposing ways to test the user story
 Confirming the acceptance criteria
 Collaborative authorship of the user story can use brainstorming and mind
mapping.
 Testers may use the INVEST technique to assess a user story.

INVEST
 Created by Bill Wake as a reminder of the characteristics of a good quality
user story.

A User Story is the Conjunction of
3C’s

Retrospective
 A meeting held at the end of each
iteration/increment
 To discuss:
 What went well?
 What can be improved?
 How to improve?
 If regularly conducted with
appropriate follow up, they are
critical to self-organization and
continuous improvement.

Too Many to Improve
 Retrospectives can improve test effectiveness, test efficiency, test cases
quality and team satisfaction.
 Retrospectives can address testability of applications, user stories,
features or system interfaces.
 RCA can drive and decide improvements.
 Few improvements per iteration == Continuous improvement @
sustainable pace == Adaptive Agile method

Retrospective Organization
 Agile method dependent
 Attended by team (testers are part of team) + business representatives
 Testing occurs every iteration and vital to team success.
 Testers should bring testing prospective into retrospectives.
 Facilitators organize and run retrospective meetings.
 Team may invite other participants

Retrospective KSF’s
 All participants can provide input on any activity
 An agreement must be done when anything can be discussed outside a
retrospective.
 Mutual trust within the team
 Professional environment
 It is about improvement not personal attacks.
 Retrospective is a kind of review. Its KSF’s are same those of reviews.

Need for Continuous Integration (CI)
 Delivery of a product increment requires reliable, working, integrated SW
at the end of every sprint (increased risks).
 CI aims at merging and integrating changes @ least once a day.
 CM, compilation, SW build, deployment, and testing are wrapped into a
single, automated, repeatable process (decreased risks).
 Defects are detected more quickly.

CI Activities (Automated and Daily)
Static Code Analysis
Compile
Unit Test
Deploy
Integrate Test
Report

Good CI
 Allows Agile testers to run automated tests regularly to send quicker
feedback about code quality to team
 Visualizes test results to all team members by integrating reports
 Its automated regression tests covers as much functionality as possible,
including user stories delivered in the previous iterations
 Supports building large integrated systems
 Manual tests can be focused on new features, changes and confirmation
testing.

CI Needs Build Tools
 To run unit and integration tests
 To run additional static and dynamic tests
 To measure and profile performance
 To extract and format documentation from the source code
 To facilitate manual quality assurance processes

CI Needs Build Tools cont’d
 Can be linked to automatic
deployment tools (can fetch build
from CI/build server and deploy it
into one or more environments)
 This continuous application of QC
improves product quality and
reduces delivery time by
replacing the traditional practice
of applying quality control after
completing all development.

CI Benefits
 Earlier detection and easier RCA of integration problems and conflicting
changes
 Regular and quick feedback on code and improvement decisions
 Keeps the version of SW being tested in a day of the version being
developed
 Reduces regression risk associated with refactoring and schedule risks
associated with big-bang integration
 Provides confidence
 Visualizes product increments progress
 Encourages developers and testers
 Constant availability of executable SW throughout the sprint for testing,
demonstration, or education purposes
 Reduces repetitive manual testing activities

CI Risks and Challenges
 CI tools have to be introduced and maintained.
 CI process must be defined and established.
 Test automation requires additional resources and can be complex to
establish.
 Test coverage is essential to achieve automated testing advantages.
 Teams sometimes over-rely on unit tests and perform too little system and
acceptance testing.

CI Tools
 Testing tools, build automation tools and version control tools

Agile Planning
 Planning in ongoing
 In Agile lifecycles, there are 2 types of planning:
 Release planning
 Iteration planning

Release Planning
 Looks ahead to the release of a product
 Often a few months ahead of the start of a project
 Defines/re-defines the product backlog
 May involve refining larger user stories into smaller ones
 Business representatives with team establish/prioritize user stories for the
release
 Basis for a test approach and test plan spanning all iterations
 Based on these user stories, project and quality risks are identified and a
high-level effort estimation is performed.
 Release plans are high-level.

Testers in Release Planning
 Defining testable user stories, including acceptance criteria
 Participating in project and quality risk analyses
 Estimating testing effort associated with the user stories
 Defining the necessary test levels
 Planning the testing for the release

Iteration Planning
 After release planning for iteration 1
 Looks ahead to an iteration end and concerned with iteration backlog
 Team selects user stories, elaborates them, performs risk analysis on them and
estimates the work needed for them.
 A user story can be refused by the team if vague and the business
representatives fail to clarify it.
 Number of stories selected depends on established team velocity and size of
selected user stories.
 Selected stories are broken into tasks carried out by the team in an iteration.

Testers in Iteration Planning
 Participating in the detailed risk analysis of user stories
 Determining the testability of the user stories
 Creating acceptance tests for the user stories
 Breaking down user stories into tasks (particularly testing tasks)
 Estimating testing effort for all testing tasks
 Identifying functional and non-functional aspects of the system to be tested
 Supporting and participating in test automation at multiple levels of testing

Release and Iteration Planning
Address Test Planning
 Testing scope (extent of testing and test goals)
 The team members who will carry out the test activities.
 Test environment and data needed (when need and expected changes)
 Scheduling functional and non-functional test activities (frequency,
dependency and relation to development activities)
 Project and quality risks to be addressed
 In addition, team estimation should consider time and effort needed to
complete the required testing activities.

Re-Planning Releases and Iterations
 Releases and iterations may change (adaptability).
 Release re-planning changes due to changes in individual user stories by
internal or external factors.
 Internal factors: delivery capabilities, velocity or technical issues
 External factors: new markets/opportunities, competitors or threats
 Iteration re-planning can change cause of a user story wrongly estimated
as simple but proven to be more complex.

Re-Planning Challenges Testers
 Understanding the big picture of a release for test planning purposes
 Having adequate test basis and test oracle in each iteration for test
development
 Embracing changes 
 Decisions about test strategies/documentation

Summary

ISTQB Foundation Agile Tester 2014 Training, Agile SW Development

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Similar a ISTQB Foundation Agile Tester 2014 Training, Agile SW Development

Similar a ISTQB Foundation Agile Tester 2014 Training, Agile SW Development (20)

Más de Amr Ali (ISTQB CTAL Full, CSM, ITIL Foundation)

Más de Amr Ali (ISTQB CTAL Full, CSM, ITIL Foundation) (20)

Último

Último (20)

ISTQB Foundation Agile Tester 2014 Training, Agile SW Development