The Next Stage of Software Development Enlightenment

Talk to any product or development manager and chances are they’ll go into great detail about their approach to building software: Agile, extreme programming, scrum, test-driven, feature-driven development, behavior-driven development, lean, and the list goes on. Nowadays, we bump into every method but waterfall, and as a result, from a testing perspective, things have gotten much more interesting. The days of waiting and preparing for testing months before a build are long gone and, as testers, we are now embedded in the beautiful chaos right from the beginning; that is, if it is being done correctly. Ever since the emergence of Agile, project teams have become more aware of the importance of including testing early on and frequently throughout a product’s development, but we’re still left with relatively high failure rates.

Even though “Agile” methodologies statistically reduce the overall failure rates of projects, software quality remains elusive and extremely expensive. Listening to scrum advocates, you would think that the software industry is succeeding nearly 100% of the time. This, unfortunately, is far from the truth. Statistically, success rates have improved, and yet I think it’s still rare to see a project finish on time, on budget and with the full set of functionality that the customer requested. I also believe that the expectations for how software projects should successfully conclude has changed. It is now normal for ongoing development to continue long after the official project is over to make up for all the features that were de-scoped, or for the poor quality of a delivered system. Recognizing and understanding why barely over 60% of projects succeed, and why many of them fail, is important in order to address the challenges that many teams face. Is the root cause in the process, is it the technology, or is it the people?

As testers, we must be masters of adaptation, and rely on cleverness in our approach to software testing, as we are constantly faced with tight timelines, changing scopes, inadequate information, less than ideal test environments, unclear objectives, and ambiguously defined functionality. In my experience, these things are universal truths about the software industry. In the world of agile development, testers are certainly more valued. We are more often included earlier in the development life cycle with improved access to business analysts, developers, and product managers. We are no longer the bouncers at the exit of the bar, but are very much a part of the dance. As testers, we have a responsibility to the client to look at the product from different points of view. We must look high and we must look low, but I’m a firm believer that poor and ambiguous communication is the culprit when it comes to testing processes, regardless of which flavor of “agility” you have chosen. We must listen more, keep records of the exchanges, be less dismissive, and try to look at issues from others’ perspectives. We are at a point in the evolution of testing where I think the processes themselves are exceptionally advanced and unlikely to be the source of prevalent failed projects.

So, if it isn’t the technology, and it isn’t the process, then we’re left with the people, and as Dr. Seuss wrote: “Unless someone like you cares a whole awful lot, nothing is going to get better. It’s not.” I firmly believe that the next thing to improve success rates in software development is the evolution of those soft skills, and who better to lead the charge than us, as testers?