Online ISTQB test, Foundation level

1. Debugging is the development activity that finds, analyzes, and fixes defects
2. Debugging is the development activity that checks weither bugs were really fixed and don't cause failures anymore.
3. Debugging is the test activity that finds bugs and collects them in a bugtracking system.
4. Debugging is the test activity that sorts real bugs from false positives.

2 - During the specifications description phase, which practice is the most appropriate?

1. The tester is not involved in this phase
2. The tester performs a review of the specifications in order to detect as soon as possible the points to be clarified or corrected
3. The tester partly writes the specifications
4. The tester writes all the specifications

3 - An automated test fails, yet the application is working properly. What is this called?

1. A false positive
2. A non-functional test
3. A false negative
4. An automated test only fails if the application has an anomaly. However, the anomaly detected by the automated test is not always the one expected at the time of its implementation.

1. Find defects without running the software
2. Prevent regression between two versions of the product
3. Verify the database consistency consequently to user actions
4. Automatically measure the performances of an application

5 - When running a test suite, the tester must always follow strictly the instructions of the test cases.

1. True. The test cases have been created in order to ensure the best test coverage, it is essential to follow them closely.
2. False. Diverging from the test cases instructions may lead to discovering unforeseen paths and thus improve the test coverage.
3. True. The test cases cover the functionalities mentioned in the specification; it is not necessary to look for anomalies outside this scope.
4. False. Writing and following test cases is not recommended in an agile project.

1. Risk = Impact in case of occurrence / Benefits in case of non-occurrence
2. Risk = Sum of the potential impacts' severity
3. Risk = Probability of occurrence x Impact in case of occurrence
4. It is not recommended to calculate the risks because the result is likely to create biases and mislead the test team.

1. A similar behavior which can be seen within two different versions of the same application.
2. A range of data which, when used in the same test, must generate the same behavior.
3. The sum of all possible behaviours which allow to carry out the same action within a given application.
4. A collection of naming rules application to the development of a given application.

8 - A bus tickets purchasing terminal prohibits payment by cash, unless the user owns a valid and activited transport card. Which tool is best for analyzing the different possible behaviors of the application?

9 - A unit test performs the following function with the argument $sales = true.

10 - The test team independence towards the development team promotes test impartiality, but it also presents risks. Which of the following is not directly part of it?

1. Risk of seeing developers losing their sense of responsibility for quality
2. Risk for the test team of not being notified of some changes
3. Risk for the test team of a lack of legitimacy towards the client
4. Risk of creating a bottleneck on the test team side

1. Technical and functional risks
2. Quantitative and qualitative risks
3. Contextual and permanent risks
4. Project and product risks

1. A requirement left aside after a decision made by the test team
2. A requirement in conflict with by other requirements
3. A requirement which is not related to the software functionnalities
4. A requirement that does not impact the user experience

14 - The development team has just finalized the development of a site full of animations (slideshows, popups...) The client wants to ensure that this amount of animations does not slow down too much page loading. Which type of test is appropriate in this case?

1. The rate of compliance towards current standards for a specific realization of a component, system or process
2. The satisfaction expressed by customers or users after the conception of a component, system or process
3. The ratio between the components, systems or processes free of anomalies and the total of these objects
4. The degree to which a component, system or process meets the specified requirements and/or the needs or expectations of customers or users

1. A developer introduces an anomaly in his code. This anomaly is likely to generate a system error.
2. A developer introduces a defect in his code. This defect is likely to generate an anomaly in the system.
3. A developer introduces a bug in his code. This bug is likely to cause a system failure.
4. A developer introduces an error in his code. This error is likely to generate a system bug.

17 - Incident reports can have different objectives. Which of the following is not one of them?

1. Provide developers and other stakeholders with a feedback on the related problem to allow identification, location and correction of the anomaly
2. Provide test managers with the means to monitor quality of a system under test and the test progression
3. Provide project managers with performance metrics for each developer
4. Provide ideas to improve the testing process

1. Component tests, integration tests, system tests, acceptance tests
2. Component tests, system tests, acceptance tests, integration tests
3. Component tests, acceptance tests, system tests, integration tests
4. Component tests, acceptance tests, integration tests, system tests

1. No, agility opposes manual testing but emphasizes automated testing.
2. No, agility encourages regular testing to avoid regressions from one iteration to the next.
3. No, an agile approach must constantly seek to improve the development processes and therefore test different solutions.
4. No, it's the opposit. It's the test standards that opposes agility, which forsakens quality to gain speed.

1. As soon as the code is stable enough. The risk, when starting the tests too early, is to create a confusion between what is in progress and what actually contains defects.
2. As soon as a draft of specifications is available. Bugs may already exist in the documentation.
3. From the very beginning of the development. This is called TDD (test driven development).
4. As soon as an alpha version of the project is available. One must not wait for the beta version, because it is directly deployed to the customer.

ISTQB test, Foundation level online training