ISTQB Agile Tester Extension Exam Theory Study Material Part 10

ISTQB Agile Tester Extension Exam Theory Study Material Part 10

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. 91 to 100) with detailed explanation

Q. 91: What is Acceptance-Test driven development (ATDD)?

# Acceptance test-driven development is a test-first approach.

# It involves the creation of test cases before implementing the user story.

# It defines acceptance criteria and tests during the creation of user stories.

# It is a collaborative approach, involving the creation of test cases by the Agile team, including the developer, the tester, and the business representatives. The test cases may be manual or automated.

# It creates reusable tests for regression testing.

# It allows quick resolution of defects and validation of feature behavior.

# It helps determine if the acceptance criteria are met for the feature.

<<<<<< =================== >>>>>>

Q. 92: What is the process of Acceptance-test driven development?

1) Organizing a specification workshop where the user story is analyzed, discussed, and written by developers, testers, and business representatives.

2) Fixing of any incompleteness, ambiguities, or errors in the user story.

3) Creation of the tests by the team together or by the tester individually.

4) Validation of the tests by an independent person like a business representative.

<<<<<< =================== >>>>>>

Q. 93: What are the important features of tests under Acceptance-test driven development?

# Tests under ATDD are the examples describing the specific characteristics of the user story. With these examples, the team can implement the user story correctly.

# Because these examples and tests are the same, these terms are generally used interchangeably.

# First tests Acceptance-test driven development is the positive tests, confirming the correct behavior without exception or error conditions, comprising the sequence of activities executed if everything goes as expected.

# After the positive path tests are done, the team writes negative path tests and cover non-functional attributes as well (e.g., performance, usability).

# Tests are expressed in a way that every stakeholder is able to understand, containing sentences in natural language involving the necessary preconditions, if any, the inputs, and the related outputs.

# The examples must cover all the characteristics of the user story and should not add to the story.

# This means that an example should not exist which describes an aspect of the user story not documented in the story itself.

# No two examples should describe the same characteristics of the user story.

<<<<<< =================== >>>>>>

Q. 94: Why Acceptance test-driven development (ATDD) creates reusable tests for regression testing?

# One of the primary element of ATDD is to create reusable regression tests for continuous integration.

# Regression testing is a type of software testing which seeks to uncover new software bugs, or regressions, in existing functional and non-functional areas of a system after changes such as enhancements, patches or configuration changes, have been made to them.

# Objective of regression testing is to ensure that changes such as those mentioned above have not introduced new faults.

# Main reason for regression testing is to find out whether a change in one part of the software affects other parts of the software.

# During agile development, because the code is changed in every sprint, team needs to ensure that code that worked in the previous sprint still works after new implementations.

# Regression testing is an integral part of agile development methods and it is a common goal to automation as many of these test as possible.

<<<<<< =================== >>>>>>

Q. 95: What is Behavior-Driven development (BDD)?

# in BDD the developers focus on testing the code based on the expected behavior of the software.

# Because the tests are based on the exhibited behavior of the software, the tests are generally easier for other team members and stakeholders to understand.

# BDD frameworks are used for defining the acceptance criteria based on the “Given – When – Then” format;

1) “Given” some initial context.
2) “When” an event occurs.
3) “Then” ensure some outcomes.

# BDD framework generates code from the requirements, which are used by developers to create test cases.

# BDD helps the developer collaborate with other stakeholders, including testers, to define accurate unit tests focused on business needs.

<<<<<< =================== >>>>>>

Q. 96: What is the “Given – When – Then” concept of BDD?

# Given-When-Then or (GWT) is a semi-structured way to write down test cases and was invented by Dan North as a part of BDD.

# (GWT) format is used for expressing the test scenarios with sample data, including pre- and post-conditions.

# (GWT) helps all stakeholders of the project in communicating using business domain language.

# (GWT) can be used to explore product options and confirm selected options in a tangible way.

# (GWT) helps in specifying the requirements, identifying the acceptance tests for a streamlined discovery and delivery.

# While using (GWT) for a user story or a scenario or test, the Agile team analyzes 3-things, asking and answering 3-questions:

1) “Given”:
What is the context of the system?
What pre-condition must be true before the action is tested?
What data is in the system?

2) “When”:
What will be tested?
What input data will be tested through the business rule when the action occurs?

3) “Then”:
In response to the action, what is the observable outcome?
What are the expected results?
What is the post-condition (state) or output data observable by the user?

Example -1 of use of Given-When-Then Format:

Example -2 of use of Given-When-Then Format:

<<<<<< =================== >>>>>>

Q. 97: What is a Test Pyramid?

Test pyramid concept developed by Mike Coen is based on the testing principle of eliminating defects as early as possible in the lifecycle (i.e. early QA and testing).

# A software system is generally tested at different levels.

# Typical test levels are, from the base of the pyramid to the top, unit, integration, system, and acceptance.

# The test pyramid emphasizes on having many more low-level unit tests (bottom of the pyramid) and, as development moves to the upper levels, the number of tests decreases (top of the pyramid).

# Usually unit and integration level tests are automated and are created using API-based tools.

# At the system and acceptance levels, the automated tests are created using GUI-based tools.

# In Agile testing, the concept of the test pyramid emphasizes on building a well-balanced test portfolio.

# High-level tests remain in place as the second line of test defense. Failure in a high-level test may not mean the presence of a bug in the functional code; rather it could be due to a missing or incorrect unit test.

# Instead of fixing a bug found by a high-level test, it is better to replicate the bug through a unit test. The unit test will kill the root of the bug.

<<<<<< =================== >>>>>>

Q. 98: What is the model of “Quadrants” under Agile testing?

# Quadrants are just a testing taxonomy defined by Brian Marick through his original posts on Agile testing matrix.

# Quadrant model aligns various test levels with the appropriate test types in the Agile methodology.

# Quadrants were identified as Q1, Q2, Q3 and Q4 like in the case of mechanical engineering drawing system.

Quadrant Q1 − Unit Level, Technology Facing, and supports the developers. Unit tests belong to this Quadrant. These tests can be Automated tests.

Quadrant Q2 − System level, business facing, and conform product behavior. Functional tests belong to this quadrant. These tests are either manual or automated.

Quadrant Q3 − System or User Acceptance Level, Business Facing and focus on real-time scenarios. User Acceptance Tests belong to this quadrant. These tests are manual.

Quadrant Q4 − System or Operational Acceptance Level, Technology Facing and Focus on Performance, Load, Stress, Maintainability, Scalability Tests. Special tools can be used for these tests along with automation testing.

# Testing Quadrants model is an effective tool which helps agile teams to ensure that all important test types and test levels are included in the development lifecycle.

# Quadrants help the agile team in planning its testing activities and ensuring the availability of all resources required to accomplish them.

# Quadrants are the pictorial representation of differentiating and describing the types of tests to all stakeholders, including developers, testers, and business representatives.

# Agile team begins to think about testing first as they proceed through the quadrants and go with the release, theme, and iteration planning.

# Quadrants were designed to differentiate the types of testing and there is no hard and fast rule on following them in any particular order like say Q1, Q2, Q3 or Q4.

<<<<<< =================== >>>>>>

Q. 99: What Test Levels are covered under Agile testing described through quadrants?

# Like traditional testing, the Agile testing also covers all the test levels like;

1) Unit Testing
2) Integration Testing
3) System Testing
4) User Acceptance Testing

# Testing can be totally manual or totally automated or a combination of manual supported by automation Tools.

Agile Testing Quadrants combine the following two aspects of testing types;

To decide on “What” tests are to be performed and “When”, the agile team finds out whether a test is;

1) Business Facing, or
2) Technology Facing or
3) Support Programming Tests or
4) Critique Product Tests.

1) Business Facing Tests:
# A test is called a business facing a test if it addresses the queries from the business domain.

# These tests are of interest to the business experts and as they can understand the behavior of the system in a real-time scenario.

2) Technology-Facing Tests:
# A test is called a business facing a test if it addresses the queries from the technology domain.

# These tests are of interest to the programmers who understand the requirement to be implemented using the available technology.

3) Supporting Programming Tests:
# These tests are used by the developers.

# These tests are done to decide the code which needs to be written to achieve a particular behavior of the system.

# Team decides on what tests are to be executed after coding for ensuring that the new code does not have any adverse effect on the remaining behaviors of the System.

4) Critique Product Tests:
# These tests are meant for verification purpose only and are used for finding out deficiencies in the finished Product.

<<<<<< =================== >>>>>>

Q. 100: What is the role of a tester in a project following a Scrum lifecycle?

Testers play the most important roles with a focus on the following;

1) Teamwork:
Teamwork is a fundamental principle in Agile development. Agile emphasizes the whole-team approach consisting of developers, testers, and business representatives working together.

2) Sprint Zero:
Sprint zero is the first iteration of the project where many preparation activities take place. Here tester collaborates with the team and sets the direction for what testing needs to achieve and how testing needs to achieve it throughout the sprints.

3) Integration:
In Agile projects, the objective is to deliver value to the customer on a continuous basis through every sprint. This is done through an integration strategy involving both design and testing. To enable a continuous testing strategy for the delivered functionality and characteristics, it is important to identify all dependencies between important functions and features.

4) Test Planning:
Since testing is fully integrated into the Agile team, test planning starts during the release planning session and updated during each sprint.

Sprint planning results in a set of tasks to put on the task board, where each task should have a length of one or two days of work. All testing issues should be tracked to keep a steady flow of testing.

5) Agile Testing Practices:
Many practices like Pairing, Incremental test design, and Mind mapping are quite useful for testers in a scrum team.

ISTQB Agile Tester Extension Exam Theory Study Material Part 11

Yogindernath Gupta

An expert on R&D, Online Training and Publishing. He is M.Tech. (Honours) and is a part of the STG team since inception.