I am a developer who just started a new career in QA, right now I am still learning the basics.

While testing a project I see violations of some coding standards (Variable names, Web elements without names or ids, etc..) in parts of the code that will be seen by the customer.

My question is, is it my job to report them? after all reporting, such things will increase the product quality.

If I should report them, what are the best practices for that from your experience?

Any ideas will be much appreciated.

5 Answers 5


I would and did.

I suppose it is not part of your job definition, as the average tester doesn't have enough knowledge to spot code quality issues. But why not ? if it doesn't waste significant part of your time (and be careful not to go there) then everyone will gain from that.

  • thank you for your answer, do you recommend any format or practices to do that? Commented Feb 6, 2017 at 13:00
  • Since you are an ex-developer just use any format you prefer, or even better for the first few reports communicate with the relevant people before you report
    – Rsf
    Commented Feb 6, 2017 at 13:42
  • thank you very much, How can I convince my team leader, he is not a developer and he does not care about reporting my findings in this field. Commented Feb 6, 2017 at 13:46
  • be prepared to not being able to convince him, but try to a. explain him the facts and that it will not waste your and the team's time b. talk to the relevant developers and ask them to help on a.
    – Rsf
    Commented Feb 6, 2017 at 13:51

Find out your company standards. Some companies do not have standards, or have code where some standards were not applied correctly.

Before reporting, ask what should be reported. Maybe developers want to fix standards. Maybe they had the debate and decided not to care. Maybe there is a cold war between two groups using different standards - and you (as new QA) do not want to make it hot war.

There is no replacement for communication and asking the questions before forming opinion.


Report it, and set the priority appropriately. If the missing identifiers or classes or what not are causing difficulty, then it's obviously a higher priority than if it's missing but unused.

Part of QA is to know what's important and what's not, and communicating that out to the broader team.

  • Your second sentence contradicts the first. Some "errors" should NOT be reported, if they are only errors in POV of freshly minted QA, but not for devs or business side. Don't start a war which you do not want fight. Commented Feb 8, 2017 at 16:20
  • I think you're actually referring to the 3rd sentence (2nd paragraph). I wouldn't say it contradicts, but sure, depending on the company, the attitude could be that some issues don't get entered, other places want to track everything, etc.
    – ernie
    Commented Feb 8, 2017 at 16:22
  • You are right, 2nd paragraph. And you are right about the company "culture". So new QA needs to find out what "culture" is. No reason to try to change the culture as new QA - not a good way to make friends (open communication channels) and establish your competency. Commented Feb 8, 2017 at 18:13

Question together with the team if elements really need names or id's. Just adding them without a real need seems overhead. Apply the YAGNI princible. Do not create extra work if you do not really need it.

Ask the team how they want you to report it, this if you think something might be an issue. Signaling things are missed during code-reviews are good. Coding standard should be part of the code-review, not during the manual testing phase.

I would not create tickets in a bug reporting system for each minor issue, better to discuss face-to-face with the development team. Certainly do not flood your managers with issues like this. Never underestimate "reasons" the team might have for things like this. Unless the team is systematically taking shortcuts that endanger quality, then I would singal management,


Adhering to right standards in software development enables you to deliver the right product in the right way at the right time.

So always report the wrongs. The early they are reported the cheaper it is to fix them.

  • I have one issue left, my team leader is not a developer, and the issue I am highlighting is not valuable for someone that does not write code or debug a code. Commented Feb 6, 2017 at 13:03
  • 1
    Reporting issues which are issues for QA ("right standards") but not for developers will get you nothing but wrath of developers. If developers have a reason (even if you disagree with it) to do things certain way, you will have hard time to persuade them otherwise Commented Feb 6, 2017 at 18:52

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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