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

  • 2
    If this question is typical of the exam, then the exam is awful. You could make a reasonable case for any of these answers, depending upon when the fault is discovered, the overall complexity of each phase, the complexity of the fault, whether the workers responsible for the phase that contains the fault are even still available to fix it, and many other factors. – Mark Amery Dec 17 '16 at 12:53
  • 2
    The question is indeed typical. The correct way to approach this is to memorize what the ISTQB deems is correct, not to actually try to make sense of these mostly-context-free questions. – Joe Strazzere Dec 17 '16 at 15:55
  • 2
    Deepika, This is the reason why many people don't support or consider certifications as a measure of one's ability to be good software tester. It's better you don't get too carried away with this and learn actual testing by practicing and interacting with people. – IAmMilinPatel Dec 19 '16 at 2:53
  • Yeah agree! Just finished my exam and happily, the exam did not have very vague questions like this. I mean, there were vague questions, but not so vague as this one – Deepika Fernando Dec 19 '16 at 2:54

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) enter image description here

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.

  • +1 for the course suggestions! And I like your perspective of the issue too. Things are getting interesting now. Boehm's law is not mentioned in the syllabus. Hence you give me more perspectives to think. Thanks for broadening my horizon! – Deepika Fernando Dec 17 '16 at 11:01
  • I think ISTQB does touch the subject (read the book 10 years ago), they just don't credit mister Boehm. Here is some online reference I found istqbexamcertification.com/… – Niels van Reijmersdal Dec 17 '16 at 11:04
  • Thanks for the link and yes you are correct. The syllabus speaks of this theory but doesn't mention the name of the person. Btw, I have just finished the exam and I feel that I did good. Waiting for the results now – Deepika Fernando Dec 19 '16 at 2:59

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.

  • 2
    Yeah that is one perspective. On the other hand, let us imagine that the software is built and tested. When it goes to the 'live' environment, users find a bug. You analyse the root of the problem and find out that the cause lies in 'wrong requirements'. Thus, wrong requirements can also be expensive to fix. I'm just trying to analyse the question in different perspectives. Much appreciated if anyone can put their thoughts in 😊 – Deepika Fernando Dec 17 '16 at 8:46

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.

Your Answer

