ISTQB CTFL-2018 Practice Test - Questions Answers, Page 29

Maintenance testing is a type of testing that is done on an existing system after modifications or migration, or to prevent deterioration or obsolescence. Maintenance testing can be triggered by various events or situations, such as:

System migration from one platform to another, which can affect the functionality, performance, or compatibility of the system.

Preparation for an audit of a system, which can require verifying the compliance of the system with standards or regulations.

Modifications to a system, which can introduce new defects or affect existing ones.

Therefore, statements a, c, and d are correct.

Static testing is a type of testing that does not involve executing the software or system under test, but rather analyzing it using various techniques, such as reviews, inspections, walkthroughs, checklists, static analysis tools, etc. Static testing can be applied to any work product that participants know how to read and understand, such as requirements specifications, design specifications, code, test cases, test plans, user manuals, etc. Static testing can help find defects and improve the quality of any work product at any stage of the software development lifecycle.

Static testing and dynamic testing are two types of testing that differ in the way they evaluate the software or system under test. Static testing is a type of testing that does not involve executing the software or system under test, but rather analyzing it using various techniques, such as reviews, inspections, walkthroughs, checklists, static analysis tools, etc. Dynamic testing is a type of testing that involves executing the software or system under test using test cases and comparing the actual results with the expected results. Static testing techniques, such as reviews, can be undertaken before dynamic testing, making defects cheaper to remove. This is because static testing can help find defects and improve the quality of any work product at any stage of the software development lifecycle, before they become more costly and difficult to fix during dynamic testing or after deployment.

Incorrect interface specifications are most likely to be found by a review during static testing. A review is a type of static testing technique that involves a manual examination of a work product by one or more individuals who follow a defined process. A review can be applied to any work product, such as requirements specifications, design specifications, code, test cases, test plans, user manuals, etc. A review can help find defects and improve the quality of any work product at any stage of the software development lifecycle. Incorrect interface specifications are defects that affect the definition and communication of the interfaces between components or systems. These defects can be detected by reviewing the interface specifications document and comparing it with the requirements and design specifications.

A typical characteristic of the walkthrough review type is that the meeting is led by the author. A walkthrough is a type of informal review that involves a presentation of a work product by the author to peers and other stakeholders for feedback and comments. The author leads the meeting and explains the work product to the participants, who can ask questions and make suggestions for improvement. The author may also record any issues or action items during the meeting. A walkthrough does not require formal preparation or follow-up by the participants, nor does it have defined entry and exit criteria.

Defect 1: Missing test case for validation failure of 'Password' field being blank. According to checklist item C2, there must be one test case for each error path. The test basis document specifies that the 'Password' field must be mandatory, and that if it is blank, Error Number 13 should be displayed. However, none of the test cases cover this scenario. Therefore, a test case for this validation failure is missing and should be added.

Defect 2: Incorrect field name in TC3. According to checklist item C3, each test case must use terminology consistent with the test basis document. The test basis document uses the term 'User Name' to refer to the field that identifies the user. However, TC3 uses the term 'User Id', which is inconsistent and confusing. Therefore, TC3 should be corrected to use the term 'User Name' instead of 'User Id'.

Defect 3: Incorrect error number in TC3. According to checklist item C3, each test case must use terminology consistent with the test basis document. The test basis document specifies that if the 'User Name' entered does not exist on the database, Error Number 12 should be displayed. However, TC3 states that Error Number 23 should be displayed, which is incorrect and does not match the test basis document. Therefore, TC3 should be corrected to use Error Number 12 instead of Error Number 23.

Checklist-based testing is an experience-based test technique whereby the experienced tester uses a high-level list of items to be noted, checked or remembered, or a set of rules or criteria against which a product has to be verified. Checklist-based testing can help the tester to focus on important aspects of the test object and to ensure that nothing is overlooked or forgotten. Checklist-based testing can also help the tester to communicate and report the test results and coverage more effectively.

A key difference between black box and white box test design techniques is that white box techniques can measure the extent of code coverage, while black box techniques cannot. Code coverage is a measure of how much of the code of a system or component has been executed by a test or a set of tests. White box techniques use software code to derive test cases that cover specific aspects of the code, such as statements, branches, paths, or data flows. White box techniques can use tools or methods to measure the code coverage achieved by the test cases and identify any gaps or redundancies. Black box techniques use functional design specifications to derive test cases that cover specific aspects of the functionality, behavior, or quality of the system or component, such as inputs, outputs, equivalence classes, boundary values, states, transitions, etc. Black box techniques do not use or access the code of the system or component, and therefore cannot measure the code coverage.

The three ages that would test all valid equivalence partitions and therefore test rate A, B and C are 20, 35 and 65. Equivalence partitioning is a technique to divide a set of possible inputs or outputs into classes that are expected to behave similarly or produce similar results. For each equivalence class, only one test case is required to represent the whole class. In this case, we can identify the following equivalence classes for the age of the driver:

Valid age between 17 and 25 inclusive (rate A)

Valid age between 26 and 50 inclusive (rate B)

Valid age over 50 (rate C)

Invalid age below 17

Invalid age above 100

Therefore, three test cases are required to test all valid equivalence partitions, and any value within each class can be used as a representative value. For example, 20 for rate A, 35 for rate B, and 65 for rate C.