Tuesday, March 04, 2014
Is Software Testing Once Again a "Concept Sale?"
Back in the day (1990 - 1995), test automation tools were a concept sale. People had to be shown in very clear and compelling terms what test automation was and how it was helpful. After a few years, people understood the need and value, so the questions started moving toward, "Which type of test tool(s) do we need?"
Based on what I see in terms of software quality overall and hear in conversations with c-level execs, I get the feeling that software testing is going down the same path as other quality-related practices, such as six-sigma, TQM, requirements engineering, standards, etc. Yes, I fear that software testing is quickly becoming a "concept sale."
What used to be considered an essential part of the software development life cycle, is now in danger of becoming a secondary and optional part of the life cycle. It's certainly not that way in all companies, but I see a clear trend emerging that companies are willing to take huge risks in releasing largely untested software.
It seems that management knows that testing is needed, but it is a luxury. The attitude seems to be that defects found "in the wild" can be fixed cheaper and faster than before release. Risk is secondary to release dates.
Does that mean that "testing is dead" after all? Well, it reminds me of the scene from Monty Python and the Holy Grail, where some people are trying to put a man on a cart, but he keeps saying "I'm not quite dead yet."
I have no easy answers on this. All I can say is to: 1) keep showing your value by being an information provider of things beyond defects and failures, 2) be professional and continue to work on your skills (get better at providing feedback, learn how to notice details better, become a creative thinker, etc.), and 3) keep making the message that testing is a lifecycle activity, integrated into a development process. (I do think it is significant that the concept of a software lifecycle is also a confusing and elusive topic for many companies.)
The particular method of developing software isn't the issue. The same thinking goes for architecture, requirements, design and all the other disciplines that make solid software. The magic is not in the method. The magic is to understand user needs, deliver to those needs in value-added ways, and know the solution actually works by testing it!
Don't assume that everyone understands why testing is needed. Be prepared to show the value of your testing at a moment's notice. Dashboards are a good way to do that. In fact, I have a presentation on this posted on YouTube and Slideshare.net.
You never know when you'll have to make a concept sale for testing!
I would be interested in hearing your opinions on this.