This document provides an overview of agile software testing principles and processes. It begins with discussing the fundamentals of agile development, including the agile manifesto, principles, and common agile approaches like Scrum and Kanban. It then covers key differences between testing in traditional vs agile projects, such as integrated development and testing activities, reduced documentation, and different test levels. The document also discusses important agile testing practices like collaborative user story creation, retrospectives, continuous integration, and the involvement of testers in planning.

1. SoftwareTesterTraininig
[AgileExtension]
Based on ISTQB CTAE Syllabus
Presented by :
DavisThomas K

2. Waterfall vs
Agile
Methodology

3. Iterations

4. Chapter 01
AgileSoftware
Development
 1.1The Fundamentals of Agile Software
Development
 1.2 Aspects of Agile Approaches

5. 1.AgileSoftware
Development
1.1The Fundamentals
ofAgile
Software
Development
Topics
 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

6. What comes to your mind of thinking agile ?

7. What comes to
your mind of
thinking agile ?
 1. No Design is required
 2. No Documentation is required
 3. No managers needed
 4. No Planning is required
 5. Iterative development
 6. Incremental development
 7. Faster delivery
 8.Agile is a silver bullet
 9. Agile is undisciplined
 10. Agile requires a lot of rework
 11. Agile is anti-architecture

8. Agile
Manifesto.

9. Agile
Principles.
Principles behind the Agile Manifesto
We follow these principles:
Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software.
Welcome changing requirements, even late in
development. Agile processes harness change for
the customer's competitive advantage.
Deliver working software frequently, from a
couple of weeks to a couple of months, with a
preference to the shorter timescale.
Business people and developers must work
together daily throughout the project.
Build projects around motivated individuals.
Give them the environment and support they need,
and trust them to get the job done.

10. Agile
Principles…
The most efficient and effective method of
conveying information to and within a development
team is face-to-face conversation.
Working software is the primary measure of progress.
Agile processes promote sustainable development.
The sponsors, developers, and users should be able
to maintain a constant pace indefinitely.
Continuous attention to technical excellence
and good design enhances agility.
Simplicity--the art of maximizing the amount
of work not done--is essential.
The best architectures, requirements, and designs
emerge from self-organizing teams.
At regular intervals, the team reflects on how
to become more effective, then tunes and adjusts
its behavior accordingly.

11. ASample
testing process
inAgile

12. Agile model vs
Non-Agile
models
 Flexible
 Success is measured against business value , not conformation to
plan
 Leadership vs Dictatorship
 Changes are welcomed
 Less documentation
 People oriented
 Minimum upfront planning

14. 1.1.2Whole-Team
Approach
 Whole-Team Approach orTeam based approach
 Collaborative , Everyone is kept responsible
 Members cannot operate in isolation
 Willing to switch roles / responsibilities
 Developers and testers are supporting each other
 Power of three” is a collaborating concept which involves developers,
testers and business representatives in discussing and finalizing the
features to work on, in future.
Its benefits include:
1. Enhancing communication and collaboration within the team .
2. Enabling the various skill sets within the team to be leveraged to the
benefit of the project
3. Making quality everyone’s responsibility

15. 1.1.3 Early and
Frequent Feedback
The benefits of early and frequent feedback include:
 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.

16. Chapter 01
AgileSoftware
Development
 1.1The Fundamentals of Agile Software
Development
1.2 Aspects of AgileApproaches

17. 1.AgileSoftware
Development
1.2Aspects ofAgile
Approaches
Topics
 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

18. 1.2.1AgileSoftware
Development
Approaches
Extreme Programming
Scrum
Kanban

19. Extreme
Programming
 Extreme Programming was first developed by Kent Beck. XP is an
Agile software development framework guided by Agile
development practices, principles, and values.
 XP is a software development methodology which is intended to
improve software quality and responsiveness to changing
customer requirements.
 Extreme Programming improves a software project in five
essential ways; communication, simplicity, feedback, respect,
and courage

20. Extreme
Programming
 XP teams typically work in iterations that are one or
two weeks long
 As long as the team hasn’t started work on a particular
feature, a new feature of equivalent size can be
swapped into the XP team’s iteration in exchange for
the unstartled feature. [They allow change to the
sprints]
 Extreme Programming teams work in a strict priority
order. Features to be developed are prioritized by the
customer
 XP prescribe any engineering practices; like automated
testing, pair programming, simple design, refactoring,
TDD.

21. Kanban
 Visualize the workflow
- Split the work into pieces, write each item on a card
and put on the wall
-- Use named columns to illustrate where each item is
in the workflow.
 Limit WIP (work in progress) – assign explicit limits to
how many items may be in progress at each workflow
state. ·
Measure the lead time (average time to complete one
item, sometimes called “cycle time”), optimize the
process to make lead time as small and predictable as
possible.

22. Kanban Board
 Kanban Board:The value chain to be managed is visualized by a
Kanban board. Each column shows a station, which is a set of
related activities, e.g., development or testing.The items to be
produced or tasks to be processed are symbolized by tickets
moving from left to right across the board through the stations.

23. Scrum
 Sprint
 Product Increment [releasable/shippable product ]
 Product Backlog
 Sprint Backlog
 Definition if Done
 Time boxing
 Transparency
Roles - Scrum Master , Product Owner and Development team
Ceremonies : Sprint Planning,The “Daily Stand-up” , Sprint
Retrospective, Sprint Review.

25. .2.2Collaborative
UserStoryCreation
 User stories
 Acceptance criteria

The tester may use the INVEST technique [INVEST]
: Independent ,Negotiable ,Valuable , Estimable , Small ,Testable

26. According to the 3C concept [Jeffries00], a user story is the conjunction of three elements:
Card:The card is the physical media describing a user story. It identifies the requirement, its criticality,
expected development and test duration, and the acceptance criteria for that story.The description has to be
accurate, as it will be used in the product backlog.
Conversation:The conversation explains how the software will be used.The conversation can be
documented or verbal.Testers, having a different point of view than developers and business representatives
,bring valuable input to the exchange of thoughts, opinions, and experiences.Conversation begins during the
release-planning phase and continues when the story is scheduled.
Confirmation:The acceptance criteria, discussed in the conversation, are used to confirm that the story is
done.These acceptance criteria may span multiple user stories. Both positive and negative tests should be
used to cover the criteria.
During confirmation, various participants play the role of a tester. These can include developers as well as
specialists focused on performance, security, interoperability, and other quality characteristics.To confirm a
story as done, the defined acceptance criteria should be tested and shown to be satisfied.

27. 1.2.3
Retrospectives
 InAgile development, a retrospective is a meeting held at the end
of each iteration to discuss what was successful, what could be
improved, and how to incorporate the improvements and retain
the successes in future iterations
 Retrospectives cover topics such as the process, people,
organizations, relationships, and tools.
 Retrospectives can result in test-related improvement decisions
focused on test effectiveness, test productivity, test case quality,
and team satisfaction. They may also address the testability of
the applications, user stories, features, or system interfaces. Root
cause analysis of defects can drive testing and development
improvements.
This allows for continuous improvement at a sustained pace.

28. 1.2.3
Retrospectives

29. 1.2.4Continuous
Integration
 Delivery of a product increment requires reliable, working, integrated
software at the end of every sprint.Continuous integration addresses
this challenge by merging all changes made to the software and
integrating all changed components regularly, at least once a day.
 Since developers integrate their work constantly, build constantly, and
test constantly, defects in code are detected more quickly.

30. A continuous integration process consists of the following automated activities:
1. Static code analysis: executing static code analysis and reporting results
2. Compile: compiling and linking the code, generating the executable files
3. Unit test: executing the unit tests, checking code coverage and reporting test results
4. Deploy: installing the build into a test environment
5. Integration test: executing the integration tests and reporting results
6. Report (dashboard): posting the status of all these activities to a publicly visible location or emailing status to
the team

31. Continuous integration can provide the following benefits:
1. Allows earlier detection and easier root cause analysis of integration problems and conflicting changes
2. Gives the development team regular feedback on whether the code is working
3. Keeps the version of the software being tested within a day of the version being developed
4. Reduces regression risk associated with developer code refactoring due to rapid re-testing of the code base
after each small set of changes
5. Provides confidence that each day’s development work is based on a solid foundation
6. Makes progress toward the completion of the product increment visible, encouraging developers and testers
7. Eliminates the schedule risks associated with big-bang integration
8. Provides constant availability of executable software throughout the sprint for testing, demonstration, or
education purposes
9. Reduces repetitive manual testing activities
10. Provides quick feedback on decisions made to improve quality and tests

32. Risks and challenges:
1. Continuous integration tools have to be introduced and maintained
2. The continuous integration process must be defined and established
3. Test automation requires additional resources and can be complex to establish
4. Thorough test coverage is essential to achieve automated testing advantages
5. Teams sometimes over-rely on unit tests and perform too little system and acceptance testing

33. 1.2.5 Release and
Iteration Planning
 Planning is an on-going activity, and this is the case in
Agile lifecycles as well.
 ForAgile lifecycles, two kinds of planning occur, release
planning and iteration planning.


34. Release Planning
 Release plans are high-level.
 Release planning - looks ahead to the release of a product
 Release planning defines and re-defines the product backlog
 Involve refining larger user stories into a collection of smaller
stories
 Release planning provides the basis for a test approach and test
plan spanning all iterations.
 In release planning, business representatives establish and
prioritize the user stories for the release, in collaboration with the
team
 Based on these user stories, project and quality risks are identified
and a high-level effort estimation is performed

35. Release Planning
[Involvement of
testers]
Testers are involved in release planning and especially add value in
the following activities:
1. Defining testable user stories, including acceptance criteria
2. Participating in project and quality risk analyses
3. Estimating testing effort associated with the user stories
4. Defining the necessary test levels
5. Planning the testing for the release

36. Iterative Planning/
Sprint planning
 After release planning is done, iteration planning for the first
iteration starts.
 Iteration planning looks ahead to the end of a single iteration and
is concerned with the iteration backlog.
 In iteration planning, the team selects user stories from the
prioritized release backlog, elaborates the user stories, performs a
risk analysis for the user stories, and estimates the work needed
for each user story
 The number of stories selected is based on established team
velocity and the estimated size of the selected user stories.After
the contents of the iteration are finalized, the user stories are
broken into tasks, which will be carried out by the appropriate
team members.

37. Iterative Planning
[Involvement of
testers]
Testers are involved in iterative planning and especially add value in
the following activities:
1. Participating in the detailed risk analysis of user stories
2. Determining the testability of the user stories
3. Creating acceptance tests for the user stories
4. Breaking down user stories into tasks (particularly testing tasks)
5. Estimating testing effort for all testing tasks
6. Identifying functional and non-functional aspects of the system
to be tested
7. Supporting and participating in test automation at multiple
levels of testing

38.  Release and iteration planning should address test planning as well as planning for development
activities.
Particular test-related issues to address include
The scope of testing, the extent of testing for those areas in scope, the test goals, and the reasons for
these decisions.
The team members who will carry out the test activities.
The test environment and test data needed, when they are needed, and whether any additions or changes
to the test environment and/or data will occur prior to or during the project.
The timing, sequencing, dependencies, and prerequisites for the functional and non-functional test
activities (e.g., how frequently to run regression tests, which features depend on other features or test
data, etc.), including how the test activities relate to and depend on development activities.
The project and quality risks to be addressed

39. Activities during Sprint Planning meeting
The Product Owner explains the release goal and walk through the release backlog
The Product Owner also explains the big picture and vision.
The team with the help of the Product Owner breaks down requirements into user stories, details the acceptance criteria
and sizes them.
The team also creates a high level architecture design.
The team plans for necessary infrastructure items and tools for the release (e.g., for test management, defect
management, test automation, and continuous integration)
Team creates the initial test strategy for various test levels to understand the test scope; technical risks and initial risks
analysis
The team establishes various metrics to measure the progress with the help of Scrum Master.
The brainstorms and creates the Definition of done.
The team creates the big visible task board

40. Chapter 02
Fundamental
AgileTesting
Principles,
Practices, and
Processes
 FA-2.1.1 (K2) Describe the differences between
testing activities in Agile projects and non-Agile
projects
 FA-2.1.2 (K2) Describe how development and
testing activities are integrated in Agile
projects
 FA-2.1.3 (K2) Describe the role of independent
testing in Agile projects

41. 2.1 The
Differences
between
Testing in
Traditional and
Agile
Approaches
 2.1.1Testing and Development Activities
 2.1.2 ProjectWork Products
 2.1.3Test Levels
 2.1.4Testing and Configuration Management
 2.1.5 Organizational Options for Independent
Testing

42. 2.1.1Testing
and
Development
Activities
 At the beginning of the project, there is a
release planning period.This is followed by a
sequence of iterations
 Once iteration scope is established, the
selected user stories are developed, integrated
with the system, and tested.
 Testers, developers, and business stakeholders
all have a role in testing
 In some Agile practices (e.g., Extreme
Programming), pairing is used. Pairing can
involve testers working together in twos to test
a feature

43.  Testers may also serve as testing and quality coaches within the team,
sharing testing knowledge and supporting quality assurance work within
the team.This promotes a sense of collective ownership of quality of the
product.
 The use of automated testing is one way of managing the amount of test
effort associated with change
 Because of the heavy use of test automation, a higher percentage of the
manual testing on Agile projects tends to be done using experience-based
and defect-based techniques such as software attacks, exploratory
testing, and error guessing

44. 2.1.2 Project
Work Products
 Project work products of immediate interest to
Agile testers typically fall into three categories:
 1. Business-oriented work products that describe what is
needed (e.g., requirements specifications) and how to use it
(e.g., user documentation)
 2. Development work products that describe how the
system is built (e.g., database entity relationship diagrams),
that actually implement the system (e.g., code), or that
evaluate individual pieces of code (e.g., automated unit
tests)
 3.Test work products that describe how the system is tested
(e.g., test strategies and plans), that actually test the system
(e.g., manual and automated tests), or that present test
results (e.g., test dashboards as discussed in Section 2.2.1)

45. What are Epics
inAgileTesting
 Business-oriented work products are categorized into user stories
and acceptance criteria
 Collection of complex user stories may be grouped as Epics, which
can be broken down further.

46. 2.1.3Test
Levels
 Test levels are test activities that are logically related, often by
the maturity or completeness of the item under test.
 During a iteration, here is the sequence of tests:
 Unit testing, typically done by the developer, but sometimes tester
also helps
 Feature acceptance testing, which may be broken into couple of
activities:
 Feature verification testing, which is often automated
 Feature validation testing, which involves everyone and mostly done
manually

47. 2.1.4Testing
and
Configuration
Management
 Agile projects often involve heavy use of automated tools to
develop, test, and manage software development.
 Developers use tools for static analysis, unit testing, and code
coverage. Developers continuously check the code and unit
tests into a configuration management system, using
automated build and test frameworks
 Developers use tools like SONAR for static analysis and code
coverage, JUnit for code coverage. Developers also use configuration
management tools like SVN, where they can check in source code,
unit tests.The configuration management tool will compile and build
the code with test frameworks.

48. There are 3 kinds of builds, namely Fast builds, Full build, and Push-To-QA build.
Fast build is triggered when it detects the source code changes, and it also detects complication, unit
testing or packaging errors. It also performs the static code analysis and provides a web based build report
on the code coverage.This build can be customized as per the team
Full Build is scheduled usually twice a day, it is same as fast build, and it deploys into DEV server
Push-To-QA build is scheduled On-demand and it deploy the latest DEV build to QA

49. 2.1.5
Organizational
Options for
Independent
Testing
 Agile teams are cross functional, meaning both testers and
developers will be one team
 In teams where they have full independence, assigning testers on-
demand may be helpful sometimes during the final days of the sprint.
This really make testers independent and become objective.
 Why not a independent tester ? Agile teams are small, stable,
develop long term relationships between them for the purpose
carrying test activities and developing automated test tools.

50. Chapter 02
Fundamental
AgileTesting
Principles,
Practices, and
Processes
 2.1 The Differences betweenTesting in
Traditional and Agile Approaches
 2.2 Status ofTesting in Agile Projects
 2.3 Role and Skills of aTester in an AgileTeam

51. 2.2 Status of
Testing inAgile
Projects
 FA-2.2.1 (K2) Describe the tools and techniques
used to communicate the status of testing in an
Agile project, including test progress and
product quality
 FA-2.2.2 (K2) Describe the process of evolving
tests across multiple iterations and explain why
test automation is important to manage
regression risk in Agile projects

52. 2.2.1
Communicating
TestStatus,
Progress, and
ProductQuality
 Burndown charts
 The daily stand-up meeting
 Customer satisfaction surveys
 Big visible task boards at the team location.

53. 2.2.2 Managing
Regression Risk
with Evolving
Manual and
AutomatedTest
Cases
Agile teams largely make incremental delivery, what that essentially
means is, as the number of iteration increases, the size of the product
also increases
Because complete repetition of all tests is seldom possible, especially
in tight-timeline , Extensive automation is highly recommended to
get rid of regression risk.The automation scripts are kept updated in
every iteration
 Additionally, apart from test automation, the following testing tests
may also be automated:
 Generating test data
 Test data loading
 Deployment of builds in test environments
 Back-out test environment
 Comparing data outputs

54. Chapter 02
Fundamental
AgileTesting
Principles,
Practices, and
Processes
 2.1 The Differences betweenTesting in
Traditional and Agile Approaches
 2.2 Status ofTesting in Agile Projects
 2.3 Role and Skills of aTester in an AgileTeam

55. 2.3 Role and
Skills of a
Tester in an
AgileTeam
 FA-2.3.1 (K2) Understand the skills (people,
domain, and testing) of a tester in an Agile
team
 FA-2.3.2 (K2) Understand the role of a tester
within an Agile team

56. 2.3 Role and
Skills of aTester
in anAgileTeam
2.3.1AgileTester
Skills
Testers in Agile teams should:
 Be positive and solution-oriented
 Display critical, quality-oriented, skeptical thinking about the product
 Actively acquire information from stakeholders (rather than relying entirely on
written specifications)
 Accurately evaluate and report test results, test progress, and product quality
 Work effectively to define testable user stories, especially acceptance criteria,
with customer representatives and stakeholders
 Collaborate within the team, working in pairs with programmers and other
team members
 Respond to change quickly, including changing, adding, or improving test
cases
 Plan and organize their own work

57. 2.3 Role and
Skills of aTester
in anAgileTeam
2.3.2 Role of
tester
The Role of aTester in an AgileTeam
Understanding, implementing, and updating the test strategy
Measuring and reporting test coverage across all applicable coverage
dimensions
Ensuring proper use of testing tools and Configuring, using, and managing test
environments and test data
Reporting defects and working with the team to resolve them
Coaching other team members in relevant aspects of testing
Ensuring the appropriate testing tasks are scheduled during release and
iteration planning
Actively collaborating with developers and business stakeholders to clarify
requirements, especially in terms of testability, consistency, and completeness
 Participating proactively in team retrospectives, suggesting and
implementing improvements

58. Test related
risk
 Agile organizations may encounter some test-related
organizational risks:
 Testers work so closely to developers that they lose the
appropriate tester mindset
 Testers become tolerant of or silent about inefficient, ineffective,
or low-quality practices within the team
 Testers cannot keep pace with the incoming changes in time-
constrained iterations

59. Chapter 3:
AgileTesting
Methods,
Techniques
andTools
 3.1 AgileTesting Methods
 3.2 Assessing Quality Risks and EstimatingTest Effort
 3.3Techniques in Agile Projects
 3.4Tools in Agile Projects

60. 3.1Agile
Testing
Methods
 FA-3.1.1 (K1) Recall the concepts of test-driven development,
acceptance test-driven development, and behavior-driven
development
 FA-3.1.2 (K1) Recall the concepts of the test pyramid
 FA-3.1.3 (K2) Summarize the testing quadrants and their
relationships with testing levels and testing types
 FA-3.1.4 (K3) For a givenAgile project, practice the role of a tester
in a Scrum team

61. Test-Driven
Development
 Test-driven development (TDD) is used to develop code guided by
automated test cases.
 The process for test-driven development is:
 Add a test that captures the programmer’s concept of the desired
functioning of a small piece of code
 Run the test, which should fail since the code doesn’t exist
 Write the code and run the test in a tight loop until the test passes
 Refactor the code after the test is passed, re-running the test to
ensure it continues to pass against the refactored code
 Repeat this process for the next small piece of code, running the
previous tests as well as the added tests

62. Acceptance
Test-Driven
Development
 Defines acceptance criteria and tests during the creation of user
stories
 Acceptance test-driven development creates reusable tests for
regression testing
 Acceptance test-driven development allows quick resolution of
defects and validation of feature behavior. It helps determine if
the acceptance criteria are met for the feature.
 format:
Given some initial context,
When an event occurs,
Then ensure some outcomes.

63. Behavior-
Driven
Development
 Behavior-Driven Development (BDD) is an evolution in the
thinking behindTestDrivenDevelopment and
AcceptanceTestDrivenPlanning.
 It presents a framework of activity based on three core principles:
 Business andTechnology should refer to the same system in the
same way - ItsAllBehaviour
 Any system should have an identified, verifiable value to the
business -WheresTheBusinessValue
 Up-front analysis, design and planning all have a diminishing
return - EnoughIsEnough

64. 3.1.2TheTest
Pyramid

65. 3.1.2TheTest
Pyramid

66. 3.1.3Testing
Quadrants,
Test Levels,
andTesting
Types


67. The four quadrants are described below:
•Quadrant Q1 – At unit level contains unitTests, technology facing, tests subject to full automation and
continuous integration.
•Quadrant Q2 – At system level, business facing, these are functional tests, examples, story tests, user
experience prototypes, and simulations based on the acceptance criteria, be manual or automated.
Created as a part of definition of done for a story
•Quadrant Q3 – At system or user acceptance level, business facing, contains tests exploratory testing,
scenarios, process flows, usability testing, user acceptance testing, alpha testing, and beta testing.These
tests are often manual and are user-oriented.
•Quadrant Q4 – At system or operational acceptance level, technology facing performance, load, stress,
and scalability tests, security tests, maintainability, memory management, compatibility and
interoperability, data migration, infrastructure, and recovery testing.These tests are often automated.

68. 3.1.4The Role
of aTester
Testers in Agile teams should:
Cross-functional
Self-organizing
Co-located
Collaborative
Empowered
Committed
Transparent
Credible
Open to feedback
Resilient – Respond to change

69. SprintZero
 Identify scope or the product backlog
 Develop system architecture [high-level prototypes ]
 Plan, acquire, and install needed tools
(e.g., for test management, defect management, test
automation, and continuous integration)
 Develop test strategy
 Perform an initial quality risk analysis
 Define test metrics
 Specify the definition of “done”
 Create the task board
 Define entry and exit criteria of testing

70. AgileTesting
Practices
 Pairing
 Incremental test design
 Idea Mind mapping
 Affinity diagram

71. 3.2Assessing
Quality Risks
and Estimating
Test Effort
 FA-3.2.1 (K3) Assess quality risks within an Agile project
 FA-3.2.2 (K3) Estimate testing effort based on iteration
content and quality risks

72. 3.2.1Assessing
Quality Risks
inAgile
Projects
 Few examples of quality risks are:
 No test data or incorrect test data to test specific application (a
functional risk related to accuracy)
 Slow system response to user input data (a non-functional risk
related to efficiency and response time)
 Screens that with no boundary conditions and business logic (a
non-functional risk related to usability and understandability)

73. Listed below is an example of quality risk process during iteration planning
1.All team members, including testers get into iteration planning meeting.
2.The prioritized backlog items are displayed on the task board for the current iteration.
3.Considering the quality characteristics, identify the quality risks items with each of them.
4.With each identified risk, categorize the level of risk and impact in terms of number of defects that
may surface.
5.Map the testing effort based on the level of risk
6.Based on the level of risk and its quality characteristic, select the appropriate technique to mitigate
the risk.

74. What is Planning
Poker? Effort
estimation inAgile
methodology
3.2.2 Estimating
Testing Effort
Based onContent
and Risk
1.Product Owner explains the story and its acceptance criteria in
detail
2.Team discusses the work involved and asks questions to the
Product Owner
3.Everyone estimates individually without getting influenced by
others.
4.Each team member selects a poker card that reflects their
estimate of the effort required for that story
5.Everyone reveals their estimates simultaneously.
6.Team members who voted with the lowest and highest
estimates explain their reasoning behind their estimation and
any misunderstanding of scope is neutralized.
7.After discussion, the team members reselect the cards to
reflect their estimates based current discussion.
8.Take the agreement of final number as the team estimate.
9.Repeat the process for all the stories in the Sprint backlog.

75. 3.3Techniques
inAgile
Projects
 FA-3.3.1 (K3) Interpret relevant information to support
testing activities
 FA-3.3.2 (K2) Explain to business stakeholders how to
define testable acceptance criteria
 FA-3.3.3 (K3) Given a user story, write acceptance test-
driven development test cases
 FA-3.3.4 (K3) For both functional and non-functional
behavior, write test cases using black box test design
techniques based on given user stories
 FA-3.3.5 (K3) Perform exploratory testing to support
the testing of an Agile project

76. The user
stories serve as
an important
test basis.
Other possible
test bases
include
 Experience from previous projects
Existing functions, features, and quality characteristics of the
system
Code, architecture, and design
 User profiles (context, system configurations, and user behavior)
Information on defects from existing and previous projects
A categorization of defects in a defect taxonomy
Applicable standards
Quality risks

77. 3.3.1
Acceptance
Criteria,
Adequate
Coverage, and
Other
Information
forTesting
 The acceptance criteria should comply with the following traits,
 Functional behavior
 Quality Characteristics [reliability, usability ]
 Scenarios (use cases)
 Business Rules
 External interfaces
 Constraints
 Data definitions

78. Definition of
done for each
test levels and
user story
What's your definition of done for
 Unit testing
 Integration testing
 System testing
 User Story
 Feature
 Iteration
 Release

79. User StoryThe definition of done for user stories may be determined by the
following criteria:
 The user stories selected for the iteration are complete, understood by
the team, and have detailed, testable acceptance criteria
 All the elements of the user story are specified and reviewed, including
the user story acceptance tests, have been completed
 Tasks necessary to implement and test the selected user stories have
been identified and estimated by the team

80. Unit testing - Done
 100% decision coverage
 Static analysis performed on all code
 No unresolved major defects
 No known unacceptable technical debt
 All code, unit tests, and unit test results reviewed
 All unit tests automated
 Important characteristics are within agreed limits (e.g., performance)

81. Integration testing - Done
 All functional requirements tested
 All interfaces between units tested
 All quality risks covered according to the agreed extent of testing
 No unresolved major defects
 All defects found are reported
 All regression tests automated

82. FeatureThe definition of done for features, which may span multiple user stories or epics,
may include:
 All constituent user stories, with acceptance criteria, are defined and approved by the
customer
 The design is complete, with no known technical debt
 The code is complete, with no known technical debt or unfinished refactoring
 Unit tests have been performed and have achieved the defined level of coverage
 Integration tests and system tests for the feature have been performed according to the
defined coverage criteria
 No major defects remain to be corrected
 Feature documentation is complete, which may include release notes, user manuals, and
online help functions

83. System testing - Done
 End-to-end tests of user stories, features, and functions tested
 All user personas covered
 The most important quality characteristics of the system covered (e.g., performance,
robustness, reliability)
 Testing done in a production-like environment
 All quality risks covered according to the agreed extent of testing
 All regression tests automated
 All defects found are reported and possibly fixed
 No unresolved major defects

84. Iteration- Done
 All features for the iteration are ready and individually tested according to the feature level
criteria
 Any non-critical defects that cannot be fixed within the constraints of the iteration added
to the product backlog and prioritized
 Integration of all features for the iteration completed and tested
 Documentation written, reviewed, and approved

85. Release- Done
 Coverage: All relevant test basis elements for all contents of the release have been
covered by testing.
 Quality
 Time
 Cost

86. 3.3.2Applying
Acceptance
Test-Driven
Development
 The idea of Acceptance test driven development is a set of tests
that must pass before an application can be considered finished
 Example acceptance test case is given below
scenario “System approves an card swipe for an amount less than
the preset maximum limit”
{
given “the System has selected an open card swipe”,
and “the System has chosen to approve the swipe”,
and “the card swipe amount is less than the agreed maximum limit”,
when “the System completes the action”,
then “the card swipe should be successfully approved”,
}

87. 3.3.3
Functional and
Non-
Functional
Black BoxTest
Design

88. 3.3.4
Exploratory
testing
 Exploratory testing is a hands-on approach in
which testers are involved in minimum planning and
maximum test execution.
 The planning involves the creation of a test charter,
a short declaration of the scope of a short (1 to 2
hour) time-boxed test effort, the objectives and
possible approaches to be used.

89. TestCharter 
A charter is a goal or
agenda for
a test session.
Often charters are
created from a
specification, test plan,
or by examining results
from previous sessions.

90. The quality of
the tests
depends on the
testers’ abilityto
ask relevant
questions about
what to test.
 What is most important to find out about the system?
 In what way may the system fail?
 What happens if.....?
 What should happen when.....?
 Are customer needs, requirements, and expectations fulfilled?
 Is the system possible to install (and remove if necessary) in all
supported upgrade paths?

91. Heuristics can
be applied
when testing
 A heuristic can guide the tester in how to
perform the testing and to evaluate the results
.
Examples include:
 Boundaries
 CRUD (Create, Read, Update, Delete)
 Configuration variations
 Interruptions (e.g., log off, shut down, or
reboot)

92. Information
that may be
useful to
document
 Test coverage: what input data have been used, how
much has been covered, and how much remains to be
tested
 Evaluation notes: observations during testing
 Risk/strategy list
 Issues, questions, and anomalies: any unexpected
behavior, any questions regarding the efficiency of the
approach, any concerns about the ideas/test attempts,
test environment, test data, misunderstanding of the
function, test script or the system under test
 Recording of actual behavior

93. 3.4Tools in
Agile Projects
 FA-3.4.1 (K1) Recall different tools available to testers
according to their purpose and to activities in Agile
projects

94. Task
Management
andTracking
Tools
These tools serve the following purposes:
 Agile Project Management managing requirements to stories
accepted
 Iteration and Sprint management
 Write stories and their prioritization for the team and PO
 Role based permissions for every persona of the user in Rally
 Captures team estimates and projects the velocity trends
 Team and multiple team release planning
 Generate nice visual reports, charts, dash boards and custom reports
 Integration of third party tools like clearquest etc. for tracking number
of test cases, check-ins, automated updates etc.
 Provides development and test sandboxes to experiment something
new always.
 Examples of Agile tools are Rally,Version One, Jira

95. Communication
and
Information
SharingTools
 In addition to writing emails and verbal communication, agile
teams have 3 types of support communication for information
sharing; wikis, instant messaging, and desktop sharing.
 Wikis -

96. Wiki
 A wiki can be a great way to plan and manage a project, from
conception to completion.Assign tasks, make a timeline, add
notes, paste images and other media
 Wiki’s are used to create a checklist so that we never forget
anything, and it’s done right every time.
 Wiki may also be used to log client work.; either hours spent on a
project or number of projects completed
 Teams working onWeb application take take notes, pull snippets
from pages, save images all the time and yet it can be hard to keep
track of all of them. Keep them all in one place on a wiki for easy
access when you need them.
 If we get a lot of questions about work, or product, keep an ever-
growing FAQ onWiki to prevent having to repeat your answers too
many times

97. Instant
messaging,
audio calls, and
video chat
Instant messaging, audio calls, and video chat tools
provide the following benefits:
 Allow real time face-to-face communication between
team members, especially useful for distributed teams
 Involve distributed teams for all scrum ceremonies
 Low cost due toVOIP technology.

98. Desktop sharing
and screen
sharing tools
Desktop sharing and screen sharing tools help team
members in providing the following:
 In distributed teams, the team members can pair up
every day to do pair programming, code reviews,
conducting demo and exercises.
 Capturing lessons learnt and retrospectives at the end
of every sprint to improve continuously.

99. Configuration
Management
Tools
Software configuration management tools
 VSS –Visual source safe
 CVS- Concurrent version system
 RationalClear Case
 SVN- Subversion.
 Perforce
 TortoiseSVN
 IBM Rational team concert
 IBM Configuration management version management
 Razor
 Quma version control system
 SourceAnywhere

100. Test Design,
Implementation,
and Execution
Tools
 Test design tools
 Test case management tools
 Test data preparation and generation tools
 Test data load tools
 Automated test execution tools
 Exploratory test tools

101. Cloud
Computing and
Virtualization
Tools
 This software makes it possible to run multiple
operating systems and multiple applications on the
same server at the same time