2

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.

|improve this question
2

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.

|improve this answer
  • thank you for your answer, do you recommend any format or practices to do that? – Yahya Hussein Feb 6 '17 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 Feb 6 '17 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. – Yahya Hussein Feb 6 '17 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 Feb 6 '17 at 13:51
2

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.

|improve this answer
2

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.

|improve this answer
  • 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. – Peter M. Feb 8 '17 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 Feb 8 '17 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. – Peter M. Feb 8 '17 at 18:13
2

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,

|improve this answer
1

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.

|improve this answer
  • 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. – Yahya Hussein Feb 6 '17 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 – Peter M. Feb 6 '17 at 18:52

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.