4

I am preparing for the ISTQB Foundation Level Exam by taking this mock test.

Consider the following statements

i. an incident may be closed without being fixed

ii. incidents may not be raised against documentation

iii. the final stage of incident tracking is fixing

iv. the incident record does not include information on test environments

v. incidents should be raised when someone other than the author of the software performs the test

Possible answers are:

a) ii and v are true, I, iii and iv are false

b) i and v are true, ii, iii and iv are false

c) i, iv and v are true, ii and iii are false

d) i and ii are true, iii, iv and v are false

e) i is true, ii, iii, iv and v are false

Supposedly, the correct answer is b: "i and v are true, ii, iii and iv are false".

But, how can "incidents should be raised when someone other than the author of the software performs the test" be true? It makes no sense to me.

Am I missing something?

  • 2
    @MateMrše You are thinking like a tester, which is good! Your comments on one of the answers were exactly right--the wording of #5 is definitely ambiguous and should be questioned. Keep cultivating that critical thinking, which unfortunately the ISTQB certification seems to actively discourage by trying to teach you that there's always only one "right" answer or definition. You might take a look at developsense.com/presentations/notyetcertified.pdf which could give you many useful ideas for ways to improve your testing skills beyond certifications. – c32hedge May 17 '19 at 13:33
  • Thanks for the notyetcertified.pdf. Will read it. – Mate Mrše May 17 '19 at 14:01
4

A number of answers can be figured out through the process of elimination - even ones that don't necessarily make sense to you.

In the example question, you can knock out 2 and 3 straight away... we know they're false, which also means the answer can't be A or D.

We can also take out 4 because an incident should include information on test environments (whether they do or not in real life is a different story!), which means the answer can't be C either.

Lastly (and bear with me), remember that an incident is different to a defect:

  • A defect is when the actual behavior does not match expected behavior.
  • An incident is the occurrence of any unexpected behavior while testing.

A defect can be raised at any point in the development life cycle, whereas an incident can only be raised from system testing (and not in unit testing). So, if 'the author of the software' (read 'developer') finds an incident, then it would have been found in unit testing, and is therefore a defect and not an incident.

Sooo, because we know 5 is true... the answer can't be E, and so it must be B :)

| improve this answer | |
  • OK. Now, that is much more clear. So, it is about finding an incident (not a defect) after unit testing. – Mate Mrše May 17 '19 at 13:11
  • 4
    Wow. I've never had much use for the ISTQB stuff, but in this case it seems to have taken pedantic hair-splitting of glossary definitions to a whole new level of uselessness--good explanation of a bad "distinction with out a difference" test question. – c32hedge May 17 '19 at 13:17
  • 2
    No kidding. What, we're supposed to record 'documentation defect' differently from software defect? cmon, this is silly. if the 'documentation' is the help screen the user sees, does that count? What about badly worded BDD tests - do they count? In other words - whatever you think on those points - is becomes totally open to interpretation and that is not good. If the documentation is cucumber tests that read badly, does that count? ... – Michael Durrant May 17 '19 at 14:20
  • 2
    ...This sort of distinction is often then analyzed by business users - and then they go and cut out the parts they don't think add value (like documentation or tests)... in flowery language about how app code has more 'revenue'. Guess what happens to quality over time? Been there. Done that. TOO many times. – Michael Durrant May 17 '19 at 14:23
1

incidents should be raised when someone other than the author of the software performs the test could be reworded to when a test fails, raise an incident. i don't think it matters who is doing the testing. The someone other than the author of the software may be just to confuse you.

| improve this answer | |
  • 1
    It is still very confusing, and wrong, IMO. This could be understood as if anyone other than the author of the software performs the test - that constitutes an incident. Maybe it is because English is not my native language that I'm misinterpreting this. – Mate Mrše May 17 '19 at 11:53
  • yeah you are right, it could be understood like this.. but this would make no sense :) incident is incident i would say, no matter who tests. – globalworming May 17 '19 at 11:55
  • 1
    I agree. But, since that sentence has no context (and none is given in the question, either) it is wrong. Oh, well, I'll just go with this. – Mate Mrše May 17 '19 at 11:59
0

Unfortunately ISTQB focuses on terminology (Error/Defect/Bug/Failure) instead of focusing on practical skill set. (Review the most recently logged bug there is a high chance there is another one nearby)

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.