ISTQB Agile Tester Extension Exam Theory Study Material Part 13
Have a deep study of this entire question bank containing theory portion with detailed explanation. This study resource is as per the latest syllabus.
Just 1 hr. of time spent in brushing up your knowledge just before the ISTQB Agile Tester Extension Exam shall be of great help in clearing it.
Set of 10 Questions (Q. 121 to 130) with detailed explanation
Q. 121: Describe an example of Definition of Done (DoD) for Features?
The definition of done for features, which may be spread across multiple user stories or epics, may be found out by the following criteria:
1) All constituent user stories, with acceptance criteria, are defined and approved by the customer
2) The design is complete, with no known technical debt
3) The code is complete, with no known technical debt or unfinished refactoring
4) Unit tests have been performed and have achieved the defined level of coverage
5) Integration tests and system tests for the feature have been performed according to the defined coverage criteria
6) No major defects remain to be corrected
7) Feature documentation is complete, which may include release notes, user manuals, and online help functions
<<<<<< =================== >>>>>>
Q. 122: Describe an example of Definition of Done (DoD) for Iterations or sprints?
The definition of done for iteration may be found out by the following criteria:
1) All features for the iteration are ready and individually tested according to the feature level criteria
2) Any non-critical defects that cannot be fixed within the constraints of the iteration added to the product backlog and prioritized
3) Integration of all features for the iteration completed and tested
4) Documentation written, reviewed, and approved
<<<<<< =================== >>>>>>
Q. 123: Describe an example of Definition of Done (DoD) for Release?
The definition of done for release, which may be spread across multiple iterations, may be found out by the following criteria:
1) Coverage:
All relevant test basis elements for all contents of the release have been covered by testing. The adequacy of the coverage is determined by what is new or changed its complexity and size, and the associated risks of failure.
2) Quality:
The defect intensity (e.g., how many defects are found per day or per transaction), the defect density (e.g., the number of defects found compared to the number of user stories, effort, and/or quality attributes), estimated number of remaining defects are within acceptable limits, the consequences of unresolved and remaining defects (e.g., the severity and priority) are understood and acceptable, the residual level of risk associated with each identified quality risk is understood and acceptable.
3) Time:
If the pre-determined delivery date has been reached, the business considerations associated with releasing and not releasing need to be considered.
4) Cost:
The estimated lifecycle cost should be used to calculate the return on investment for the delivered system (i.e., the calculated development and maintenance cost should be considerably lower than the expected total sales of the product). The main part of the lifecycle cost often comes from maintenance after the product has been released, due to the number of defects escaping to production.
<<<<<< =================== >>>>>>
Q. 124: How Acceptance Test-Driven Development is applied in actual practice?
Acceptance test-driven development is a test-first approach. Hence test cases are created before implementing the user story. The test cases may be manual or automated.
It involves the following steps.
Step-1: Specification workshop
It involves analysis and discussions on the user story which is written by developers, testers and business representatives.
All errors, ambiguities or incompleteness in the user story are fixed during this process.
Step-2: Creation of tests
It is done by the by the tester individually or by the whole team together.
The tests are validated by an independent person like a business representative.
<<<<<< =================== >>>>>>
Q. 125: What characteristics of the user story are covered under tests written under ATDD?
The test show the following characteristics of the user story:
# One or more positive path (Since examples and tests are the same)
# One or more negative path
# Examples covering all non-functional attributes like performance, usability, stress and security etc.
<<<<<< =================== >>>>>>
Q. 126: What are the contents of tests written under ATDD?
Tests are written in clear normal language understandable by all stakeholders, and consist of the following;
# Preconditions
# The input
# Related output
The test or examples cover all functionality and non-functional characteristics mentioned in the user story only. This means that an example should not exist which describes an aspect of the user story not documented in the story itself.
<<<<<< =================== >>>>>>
Q. 127: Which Functional and Non-Functional Black Box Test Design techniques are used by Agile Testers?
# Equivalence partitioning,
# Boundary value analysis,
# Decision tables,
# State transition testing
# Class Tree
<<<<<< =================== >>>>>>
Q. 128: What is a test charter in exploratory testing of agile projects?
# In exploratory testing, test design and test execution take place simultaneously and the process is guided by a test charter prepared beforehand.
# A test charter is a document which provides the test conditions to cover during a time-boxed testing session.
<<<<<< =================== >>>>>>
Q. 129: What are the contents of test charter in exploratory testing of agile projects?
A test charter includes the following information:
1) Actor: is an intended user of the system
2) Purpose: the theme of the charter including what particular objective the actor wants to achieve, i.e., the test conditions
3) Setup: what needs to be in place in order to start the test execution
4) Priority: relative importance of this charter, based on the priority of the associated user story or the risk level
5) Reference: specifications like user story, risks, or other information sources
6) Data: whatever data is needed to carry out the charter
7) Activities: a list of ideas of
# What the actor may want to do with the system (e.g., “Log on to the system as a superuser”)
# What would be interesting to test (both positive and negative tests)
8) Oracle notes: how to evaluate the product to determine correct results (e.g., to capture what happens on the screen and compare to what is written in the user’s manual)
9) Variations: alternative actions and evaluations to complement the ideas described under activities
<<<<<< =================== >>>>>>
Q. 130: What is a session in exploratory testing?
Exploratory testing is managed by a method which is known as session-based test management.
A session is defined as an uninterrupted period of testing which could last from 60 to 120 minutes.
Test sessions include the following activities:
1) Survey session to learn how it works
2) Analysis session to evaluate the functionality or characteristics
3) Deep coverage – corner cases, scenarios, interactions
ISTQB Agile Tester Extension Exam Theory Study Material Part 14
An expert on R&D, Online Training and Publishing. He is M.Tech. (Honours) and is a part of the STG team since inception.