QA tasks in scrum

It is not in alignment with Scrum values and principles to "look down upon" QA specialists on a team. In fact, Scrum does not recognize titles for Development Team members or sub-teams within the Development Team, even though individual Development Team members may have specialized skills.

Based on your description, it seems like there's a disagreement between the development specialists and the test specialists as to when to log a bug in your issue tracking system. In my experiences, there are two types of issues to consider - those found in new work that is not yet delivered and those that exist in released and deployed systems.

The best thing to do is for the team to come up with a working agreement on how to handle these. I do find that it is more important to track issues that were discovered in a released and deployed system in the issue tracking tool. These are escapes - defects that went through all of the development and quality assurance activities yet were not detected and removed - and can provide insight into how to improve the team's way of working to prevent similar escapes in the future.

As far as how the top managers know about work, there needs to be some level of trust involved. I would assert that a low number of defects found in released and deployed systems would indicate a high-quality development process. Even if you don't log defects as separate issues in the issue tracker, you can often use your issue tracker to obtain information about incomplete or rejected work in other ways.

An agreement on how to identify and track the work that satisfies everyone's needs can be reached, but it will take time and discussion. It also requires a level of maturity of everyone involved to understand everyone's perspective, determine options, and weigh trade-offs.

As a long time QA professional(25+ years) I want to start with reminding you that QA doesn't just find bugs. They ensure that the process is quality centric and should be preventing bugs rather than just testing at the end to find them. Prevention is cheaper and faster than discovery late in the process.  Now for the Scrum stuff.

As I said, I am a long time QA profressional and here is how I viewed defects in agile organizations. As long as the defect exists it represent negative value. Since my job as QA is to prevent defects in released software, if I do find a defect while testing a Sprint Backlog Item, I go directly to the developer to show them how to reproduce so that they can fix it immediately.  That eliminates the negative value faster and increases the positive value of what is trying to be completed.  I don't bother writing a ticket because in reality that ticket means nothing in the long term.  The defect never made it into the product used by the end user. 

However, if a defect I found is determined to be ok to leave in the product and fix at another time, I will add a Product Backlog Item to describe the defect so that it can be refined and pulled into a future Sprint. If a defect is found in Production, again an item is placed in the Product Backlog.  Notice I didn't say a bug ticket, I said item.  These issues are just things that represent work needed to the product in order to keep it relevant and add value.  So I use the same item type as is used for product enhancements.  This helps to handle everything in the same way.  If you use separate items types for features and defects, there is a tendency to use different criteria and methods for handling them.  They should all be treated equally and the Scrum Team addresses the items that provide the best value. Just as a defect represents negative value as long at is exists, a new feature presents negative value as long as it does not exist.  So the decisions on whether to work on a feature or a defect should be made based on which provides the best positive value at the time. 

Having a history of bugs found really has no value.  What your top managers should be focused on is how much value has been delivered to the end users represented by the usage of the products and trust that the Scrum Teams are doing all they can do ensure that the value delivered is of high quality.  

I’m working with a team who got upset when they notice any bug in Scrum board, Don’t they have the right of objection ?!

Do they disagree that these are defects?

Testers are part of the Development Team. If there is a division between Developers, Testers, Solutions Architects, and other roles on the Development Team, I would recommend that you play a facilitation game to bring that team together and teach them that they are all on the same team. If there is a bug, it is everybody's to solve.

Do they disagree that these are defects?

No they're completely agreed it's a valid defect, but they insist to fix it internally without reporting it, so the top management will see the scrum board without any defects!

please note that when we -tester- found a defect we call them directly to fix it while we reporting.

my question is, Does scrum prevent or recommend that the tester  shouldn't report any defect!

Does scrum prevent or recommend that the tester  shouldn't report any defect!

The team should know how much work remains to be done, including the repair of any defects found on items that are currently in progress. This repair work ought to be made visible on the Sprint Backlog.

If a defect is found in an increment that has already been delivered, it should be added to the Product Backlog, and managed by the Product Owner for remedy in a future Sprint. He or she can negotiate with the team to conduct an urgent repair if necessary.

Remember that a backlog is an artifact that supports transparency, inspection, and adaptation by people doing the work. It is not a tool for reporting to management. Are managers using transparency in a way that the team finds unhelpful?