Which software faults are the hardest to fix? ISTQB Foundation Level Exam question

Question

I found the following question in a few mock exam papers available online

Which of the following statements are true?

• 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

My idea is that the question is not complete unless you know the status of the specific project, fault type and the root cause of the fault.

For example, if the project is still in the requirement gathering phase in a Waterfall Environment, the answer would be 'Faults in requirements are the most expensive to fix'

However, if you are in the Testing Phase in a Waterfall Environment and if you find a fault due to an issue in the program specification, the answer should be, 'Faults in program specifications are the most expensive to fix'

I wonder if

• This type of vague questions are there in the actual exam?

• My approach to the question is wrong?

• What do you think is the correct answer?

Thanks in advance for your time and effort in helping me crack the exam

Answer 1

This question is bogus. As the most expensive fix depends on the complexity of the fault. Small issues in any stage of the software development cycle are cheap to fix. As complex issues might need a complete rewrite. This rewrite might not be caused by wrong requirements, but by spaghetti-code or the other way around, depending who and where took the shortcuts.

This question probably relates to Boehm's Law: (picture from this blog-post)

Finding mistakes later in the development-cycle will cost more time and resources to fix on average. From this perspective the answer would be:

Faults in code are the most expensive to fix

As the faults, be it design, requirements or just code-mistakes are more expensive to fix if you have already build them. You will need to build them again, thus it will cost more money. This is why I would advise Agile development, then you get an graph like this each iteration, instead of a single big release cycle. Agile minimizes risks like this.

To answer your other questions:

This type of vague questions are there in the actual exam?

Yes, ISTQB is known for these type of questions and vague theory. ISQTB it is about theoretical testing instead of practical real world testing. If you seek a good course for testing have a look at the Certified Agile Tester courses as they have both a practical and questions exam. I would stop ISTQB if I could, and switch to the CAT version instead.

My approach to the question is wrong?

No, I like your approach. The root-cause is key here. Although looking at the phases is a good direction. It is important how much work is already executed and how much you have to re-execute due to this error. This is certainly true in Waterfall projects, but hopefully no-one is doing big waterfall projects anymore. I think the last statistics I read is that around 7% is still doing traditional waterfall project management. This number is going down fast. Don't waste to much time on understanding it, high level is enough I would think.

Answer 2

The point this question is trying to make is:

• we should build in "quality" instead of testing it out.
• testing should start as soon as development starts.
• if we leave any faults in earlier stages of development, they will cause "butterfly effect" and become difficult and expensive to fix. The analogy I want to use here is: earlier development is like drawing a schematic and laying foundation for a building, if something goes wrong in the very beginning, it will become VERY expensive to fix as the foundation has been laid and multiple stories have been built, every needs to be torn down in order to fix a fault in its foundation / design.

I think the correct answer is: faults in design are the most expensive to fix as design is the earliest stage of development.

Answer 3

Of the choices I would say that faults in the requirements are the most expensive to fix as if they are not discovered at a very early stage everything after them is going to have to be at least re-visited and possible thrown away and started from scratch.

From personal experience the one thing more expensive is missing requirements, or even no requirements, as if you don't have a requirement you cannot implement that behaviour, test it, etc., so you are at the mercy of the timing of when the missing requirement is discovered which may invalidate all of the work done to date.

Answer 4

Pay attention. The question states when error is made not found. Errors made in req and found in later delivery stage are the most expensive to fix.

Answer 5

the guy above (Oleg) is right actually, we elaborate about it, and the answer is right here being simple because the question says nothing about when it is found. So the question describes a situation, when an error is found, and then you decide when it is most expensive to fix- when it originated and multiplied from which state/phase of software development .