5 symptoms of a faulty work process that wastes your time and money

Ideally, software testers aim to accomplish their work in the least amount of time possible, at the least expense necessary, and all while guaranteeing the smoothest, most bug-free software experience possible.

Like a well-oiled machine, experienced teams should progress from one stage to the next of the testing process without a hitch.

But how feasible is that?

Unless you’ve fine-tuned every step of the way, not much. Which is why it is critically important to periodically take a step back and scan your work process to note if there are any signs or symptoms that something may be awry.

In this article, I take a look at five symptoms of a faulty work process that require urgent fixing before they inevitably start taking their toll on your organisation’s resources.

1 – Missing requirements

One of the things that vexes me most are missing requirements.

The worst thing about them? You never know they’re there until the project hits a snag. Missing requirements are definitely symptoms of a faulty work process.

To avoid the embarrassment of missing requirements, you need to approach writing in a systematic way. Frequent deliveries minimise the impact of missed requirements.

The first thing you need to do when writing requirements is to put down all the obvious requirements first. It might sound obvious indeed, but this step is very important.

Not only will you enjoy the ‘little win’ of seeing your requirements list growing, but beginning with the obvious sets you in the right frame of mind to elaborate about the rest of the requirements.

Use templates such as user stories, use cases, prototypes and others. A good template helps you to write better requirements, but the most part of the missing requirements are likely to be found when the solution is tested and deployed, so deploy often. Furthermore, have someone else review them. Writing requirements is not a one-(wo)man show.

Better solutions: Be aware that there are more types of requirements than the obvious: normal requirements, hidden requirements, sensational requirements. Use different types of gathering techniques.

2 – Ambiguous requirements

Ambiguous requirements, also symptoms of a faulty work process, are a time sink for developers and testers since they have to spend extra time trying to understand them before implementing in practice.

Trends in requirements management encourage writers to formulate brief requirements that can be easily testable and verifiable by team members. Brief requirements can also lead to more interpretations and misunderstandings. When working Agile you say that the user story is a promise for communication. The requirement is not intended to be complete so the developers have to discuss it with the product owner.

A good way to avoid ambiguity when writing requirements is to use a good template, such as the user story template. It is also always wise to involve other people (preferably of a different background than the main writer) to cross-check and give honest feedback about their clarity. Another suggestion I have is to adopt a template on which to base your requirements writing process.

Good communication is key in this case since ambiguous requirements are often a symptom of incomplete information. It is highly recommended to have the product owner on-site during the project to discuss and explain the requirements.

3 – Irrelevant requirements

As I mentioned already, the introduction of Agile drove requirements writers to review their documentation procedure.

In order to keep to the principles espoused by Agile methodology, they had to ditch heavily detailed tomes in favour of light-weight documentation that concisely delivers the essential information.

Yet, some requirements writers still believe that a lengthy documentation reflects their level of ability.

For this reason, they feel compelled to add in irrelevant requirements whenever they see that a document came in a short of their expectations.

Resist the urge! Embrace the simplicity of Agile instead, and ensure you don’t provide symptoms of a faulty work process.

There is a variety of ways how requirements can be presented and in certain cases the shorter the better. At the end of the day, you are not writing requirements to win a Man Booker Prize but to help developers and testers produce working software. Again, use a template that helps you focus on the important parts of a requirement.

Many systems have lots of capabilities that are in common with other systems. Why not create a checklist of base requirements (e.g. save, search, list, delete, help files, printability, etc.) and reuse it in every project?

4 – Requirements that change unexpectedly

It is natural that requirements change, but they should not change in an unexpected way.

Agile working methods are very time-aware. They don’t call it a sprint for nothing! Although I don’t believe that requirements should be set in stone – there’s always room for improvement as the project progresses – the team needs to have a consistent objective that doesn’t change all of a sudden.

For this reason I advocate shorter sprints, frequent releases and actively listening to customer feedback. Based upon the feedback, draw you conclusions and decide about requirements for the next sprint.

5 – Goals that change constantly

Although a sudden, unexpected change can be tolerable up to a certain point, what certainly isn’t are a set of requirements that change and shift shape all the time.

Like the foundations of a building, the requirements need to provide a solid basis on which the framework of the product can be developed. You wouldn’t build a house on quicksand, would you?

Although the details can (and should) change in response to the feedback obtained from continuous testing, it is impossible to make a product without a coherent blueprint.

If you notice that requirements are changing at an alarming rate, then maybe you should consider bringing in the client again to discuss their aims and the kind of product they are envisioning.
It is also important that you are in contact with the person who is calling the shots from your client’s end. Sometimes, the person who explains the requirements is simply relaying the message from someone else; you need to get in touch with your intended client or product owner and obtain feedback directly.

Establishing open and active channels of communication is of utmost importance to ensure that the requirements you are working upon are a definite representation of your client’s needs.

In conclusion

The consequences of a faulty work process can be catastrophic unless the root causes are identified and corrected.

Take a moment to reflect on your typical workflow during a project and see if you can spot any of the symptoms that are outlined in this article.

You might discover one or more that apply to your situation, in which case, take steps to remedy immediately and put a halt to? the loss of time and money which these faulty processes ultimately result in.

Having a good strategy and plan for your work process is an essential precaution to avoid faulty processes from taking a hold on your team’s workflow, since they streamline your work and allow team members to easily pinpoint themselves any divergence from optimal work processes and make the necessary corrections more autonomously.