Cory,
Thanks for such a thoughtful response!

Great answer.

That was an interesting question. In my experience, it depends on the organization, and whether you can influence people that are in a position to affect the changes in the areas that need them. I have had some degree of success (again, depending on the organizational culture) with this problem.

The approach that I prefer is to drive the conversation by using metrics. To do this, you spend some time collecting metrics (by “metrics” I mean down time, severe bug counts following releases, customer impact, possible lost revenue, etc) that illustrate the relative cost of the lack of QA. Dev-ops is your friend here – get real numbers if you can. Once the management layers see real data that speaks to real cost or dissatisfied customers, they might start to pay attention; that means you might get support for some pilot initiatives or similar targeted efforts to prove out your ideas. This can be a risky approach, because some organizational cultures are more insecure than others; socializing metrics can get you into trouble in those cases. If you try this approach, figure out who you can trust to help you make your case, or to watch your back. Make sure you have your master plan up your sleeve so you are ready to execute it 🙂

The other approach that I have used is the direct proof of concept. This is where you find a way to actually do real TDD on a project, or a part of a project. Sometimes you might need permission for this, and sometimes you just “find a way” to do it regardless. If you can find a way to directly illustrate its value relative to the current practice (e.g. “wow, zero bugs with TDD as opposed to 100 bugs a week without it!”), then you can start to drive a conversation around it with meaningful ammunition to support your position.

A third way that might work, but I have only seen it in very proactive environments, is to bring in some outside experts to help you make the case. To do this might require the organization to accept that there is a problem – which, IMHO, can be very difficult and seems to require the metrics-driven approach anyway.

Not easy, of course, but with some savvy, some persistence, and proper framing of the discussion, I think it can be done.

Just my $0.02, hope that helps. Good luck!

That’s a difficult one. I start by asking them if what they are doing is currently working.

Hi Dan, I’m familiar with exploratory testing, but I have to be honest, I don’t like itu2014in most cases. I’ve seen it very unstructured.nnnI still think we should start with automated test and make them pass in Agile environments.nnnAfter consulting for many companies, I have always gotten the best results with this approach.