-2

Backstory:
As the single developer with experience in the chosen technology, a month ago I drafted a component that for all extents and purposes worked within acceptable levels according to the demos that were had.

Four weeks and assorted developers later (that´d be more or less last Thursday), the feature entered QA and since then I´ve been given 8 showstopper bugs, around 25 critical ones, 47 majors and a single minor one.

I´m beginning to harbor a grudge against this people, but then, they're making their best to actually improve the quality of the product, so I really shouldn´t. At the same time, I also think I have a right to sleep/eat without having nightmares of showstoppers appearing on my inbox.

What´s a polite way of handling this situation? I´ve gotten most of the former developers on board with this, but the QA folk continue to report all their bugs to me and upper management keeps asking me what I´m doing about them, so I´m growing considerably more anxious each day that passes by.


More details: About one in thirteen bug reports are actually addressable by me (about one in three of those is actually caused by code I wrote), the rest of them lay in code that is honestly foreign to me at all. Yet I´m the one getting the reports and being ad-hoc in charge of distributing them to the right developers. I´m not the team lead. Judging by the amount of work I´ve been given someone seems to think I´m actually a team of people under my name. All jokes aside, the actual team lead is on extended leave without an explicit replacement, and the most senior dev in the project is actually spearheading another module for the project, and I´ve made it abundantly clear that I´ve had 0 involvement in the project for about four weeks already. The reason I´m posting this is because I´m running out of options for reals, not just imagining things.

  • 4
    How are the QA folks "shafting" you? Do the bugs exist? Are they correctly categorized? You haven't indicated that the bugs really aren't there or that the severity doesn't reflect reality. It sounds like you had a first draft of a component that has some significant bugs that need to be addressed. – Justin Cave Sep 9 '13 at 23:52
  • 1
    OK. So almost all of the bugs have been introduced over the last month by other developers? Are you the team lead for the project? If so, assigning bugs to the appropriate developer seems like a pretty reasonable thing to ask of the team lead. Is someone else the team lead that should be taking care of assigning bugs to appropriate developers? It seems unlikely that QA could determine which developer wrote the code that is creating the bug. – Justin Cave Sep 10 '13 at 0:33
  • 2
    is there someone else that is the team lead? Is there someone else that could/ should be assigning bugs? QA seems to think you're the lead. Management seems to think you're the team lead. Do you want to be the team lead? – Justin Cave Sep 10 '13 at 1:07
  • 1
    What is your relationship to management and to the other developers. You talk about your "client's QA folks" so I'm guessing you are a contractor. Is the management you refer to management in your company? Or in the client company? Is the rest of the team comprised of developers from your company? Or the client company? Is there a client engagement manager? – Justin Cave Sep 10 '13 at 6:30
  • 3
    I am going to say it: Their job is harder because you didn't do yours. Stop for a moment and think how they feel haveing to waste so much time finding and reporting your defects. The fact they have so many bugs is a problem, maybe you are not prepared to own it, but it does not make it any less of a problem – mattnz Sep 10 '13 at 8:13
6

I'll echo what other people have said and emphasise that the QA are just doing their jobs and more importantly, you need to remember that QA get blamed for every bug that makes it into production.

I've been in your situation and the best solution I managed (I was getting 100 bug reports a day) was to ensure I sat in on every single triage meeting with QA and the product owner - we quickly pared them down, got a good working relationship and in the process of those meetings - managed to temper QA's quality expectations.

Don't get angry with them, work with them.

5

I think the problem is not that you're swamped with work, but actually a good process is missing. For you to be able to sort this out, have a response mechanism/process for each kind of bug you have described.

For example, showstopper bugs are dealt with according to gravity of the situation (not as they arrive). Critical bugs are of higher priority in fixing over major bugs. Your QA folks should be able to properly tag and categorize the bugs and order them by need of fixing.

Also, it is worth considering, that you have a finite time at working on this. You can reach to a bargain with your upper management that you may work overtime for showstoppers / critical bugs outside of your working hours for a possible extra overtime pay. Otherwise, suggest that you need another hand for temporary bug fixing.

  • You have a pretty good point; I´m starting talks about time management already, and kind of negotiated them away from their apparent "there´s no such thing as a minor bug" initial policy (the only minor bug I got was actually a refresh rate issue) to a more acceptable one; that still hasn´t left me a more confortable developer, but I guess it´s a step in the right direction – Carlos Vergara Sep 10 '13 at 0:07
5

Based on your comments, the real problem is that the project team has been redeployed prematurely and you don't have the resources to deal with all of the bugs that are being reported.

It is not the QA folks' fault. They are just doing their job as they have been directed. Don't blame them. It appears that the fault lies with your management and their decision to pull resources from the project too soon1. (Or maybe on the previous project lead who swept too many problems under the carpet in his haste to call the project "finished".)

1 - Or maybe it is management's fault for saying "it is done" to the client too soon, or for a signing a contract that allowed the client to raise fault reports against stuff they previously signed off.

What can you do?

Well, I think you need to bring the problem to management's attention, and get them to get involved with solving the problem. I would suggest that there are only two rational approaches:

  • Management needs to redirect resources back to the project.

  • Management needs to assist you to manage your workload by doing such things as:

    • negotiating with the client to reclassify and reprioritize the bug list,

    • pushing back on unrealistic client deadlines to get bugs fixed, and/or

    • negotiating with the client's QA folks to alter their quality goals.


Another answer suggests that you should get management to approve (paid) overtime. I'm not sure that's a good idea. IMO, you'd be better off if the pressure on you was relieved, one way or another. (But if you do have to do overtime to deal with this mess, you should be paid for it!)

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.