ISTQB Foundation Sample Question Paper No. 3 assesses key competencies in software testing. It covers the initiation of testing activities, reasons for software faults, importance of pre-release testing, and prioritization of test execution. Essential for those preparing for ISTQB certification.
Only records defects
Is of limited value
Is a valuable source of project information during testing if it contains all incidents
Should be used only by the test team
Rate this question:
Statement and branch testing
Usability testing
Security testing
Performance testing
Rate this question:
Data tester
Boundary tester
Capture/Playback
Output comparator
Rate this question:
Statement testing
Equivalence partitioning
Error- guessing
Usability testing
Rate this question:
Poor quality software
Poor software and poor testing
Bad luck
Insufficient time for testing
Rate this question:
Statement Coverage
Pole Coverage
Condition Coverage
Path Coverage
Stub
Driver
Proxy
None of the answers are correct
Rate this question:
The most important tests first
The most difficult tests first(to allow maximum time for fixing)
The easiest tests first(to give initial confidence)
The order they are thought of
Rate this question:
Component testing should be black box, system testing should be white box.
If you find a lot of bugs in testing, you should not be very confident about the quality of software
The fewer bugs you find,the better your testing was
The more tests you run, the more bugs you will find
Rate this question:
The documentation is poor, so it takes longer to find out what the software is doing.
Wages are rising
The fault has been built into more documentation,code,tests, etc
None of the choices are correct
Rate this question:
Large
Small
Difficult to write
Difficult to test
Rate this question:
Should be able to understand a functional specification or requirements document
Should be able to understand the source code.
Is highly motivated to find faults
Is creative to find the system’s weaknesses
Rate this question:
When time for testing has run out
When all planned tests have been run
When the test completion criteria have been met
When no faults have been found by the tests run
Rate this question:
Code inspection
Coverage analysis
Usability assessment
Installation test
Rate this question:
0,1900,2004,2005
1900, 2004
1899,1900,2004,2005
1899, 1900, 1901,2003,2004,2005
Rate this question:
Needs configuration management just like requirements, design and code
Should be newly constructed for each new version of the software
Is needed only until the software is released into production or use
Does not need to be documented and commented, as it does not form part of the released software system
Rate this question:
Missing Statements
Unused Branches
Dead Code
Unused Statement
Rate this question:
IEEE829
IEEE610
BS7925-1
BS7925-2
Rate this question:
9,10,11,22
9,10,21,22
10,11,21,22
10,11,20,21
Rate this question:
As polite, constructive and helpful as possible
Firm about insisting that a bug is not a “feature” if it should be fixed
Diplomatic, sensitive to the way they may react to criticism
All of the answers are correct
Rate this question:
Reducing test time
No change
Increasing test time
Can’t say
Rate this question:
Functionality
Usability
Supportability
Maintainability
Rate this question:
How well you know a particular technique
The objective of the test
How appropriate the technique is for testing the application
Whether there is a tool to support the technique
Rate this question:
10,11,21
3,20,21
3,10,22
10,21,22
Rate this question:
System testing
Usability testing
Performance testing
Performance testing & Usability testing
Rate this question:
Performance testing can be done during unit testing as well as during the testing of whole system
The acceptance test does not necessarily include a regression test
Verification activities should not involve testers (reviews, inspections etc)
Test environments should be as similar to production environments as possible
Rate this question:
State-Transition
Usability
Performance
Security
Rate this question:
As soon as the code is written
During the design stage
When the requirements have been formally documented
As soon as possible in the development life cycle
Rate this question:
Is nothing to do with testing
Is a partial measure of test thoroughness
Branch coverage should be mandatory for all software
Can only be applied at unit or module testing, not at system testing
Rate this question:
A process for selecting test cases
A process for determining expected outputs
A way to measure the quality of software
a way to measure in a test plan what has to be done
Rate this question:
1
2
3
4
Rate this question:
State analysis
Coverage analysis
Dynamic analysis
Memory analysis
Rate this question:
1
2
3
4
Rate this question:
To show that system will work after release
To decide when the software is of sufficient quality to release
To find as many bugs as possible before release
To give information for a risk based decision about release
Rate this question:
Faults in program specifications are the most expensive to fix.
Faults in code are the most expensive to fix.
Faults in requirements are the most expensive to fix.
Faults in designs are the most expensive to fix.
Rate this question:
Design based
Big-bang
Bottom-up
Top-down
Rate this question:
IEEE 829
IEEE 610
BS7925-1
BS7925-2
Rate this question:
White box
Glass box
Structural
Functional
Rate this question:
1
2
3
4
Rate this question:
Quiz Review Timeline (Updated): Mar 22, 2023 +
Our quizzes are rigorously reviewed, monitored and continuously updated by our expert board to maintain accuracy, relevance, and timeliness.
Wait!
Here's an interesting quiz for you.