ISTQB Agile Tester Extension Exam Theory Study Material Part 4
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. 31 to 40) with detailed explanation
Q. 31: What are the instruments of Kanban?
Kanban uses three instruments like:
1) Kanban Board:
The value chain being managed is visualized through a Kanban board. The entire process, from the definition of a task to its delivery to the customer, is displayed on the Kanban board.
Each station shows a set of related activities in the form of columns e.g. development or testing.
The tasks to be processed are represented by Kanban tickets moving from left to right across the board through various stations. The team members pull work from the queue.
2) Work-in-Progress Limit:
The amount of parallel active tasks restricted. This is controlled by
the maximum number of Kanban tickets allowed for a station on the board.
Whenever a station has free capacity, the worker pulls a Kanban ticket from the previous station.
3) Lead Time:
Kanban is used to optimize the continuous flow of tasks by minimizing the (average) lead time for the complete value stream.
<<<<<< =================== >>>>>>
Q. 32: What is a “User Story” under Agile development?
User stories are the Agile form of requirements specifications and the essential functionality of the product desired by the end users.
User story explains how the system should behave with respect to a single, coherent feature or function.
The user story describes three things related to product requirements like – Who, What and Why.
A user story, in the beginning, is a brief requirement which is short enough to fit on an index “card”.
Till the development team implements the code, this user story has a meaningful “conversation” clarifying many details to the team.
<<<<<< =================== >>>>>>
Q. 33: Why “User Story” is written in Agile projects?
Poor specifications generally lead to project failure or inordinate delays in sequential product development.
Hence in agile development, user stories are written to capture requirements from the perspectives of developers, testers, and business representatives.
The reason of writing user stories is that generally the actual users are unable to describe their true needs due to the lack of technical insight and absence of a global vision for the system.
<<<<<< =================== >>>>>>
Q. 34: What are the essential characteristics of a “User Story”?
A user story must address the following;
1) It must describe all functional and non-functional characteristics.
2) It must include acceptance criteria for all described characteristics.
Acceptance criteria are the heart of the user story. User Stories are subjective, but the Acceptance Criteria provide the objectivity in it. Based upon the acceptance criteria, user story can be considered as “Done” or “Not Done” during the Sprint Review meetings.
The acceptance criteria are defined in collaboration between business representatives, developers, and testers.
The acceptance criteria included in the user story provides developers and testers a clear vision of the feature that business representatives will validate.
<<<<<< =================== >>>>>>
Q. 35: What is a general format of a “User Story”?
A generic format of a user story is as under;
“As a , I should be able to so that “.
Simple examples of using user story format are:
1) As a , I should be able to so that .
2) As a < Customer >, I want to so that .
3) As a < Administrator >, I want to
4) As a , I must
<<<<<< =================== >>>>>>
Q. 36: What is the difference between a “User Story” and an “Epic”?
Sometimes the user story becomes quite large to be managed in a single sprint. These large user stories are known as “Epics”.
Epics can include user stories for different development teams. For example, one user story can describe what is required at the API-level (middleware) while another user story describes what is needed at the UI-level (application).
Whenever an “Epic” emerges in a Prioritized Product Backlog within a Sprint, it is split into smaller manageable user stories.
Examples of Epics are:
1) As a customer of Amazon, I would like to be able to order a new blender and have it shipped to my house because my blender broke.
2) As a customer of the National auto insurance company, I would like to be able to report the fact that someone hit my truck with their car so that I can get the claim process started.
<<<<<< =================== >>>>>>
Q. 37: When an agile task is considered as “Finished”?
An agile task is considered as finished when a set of acceptance criteria is found satisfactory by the agile team.
<<<<<< =================== >>>>>>
Q. 38: What is “INVEST” technique used by testers for writing “User Stories”?
For writing short, simple and precise user stories “INVEST” guidelines are used by the collaborative authors. Every letter of the word “INVEST” represents a typical characteristic of the user story.
1) Letter – I: Independent:
It must be a self-contained user story so that it should not have any dependency on another user story.
2) Letter – N: Negotiable:
It must be negotiable or changeable or rewritable any time till it becomes a part of the iteration.
3) Letter – V: Valuable:
It must have a significant value for the end user.
4) Letter – E: Estimable:
It must be estimable in the sense that we should be able to estimate its size.
5) Letter – S: Small:
It must be small-sized or scalable. It should not be too large and become difficult to plan or prioritize with some level of certainty.
6) Letter – T: Testable:
It must be testable in the sense that its description must provide sufficiently clear information for making test development feasible.
<<<<<< =================== >>>>>>
Q. 39: What is “Three C’s” technique for writing “User Stories”?
The Three Cs concept, a user story is the conjunction of three elements:
1) Card:
It is a 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.
2) Conversation:
It explains how the software will be used. The conversation can be documented or verbal.
Conversation provides valuable inputs in deciding the acceptance criteria by exchange of thoughts, opinions, and experiences of the team members.
3) Confirmation:
The acceptance criteria, discussed during the conversation, are used to confirm that the user story is complete.
These acceptance criteria may cover many user stories. Both positive and negative tests are used to cover the acceptance criteria. During the confirmation stage, many participants can 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.
<<<<<< =================== >>>>>>
Q. 40: What is a “Retrospective” in Agile Development?
In Agile development, a retrospective is a meeting organized at the end of each iteration or sprint. This meeting is held in an open and relaxed atmosphere to encourage full participation by all team members.
The objective of the retrospective meeting is;
1) To discuss what was successful – means an understanding of best practices,
2) To discuss what could be improved – means an understanding of process improvements,
3) To discuss how to incorporate the improvements – means an understanding of process problems and bottlenecks,
4) To discuss how to maintain and retain the successes in future iterations.
Topics discussed during retrospectives are related to the process, people, organizations, relationships, and tools.
ISTQB Agile Tester Extension Exam Theory Study Material Part 5
An expert on R&D, Online Training and Publishing. He is M.Tech. (Honours) and is a part of the STG team since inception.