When Projects Are in Trouble…

When projects are in trouble, why is it that testing carries the can?

Recently, whilst working on a project, the PM called everyone into a meeting room. He then spent the next 30 minutes detailing that the developers were behind on developing the code for all the agreed-to functionality – and the additionally accepted changes. Most of the delays were due to the developers spending too much time fixing the bugs being raised by the testing team.

At this point I expected the PM to say something like, “we’re going to discuss this with the customer and we plan to descope some of the non-essential areas of functionality…”, but what was actually said was, “to give the developers more time, we’re going to cut down on the testing window. This will provide the developers with more time to catch up.”

I checked my watch at this point and, yes, it did say 2017!

Why, in the 21st Century, is it still acceptable for the first response to a project-in-trouble to cut testing time and reduce quality, rather than re-prioritising the delivery of functionality with the customer?

As testers we are referred to as a “necessary evil” when, actually, we are the safety net to the whole project! Surely, it’s much nicer to have a friendly tester or test lead identifying faults rather than a customer CEO raising a concern with your CEO.

It remains the tester’s responsibility to raise issues and defects, but the Test Manager is also responsible for helping to educate the PM’s, Dev Leads and so forth in managing risk and identifying, early on, when a project is veering off course. The impact of constantly accepting change requests without re-evaluating the project’s scope or timelines, at some point, will cause the jug to overflow!

So, testers…
  • Never be afraid to question when PM’s want to reduce testing time, resources or scope to just hit a deadline
  • Never stop raising defects: Let the development team stop fixing them instead
  • Educate your fellow project team members about quality and end user experience and explain to them why we test the way we test
  • Don’t hold up a project just for the sake of testing. Realise that we all only have a finite time on a project and no member of the team is more important than another.
What happened to the aforementioned project, then?

I eventually went to the stakeholders meeting and advised them of the issue with reducing the testing and the risk that would pose to the quality of the end deliverables.

Surprisingly, they were happy to put some of the changes on hold providing we did not miss the initial end date. They understood that not everything could be delivered at once and asked why we had not pushed back earlier.

It seems that our assumption that customers do not like being told “no” had confused the relationship. Don’t be afraid to say, “No.”

Just ensure you’re ready to fire up an alternative solution.