should I help QA team in finding bugs?

Question

I Just started my career as Consultant Developer and Joined a small company. When I go through the code for an already developed application, I can see that there are some bugs. I inform the QA team about these and ask them to open defects so that I can fix those bugs but QA team is not taking it in a sportive way..

Is this something unprofessional?

EDIT: About work environment: Product Manager wants every small thing to be entered in bugzilla that is the reason I ask QA team to open defects. Also I don't have access to the QA environment so I ask them to check if a particular branch of code is working fine in their environment.. I can open bugs in the system but I thought this would be more offending than asking them to open.. I just want the product to be bug free..when it leaves the company but no other intentions..

Answer 1

When I go through the code for an already developed application, I can see that there are some bugs

These small bugs should be found during dev testing and after dev testing developer should also run the application to make sure it works as expected before passing it to QA so right there already something is not going very well.

I inform the QA team about these and ask them to open defects so that I can fix those bugs

If the code being deployed to the QA environment is buggy and then you are asking them to pass it back to you so that you can fix it I can totally see why they would be weirded out a bit. It's really about expectations and in this case they were expecting that code being deployed is going to work, if it wasn't working then why was it deployed in the first place?

Communication is key - so if for some reason there is a separation between you and the actual dev team hence this problem then I would recommend talking to them about it and explaining to them the actual mental process that you went through yourself.

If there is no separation between you and the dev team and you were responsible for that code in any way then yes it is unprofessional because it has been released without being thoroughly dev tested.

However, I assume that is not the case because you have found the bugs half way and were just letting them know about it so talking to them and explaining the situation would be the best thing in this case.

Answer 2

I worked for a number of high-profile corporations. It was always gladly accepted if a person opens a bug when [s]he discovers a bug. No matter who that person is, and whose responsibility that bug might be.

If somebody could be offended by having a bug filed against their code, these people act utterly unprofessionally. A developer should be as egoless as possible, and a bug report should be as blameless as possible. This applies to post-mortems, too.

There is no blame, and no guilt; only defects that need to be discovered and fixed. I suspect you don't practice code reviews either; you should.

Answer 3

I can only tell you what I do. First, if you see a bug then it's "your fault" and you should enter it into the tracker, write a test case proving the bug, fix it, and submit the fix. If the QA teams sees a but then it's "their fault" and should be entered in the tracker with steps to reproduce.

Now it's not really about fault, it's more about long term responsibility. When you do a meeting to talk about progress, who is going to be "boss of that bug". The best answer is usually the one that finds it. Meaning that the team putting in the bug is the one that needs to be going "did you fix X yet".

Even more important is the fact that not every bug is going to be fixed. In the real world you have to manage bugs v.s. time constraints and other costs. It's "ok" to have a bug that's not going to get fixed in the next version, as long as everyone knows where it is, and there's a clear expectation of when it will be fixed.

So, first if you see a bug enter it into the tracker. Handle accordingly. A documented bug is 1000 times better then an undocumented one.

Now as for telling the QA team to do stuff. I personally think it's none of my business what the QA team does. As long as they find bugs and get them into the tracker in a agreed upon format, then I'm good. By having that separation I feel that I maximize their usefulness (finding "bugs" that arise, not because code faults, but because of mis-understandings). If I am giving work direction then I feel like I am not letting them do what they need to do. As have even gone as far as refusing to help them do something in the app so that we could see if the stuff they needed to do to accomplish their task was intuitive enough.

Finally, depending on company structure, you shouldn't be telling QA to do anything. Do they report to you? Do you sign their pay check. More often then not QA is equal to Dev in the corporate ladder. Telling someone to do more work is definitely not your job (unless it is). That does not mean you don't work closely with QA, you should be. At the same time, there not part of "your team" so hands off.

Most importantly from all this is:

• If you find a bug, enter it, and handle it. Don't ask others to
• Don't give work direction to other teams, it's not your place

Remember, this is very different company to company. This closely matches "what I do". But different companies will do things differently. You should either use their SOP or work with them to develop a SOP document.

I also stayed away from management, organization, or planing techniques. There are a lot of questions answered if you adopt one technique or another.

Answer 4

Yes, you should. Software quality is the responsibility of everyone on the project. Ok, let me backpedal immediately... you should actually open the bug yourself, if that's what your manager says you should do (after checking to make sure it isn't already reported).

Having a wall between the two groups is counter-productive, in my opinion, because it leads to blame, accountability problems, and poor communication. If anyone is defensive or aloof, the problem is them, their team leadership, or the leadership of the company. Recognizing that as a contractor is important, I suppose, so that you don't step on toes and compromise your status.

All bugs should be tracked because, except in some rare cases, all software of a certain size carries a backlog of bugs. Understanding the backlog is important when choosing what to work on, whether or not to release an iteration, and planning for the future.

Answer 5

Looking at the title "should I help QA team in finding bugs?"

My answer is No, or at least only incidentally.
You should focus on helping out the users of the product and thus the future of the company by having products that are bug free.

The bugs you see will exist for a wide variety of root reasons which may be that they've not been noticed or complained about but may also still exist because there's other more important projects, not enough revenue from the product, no good ways to distribute patches the product, documentation that actually includes the bug, etc, etc.

Make a case for the item to be recorded as a representative of the user.

Getting access to the bug tracking system to enter bugs can be good, however don't expect to suddenly inject a bunch of work into existing workflows without comment. What you really need to do is get more senior management on-board with this and have them notify folks about these tickets and allocating time and effort for them.

Do not try and slip-stream them into current tickets because you will generally get the feedback from the developer that "that has nothing to do with this ticket and I didn't touch that area", plus "it was like that before my ticket". So that approach tends to be a non-starter.

Basically you need to get your input working along with everyone else towards making a good product.