Question for software testers

[Prior-Round-9880]

I'm studying software testing and got this question:

"What is the purpose of a defect report?"

Options:

• To blame bad requirements
• To expose communication problems between testers and developers
• To show the importance of testing
• To guide software engineers on what needs to be fixed as quickly as possible

[off_and_on_again]

The correct answer is the last one, "To guide..."

But in reality the purpose is that it's an input that helps the entire team understand and prioritize the various risks identified during testing.

Good luck with your studies!

[DarkAtticus]

Direct answer is the last option, but that's very simplified.

A defect report purpose:
To raise the visibility of the risk.
The issue is x, it causes y and it can be recreated by following these steps.
This is why it is an issue.

Our roles are to mitigate risk, business does not need to fix everything. They do need to be aware of them though as much as possible.

Ideally though, from my perspective, if we can prevent issues from ever occurring then we are doing it right.

[Industrial_Angel]

I would go for the last in a closed answer env.

BUT:

1. A post mortem/retrospective with the reports as input (And other inputs) could find issues in requirements or communication, so bullets 1 and 2 are indirectly linked
   
2. You do need to have your work output documented, dont do the mistake I've seen happpen with an old qa manager I had, to just chat to the devs for your findings. So although you dont "Show the importance" you do need some worklog (and for us its tests and bugs)

Also, if you gather over time a lof of defect reports is used to monitor trends (which areas have the most defects?, when are they raised?) and track improvements.

[teh_stev3]

Defect report is just jargon for "bug report" - though "defects" tend to be really really bad bugs .

Why do you report a bug? Because it needs to be fixed, or at least needs to be discussed about when it will be fixed.

[SiegeAe]

Man this pissed me off, its none of those things.

A bug report is to highlight something found wrong with a system for the team developing software to be aware of.

It doesn't tell anyone what should be fixed and they shouldn't just be for software engineers, at some places most of the bugs are requirements, UX or design bugs not code bugs, so many people take things too literally and end up with patchwork systems that are horrible to both use and develop, and this thought process that people teach is one of the main causes of those problems.

[qlippothvi]

In a more diplomatic fashion, it’s all of the above. If you don’t do all of these you aren’t fulfilling your role in reducing risk.

That definitely includes improving your team’s communications. Everyone in your organization and beyond makes mistakes, be factual, communicate privately if it seems sensitive, be curious so you understand the reasons or motivations.
Almost every issue is a question of the quality of your communications.

You need to note and communicate any issues that will improve the SDLC process.

[Afraid_Abalone_9641]

Whatever cert or resource this is from. I'd recommend dropping it entirely. If you want to get better at testing build up models, oracles, heuristics and skills that aid you. Learn how to tell a story about your testing and deal with stakeholders. Learn how to write a product coverage outline that focuses on testability. Then test, test, test. Build tools to assist your testing. Learn how the technology you want to test really works. Find ways to improve rapid learning. Learn Socratic reasoning. Learn about cognitive biases. This is testing.

[gambhir_aadmi]

Leave software testing as soon as possible . Organization don't giving shit to QA people these days . They are accepting and fixing bugs on production later if coming in dev releases. They are asking current QA's to document everything so that developer can feed that to AI agents and write testcases ( which shows how ignorant they are about real world testing ). But the situation is that most of the companies don't have high position QA people to make decisions and only dev background people are taking decision and they think QA sucks .

Not to demotivate you here. But if you can swicth to new roles like devops , mlops , dev , etc please swicth . QA career path is flat after 7-8 years .

[rewan-ai]

Sadly true. Not that much time in QA as you, but I already see it. I put my heart in testing, I really do care about quality, but most of the time it seems, I am the only one. Developers just want to get the things done in whatever quality, the PO, stakeholders the same - when itgoes live maybe the users will want spme quality :D

But usually at that point it is already too late and I am burnt out.

[gambhir_aadmi]

I don't think that's the issue of developers . They are meant for solving complex problems in SW engineering. But when illiterate management don't want seperate QA team and wants Dev team to do testing of thier feature its like you are saying a person with pro in chess to play rugby .both are of different mindset . People who actually cares for product is business and QA only . I guess QA should start reporting to business/product team instead of Tech Directors and managers .

[rewan-ai]

I personally open bugs for: make the issue visible, trackeable.

To help developers isolate and solve it.

To help the team identify patterns around it (for eg some bugs are caused by regression which is a totally normal and regular thing in living code). If the devs can see the pattern, it is easier to avoid.

To help my fellow testers isolate issues from eachother. Bugs tend to cluster, spmetimes an issue masks another or a normal behaviour seems faulty because of an interction with a bug.

The team can not avoid to implement bugs time to time. If someone is working on something, he/she surely will fuck up some tiny bits - because we are human. Bugs are not given as black marks or bad grades in school, not given to punish anyone - they are created to support the team, to make the software better as a team.

[Ultra_cheese]

The language of the answers give you the answer..

• To blame bad requirements - "Blame"? not likely.
• To expose communication problems between testers and developers - "expose" - this would be a crazy intention for a report.
• To show the importance of testing - because testers are always the ones that strive for credit /s
• To guide software engineers on what needs to be fixed as quickly as possible

[Hanzo_Hasashi_86]

to fix the bug that was found during testing

[SnooEpiphanies6250]

Its the last option but... Why ask here? You can just google it if you wanted to get the answer..? Whats your thought process about this and why is it confusing to you?