When we're unsure of what to test, the project might be at risk of failure.
Tests turn our client's ideas into unequivocal specifications. They make the bridge between what's on a customer's head and what we need to build. If we can't write tests, we're lost on what we need to program.
That's a fast track to disaster.
We might think it's the client's fault. After all, we're unable to write tests because requirements are vague and volatile.
But pointing fingers never solved any problems.
So what can we do?
A really effective strategy is to reduce the scope of the current release.
Smaller deliverables mitigate two common reasons for failure to clarify what software should do:
- Trying to discuss too many features at once.
- Insecurity on what the application has to offer to succeed.
A narrower scope means we have less to focus on at once. So there's more time and energy to dig deeper and define concrete requirements to guide our acceptance tests.
With less to develop, we can ship faster. Thus, get feedback from the market sooner. That will shed light on what the app should do to satisfy users.
As programmers, it's easy to disregard deliverables as a project manager's responsibility.
However, it's we that find gaps in the specifications. If we stay silent, no one will know misunderstandings exist until the project is delivered.
That may be too late.
Even when we believe management will turn a deaf ear, let's speak up. We might end up saving the project.
Enjoyed this article? Then follow me on twitter. I tweet about what I believe it's essential to be a great software developer.
Top comments (0)