Are Testers to Blame for Missed Deadlines?
In the world of software development, there are a number of reasons why a project might fall behind schedule. It could be an absurd, last-minute requirement from the customer. It could be a massive, unexpected reduction in your company’s workforce. It could be that a giant monster destroyed your Sim City industrial park. But if you ask a dev manager in Europe, they’re likely to tell you that deadlines are missed due to out-dated testing methods.
A company called CA Technologies interviewed 301 in-house development managers (an odd number, yes?) from the UK, France and Germany. Of those people, more than half (56%) said that “their IT department’s reputation had been tarnished because of issues relating to ‘out-dated’ application development and testing methods.”
Here’s PCAdvisor with some of the specific details:
While 59 percent of UK respondents cited quality and time-to-market on integration testing as a major challenge, it was lower (48 percent) across all three countries. In the UK, 41 percent had issues with performance testing compared to 32 percent overall.
A prominent factor in the UK element of the research was the sheer number of releases expected to be delivered, with 41 percent of UK respondents stating they had to bring out ten or more releases a year. This compares to just 26 percent of respondents in France, the next nearest country.
Outdated application development and testing is having a major impact on UK enterprises, with 76 percent of respondents sighting loss of reputation in the market as a major concern. Furthermore, 67 percent were worried about reduced application functionality negatively impacting customer experience.
Almost half of all UK respondents (48 percent) are now already looking to move towards cloud-based development environments and 46 percent to agile development methods.
So will Agile cure what ails them? Last week, we started a good debate on the costs (and benefits) of switching to Agile. One of the more insightful comments came from Mike Koepke, who wrote:
“(With agile) we are much better able to accurately estimate and complete our work in 3-week chunks rather than 3-, 6- or 9-month segments. We still do long range release planning, but by completing deliverable code every sprint, we remain “agile” with respect to the scope of what gets delivered when we hit hard release dates. The key to making this work is having full buy-in by our product managers, who are active members of our scrum teams.”
What do you think? Are outdated testing practices to blame for missed deadlines? And is Agile the solution? Sound off in the comments section.
Let’s look at the history of Agile. Where did it come from? Kent Beck and Ron Jeffries, two of the biggest frauds and con artists in the industry, failed to get the Chrysler Comprehensive Compensation System working for but a fraction of the employees of that company despite years of Extreme Programming development and testing. After that failure, they got others together and reheated XP as the Agile Manifesto.
And some of you drink the Kool Aid that Agile is a silver bullet. You fail to learn anything from history. Some say, “but only if everybody has 100% buy-in and commitment!” You sound like the old Marxists who don’t believe Communism was done right anywhere it was tried.
Testing is almost never the reason why software products are late. Bad management is largely to blame. The director who can’t say No. You know what I’m talking about. Then you have the scope creep caused by programmers trying to implement late additions or remove things on a whim. It’s not usually the programmer’s fault they have to deal with a PHB. Since Testing is at the end of the chain, let’s just go ahead and have everybody blame testing. That’s OK. We’re used to the abuse. That’s part of the game.
All this other stuff, the stupid war the Agilistas have between “Waterfall” and anybody who criticizes Agile, is a sideshow. It’s noise. You Agile devotees go run off to your scrums and turn into consultants. Maybe go attend some more conferences. You’re boring and useless.
Regardless of the methodology, test will be a popular scapegoat at any company where testing is viewed as an adversary to development or the “red headed stepchild” of the R&D group.
And I don’t see Agile really changing things where I work. There are tests on the development teams. But, there are still the “system test” teams downstream from the scrum teams to blame when deadlines are missed.
Although, with the fractures between the in-house and outsourced dev teams, the outsourced teams are a popular scapegoat right now and not the various test teams.
Although, I have heard one manager say that some of the test teams are worse than others. So, there is that.
Bottom line, there will always be scapegoats. And test will always be a popular one unless you have management that doesn’t allow finger pointing.
In the 90s as program code became larger, developers were unable to thoroughly test their code, so there came the boost of SW testing.
Suddenly a smart guy (young – who does not recall how we got there in 1st place), decides that he has a remedy – let’s ask developers to test their code – it would have been a really simple solution, if only history will not repeat itself…
While unit tests are very important for meeting the deadlines, automating these and other narrow view tests aimed for initial stage go-no-go checks, while essential to that stage – are useless and wasteful for following stages which can run faster by regression samples and complicated scenarios.
And now agile suggests that what should have been throwaway tests (and unfortunately many used them as main tests since they had no time to rewrite into regression), will become the main path.
These have no system view, and failures will soon rise.