Non-go live critical defects / issues / bugs
I am new to the role of testing lead and i'm in charge of a team that have very set ideas around going live with known defects / issues / bugs. They seem to want to go-live with zero defects and they thought of going live with a known issue horrifies them.
I'm trying (not very successfully) to win them round to my way of thinking, which is that most software products go live with known issues as long as they do not impact on the overall functionality of the product and that they can be fixed at a later date.
Does anybody have any advice on how to win them round?
What kind of software is being developed? For some kinds of software (life-critical, business-critical, etc) it may be appropriate to never go live with any known defects.
Originally Posted by kevinmiller
Is this team new to software? Perhaps they just haven't experienced the "real world"? How did they come to have these sets ideas about releasing? What in particular horrifies them? I've seen teams that were repeatedly criticized so harshly when any bug was discovered by a customer that they have reacted by basically being afraid to release anything at all. I hope that isn't your team.
One tactic might be to ask them if they know any company at all that never goes live with any known defects. Perhaps their vision of the model company doesn't match your company.
Another tactic might be to have them read and discuss Perfect Software: And Other Illusions about Testing by Gerald Weinberg, or Lessons Learned in Software Testing by Kaner, Bach, and Pettichord. Lots of good, practical ideas there.
Still another tactic is to explain to them that while their opinion is important to you, you are in charge, and that the business decides when the software is "good enough", not them. Their role is to inform the business so that the proper decision can be made, not to be the gatekeepers of a go/no-go decision.
Make sure that the team is incented properly. In particular, make sure that you aren't undermining your company's ability to release by incenting testers to prevent the software from being released. I've seen that happen in the past.
Last edited by Joe Strazzere; 01-21-2013 at 09:00 AM.
I have sort of the same issue where I am. The President wants a bug free version to go out, which we all know is not possible, especially on an application the size of ours. He thinks we should regression test the whole system for every bug that is found. Luckily I have the CTO who I report to who understands that is not reality and we are trying to manage the expectations that all software for the most part will go out with bugs. What I told him was if we know we have known issues, we will send those out to the customers within the release notes so they are aware that we are aware of issues and that they are being worked on. It also helps if you find work around's for the bugs so the customers can use those. I told the Prez, hey we can regression test every bug, but we will never release anything on time, let alone at all because we will be caught in this endless loop. He is coming around slowly but surely.
The software being deleveloped is essentially an e-shopping application, so nothing too scary and certainly nothing life critical. When defect reviews are carried out, a business representative is present to give thieir view as to whether or not the software could be relased with a certain level of defect present.
I am more than happy to use a risk-based approach. It is a couple of members of my team that want all defects (however minor) to be corrected even though the end business representative has said that the software is acceptable.
The team has used the software for a number of years and i feel that they think the software should be 100% perfect before release and all incidents (low priority and low severity) should be fixed even though this would be to the detriment of releasing on time.
In my opinion, theses can be picked up at a later date in a maintenance release.
Have you tried to explore why they feel this way?
Originally Posted by kevinmiller
While everyone wants software to be perfect, most of us realize that perfection isn't realistic, and that there are diminishing returns to chasing every single bug.
In my experience, there are several typical reasons for testers to feel that 100% perfect is achievable and desirable.
1) The testers are inexperienced, and haven't worked in a real business environement long enough.
2) The testers have been punished for bugs found post-release in the past.
3) The testers have been managed by someone who didn't understand the real world of testing.
4) The testers have never been instructed on the relative importance of schedule versus quality in your shop.
Once you dig in to the root cause behind their feelings, you can be on the road to changing them.
Again, many thanks for your swift and comprehensive reply.
After an "open" meeting yesterday, it would appear that these feelings come from a combination of 2) and 4).
I will hopefully be able to address these issues and get and on the road to changing them.
Come back and bring us up to date in a while, ok? It would help everyone if you can tell us how you have addressed these issues, and what kinds of improvement you see, if any.
Good Morning Joe,
We had a good meeting and all the issues were discussed. The main thing to come out of the discussion was that in the past the QA / Testing team were given alot of flack for any bugs that were discovered after a product went live.
I explained to them that if we were to fix every bug / issue / incident that was found then we'd have an amazing product that no-one would ever see because it would be in an endless testing loop.
We have regular defect review cycles involving the business stakeholder who makes the ultimate decision based on the informarion provided by the testing team on whether or not the defect is acceptable and can be corrected in a maintenance release at a later date.
A project is beginning next week where we will trial this new approach.
kevinmiller - thanks for coming back with the update!
Sounds like you are on track to change the teams's attitude.
Shifting the ultimate decision about bug fix/don't fix from the test team to the stakeholders (where I believe it more properly belongs) is a big culture change. Shifting the team's responsibilities from gatekeepers to trusted advisors is big, too. Expect your team to struggle as they accept this change, and be as supportive as you can. You'll need to try and make sure they feel that these decisions are a shared responsibility, and not their burden alone. And you need to make them feel safe that they won't be made a scapegoat again. Make sure the stakeholders understand their increased responsibility, too.
I think if you can help your team through this transition, they'll be happier in the long run, and can help advise the business about the more difficult (but more important) decisions about deferring fixes to a later time. It's easy to take a black-and-white approach "all bugs must always be fixed". Not much thought required there. It's much harder to advise the stakeholders "Here's why we think it's safe to live with this bug for now." Scary stuff. But conveying to your team that you value their advice in helping to make these touch decisions is pretty powerful.
Tags for this Thread