New Year Sale 2026! Hurry Up, Grab the Special Discount - Save 25% - Ends In 00:00:00 Coupon code: SAVE25
Welcome to Pass4Success

- Free Preparation Discussions
Mail Us support@pass4success.com
Location US
Mob_nav_barsMENU

ISTQB-CTFL Exam - Topic 1 Question 9 Discussion

Actual exam question for ISTQB's ISTQB-CTFL exam
Question #: 9
Topic #: 1
[All ISTQB-CTFL Questions]

An Incident Management tool implements the following defect states; Open, Assigned, Solved,

Closed Consider the following defect report:

Id T000561

Test Object "Warehouse Management' application

Tester name; John Bishop

Date: 10th. April 2010

Test Case MRT558I

Status OPEN

Severity Serious

Priority

Problem- After inputting the Total Quantity item = 450 in the SV034 screen, the system shows an unexpected Error message=47

Correction:

Developer name:

Closing date:

Which of the following is a valid criticism of this report?

Show Suggested Answer Hide Answer
Suggested Answer: B

A valid criticism of this report is that the version of the application is missing. The version of the application is an important piece of information that should be included in a defect report, as it helps to identify which release or build of the software product contains the defect. The version of the application can also help to reproduce and debug the defect, as different versions may have different behaviors or features. The other options are not valid criticisms of this report. The priority, the correction description and the developer name are not missing, but rather not applicable for this report. The priority is a measure of how urgently a defect needs to be fixed, which can be assigned by the project manager or the defect tracking system, not by the tester who reports the defect. The correction description and the developer name are information that are added after the defect has been resolved, not when it has been reported. There is no link to the applicable requirement (traceability) is not a valid criticism of this report, because traceability is not a mandatory attribute of a defect report, but rather an optional one. Traceability is a relationship between two or more entities (such as requirements, test cases, defects, etc.) that shows how they are related or dependent on each other. Traceability can help to verify that the requirements are met by the test cases and defects, but it is not essential for reporting a defect. The description is not highlighting the source of the problem is not a valid criticism of this report, because highlighting the source of the problem is not a responsibility of the tester who reports the defect, but rather of the developer who fixes the defect. The description should provide enough information to describe what happened when the defect occurred, such as input values, expected results, actual results, error messages, screenshots, etc., but it does not need to explain why or how it happened. Verified Reference:A Study Guide to the ISTQB Foundation Level 2018 Syllabus - Springer, page 140.


by Freeman at Oct 17, 2023, 03:40 PM

Limited Time Offer

25%

Off

Get Premium ISTQB-CTFL Questions as Interactive Web-Based Practice Test or PDF

Contribute your Thoughts:

0/2000 characters
Submit Cancel
Marquetta
3 months ago
Is it really that serious if they didn't mention the version? Seems odd.
upvoted 0 times
...
Adelaide
3 months ago
Totally agree, traceability is key!
upvoted 0 times
...
Lisha
3 months ago
Wait, how can you solve a defect without knowing the source of the problem?
upvoted 0 times
...
Edmond
4 months ago
I think the version of the application should be included too.
upvoted 0 times
...
Elbert
4 months ago
The Priority, Correction, and Developer name are definitely missing.
upvoted 0 times
...
Maryln
4 months ago
I’m a bit confused about the description part, but I recall that highlighting the source of the problem is crucial, so option D could also be relevant.
upvoted 0 times
...
Deandrea
4 months ago
I think we practiced a similar question where traceability was emphasized, so option C might be a valid criticism as well.
upvoted 0 times
...
Hildred
4 months ago
I'm not entirely sure, but I feel like the version of the application could be important too, which makes option B a possibility.
upvoted 0 times
...
Mira
5 months ago
I remember we discussed the importance of including all relevant details in defect reports, so I think option A makes sense since those fields are missing.
upvoted 0 times
...
Brett
5 months ago
I feel pretty confident about this one. The question is asking for a valid criticism, and the missing information seems like the obvious answer to me. I'll double-check my work, but I think I've got this.
upvoted 0 times
...
Denise
5 months ago
I think the key here is to carefully review each element of the defect report and identify what's missing or could be improved. Attention to detail will be important on this one.
upvoted 0 times
...
Charlette
5 months ago
The description of the problem seems clear to me, but you're right that it doesn't explicitly state the source. I might try to rephrase that part to make it more clear.
upvoted 0 times
...
Jennifer
5 months ago
Hmm, I'm a bit confused about the "traceability" part. Does that mean we need to see a link to the original requirement? I'll have to think about that one.
upvoted 0 times
...
Lonna
5 months ago
This looks like a pretty straightforward question. I'd focus on identifying the missing information in the defect report, like the Priority, Correction, and Developer name.
upvoted 0 times
...
France
5 months ago
Hmm, I'm a bit unsure about the difference between "library" and "ad-hoc" control identification. I'll need to think this through carefully.
upvoted 0 times
...
Thaddeus
5 months ago
This looks like a pretty straightforward question. I'll carefully read through the options and choose the three that best match the prompt.
upvoted 0 times
...
Bernardo
5 months ago
I thought it was specifically for WebDAV, but now I'm second-guessing myself after thinking about the repository context.
upvoted 0 times
...

Save Cancel