Hope you guys liked my previous blog post on tips for the ISTQB exam 🙂
I got some great feedback on LinkedIn when I posted it on a discussion there that I thought I’d follow it up with a few more tips and Part 1 of explanations of some sample ISTQB Questions.
More Useful Tips for the ISTQB Foundation Exam
Process of Elimination
As the ISTQB Foundation Exam is multi-choice, process of elimination is a pretty good idea. The good thing is you can get rid of the trash quickly and then focus on the ‘realistic’ possible answers when you read the question or when you come back to it later
Highlight the key words
Especially words like “not” and “most” that change the entire meaning of the sentence but can be easy to miss.
Watch out for questions that contain the word “MOST”
I’d like to draw attention to this because chances are all of the options will be correct if you’re asked something along the lines of: “Which goal is the MOST valid to try and achieve?” At least 2 of your options will definitely be valid, so don’t just circle the first correct answer you see as you go through your options
Learn the different ways to say the same thing
For example: Confirmation Testing and Retesting –> They’re the same thing. You don’t want to be thrown by a question that you should know the answer to because you didn’t know about different ways of saying the same thing.
Learn the different types of Coverage
You’re guaranteed a few questions that will check you actually know the difference between Decision coverage, path coverage, branch coverage etc. I’ve written a blog post on the difference between Branch and Path coverage here.
Make sure you learn the 7 Key principles of Software Testing
Here they are:
Principle 1: Testing shows the presence of bugs (but a failure to find bugs does not necessarily mean that none exist). Tests must be designed to find as many bugs as possible, and since it is assumed that every product initially has bugs, a test that identifies bugs is better than one that finds none.
Principle 2: Exhaustive testing is impossible because there are usually too many variables that come into play. Therefore, testers must focus efforts on only the most critical priorities and risks.
Principle 3: Testing should be done as early as possible after the product or application has been created, in order to fix issues as fast as possible. Errors identified later in the process tend to be more expensive to mitigate.
Principle 4: Use defect clustering, as software problems tend to cluster around narrow areas or functions. By identifying and focusing on these clusters, testers can efficiently test the sensitive areas while concurrently testing the remaining “non-sensitive” areas.
Principle 5: Use a variety of tests and techniques to expose a range of defects across different areas of the product. Avoid using the same set of tests over and over on the same product or application, because this will reduce the range of bugs you will find.
Principle 6: The same tests should not be applied across the board because different software products have varying requirements, functions and purposes. For example, a website should be tested differently than a company Intranet site.
Principle 7: Don’t buy into the absence of errors fallacy. In other words, a test that finds no errors is different than concluding that the software is error-free. It should be assumed that all software contains some faults, even if said faults are hidden.
Not only should you make sure that your answer is correct but that the other answers (that you did not select) are definitely wrong. This is a great way to stop yourself from being caught out.
Explanations of Sample ISTQB Foundation Questions
Ok let’s start from the top.
a) This doesn’t make any sense. How does automation help avoid exhaustive testing?
b) Exhaustive testing (note this is also known as complete testing) is not feasible for all software. The keywords here are ALL software. Even with the addition of the words “sufficient effort and tool support” makes that option seem possible, the “all software” part cancels it out.
c)Yep this looks good. Since software systems are so complicated, testing all input/output combinations of a software system would indeed be very difficult and “normally possible”. Let’s hold on to this one for now but check the last one just to make sure.
d) Nope. It is to demonstrate the presense of defects. BUT say you didn’t learn this particular key principle of software testing. Then you could also ask yourself, how exactly would testing a piece of software prove that there is nothing wrong with it (i.e. there are no defects).
requirements. With these sort of questions I like to use the process of elimination technique and figure out which sentence out of the ones above is true so that I can eliminate 1 or more options as soon as possible.
B. Software testing is mainly needed to improve the quality of the
C. Rigorous testing and fixing of defects found can help reduce the risk of
problems occurring in an operational environment.
D. Rigorous testing is sometimes used to prove that all failures have been
a) B and C are true. A and D are false.
b) A and D are true. B and C are false.
c) A and C are true. B and D are false.
d) C and D are true. A and B are false.
Let’s start with A.
Yes- A is true. It’s feasible that software testing may be required to meet legal/contractual requirements (e.g. for peace of mind for people ‘above’ and to know that the software is of a certain quality)
Now that we know that sentence A is true. Let’s eliminate options a) and d)
Let’s read sentence C. Yep definitely- rigorous testing and defect fixing can reduce the risk of problems occuring in an operational environment. Let’s put this one on hold and check sentence D.
D- nope you can’t prove all failures have been found. It’s not feasible. Similar to the idea of Exhaustive Testing is impossible.
With these sort of questions I like to use the process of elimination technique and figure out which sentence out of the ones above is true so that I can eliminate 1 or more options as soon as possible.