Bugs Due To Requirements

You, the tester is special.

You are the first user of the application. When it is developed, you are the first person to get the feel of it. Work on it and give feedback about it.

You invest your time.

Invest time in planning, strategizing the testing. You care quality and own it. Though everyone is responsible for quality in the product development.

You apply your skills.

Think out of box and test the product. You uncover bugs.

Those bugs are important for the product, the business and the company.

They save company’s business when fixed and delivered to customer/user.

In spite of everyone’s great effort, some bug are escaped to production. Users report them as bugs or may give negative feedback for the product.

These escapes can be due to multiple reasons.

In my earlier newsletter, I had mentioned major reasons for the defect escapes at a high level.

Today, I will focus more on bugs due to issues related to requirements.

Change in the requirement is one important aspect.

But I have tried to explain on other aspects of requirements.

These are based on my 20 years of experience in testing. I hope you can learn from this experience and deliver awesome products and make an impact in the world !

Let’s dive in !

Unspecified requirements

All requirements are not captured.

During requirements capturing or product discovery phase, usually all requirements are not captured. Because, most of the times users don’t know what they want !

What ?!

That is true. !

Users, usually do not know what they want. Or sometimes, they are not able to express them.

Example:

A button in an application should have contrasting colored text and background.

Do you think that the user asks to have button with blue background and white text on it?

No !!

It is the skill of Product Managers or Business Analyst to capture that.

They should understand what is the pain point of user.

Try to find the best solution for that.

Now, if unspecified requirements are captured, product might have bugs.

They can be functional or accessibility or performance or any other type.

Not understanding the requirements correctly

Requirements are crucial.

Everyone involved in the development should understand requirements.

Whatever requirements are documented, it is very important to understand them. There should be no assumptions. If any assumptions, they should be declared.

If any requirement (or PRD or Story) is misunderstood, they can lead to disasters.

Architects may make wrong design, developers my develop in correctly.

And testers may assume something and test according to that.

These all may lead to defect escapes- that is defects in the production.

Example:

Consider health care product.

The requirement mentions that user should be able to upload and images.

This requirement may lead to uploading all images, including personal images like selfies, etc.

And there is limit set on the size of the image too.

This is because of mis-interpreting the requirements.

Actually the user should upload images of test reports and scans only.

This interpretation lead to unnecessary load on the server and it’s performance would be reduced.

Also read : How do I find bugs?

Not capturing the user requirements completely

Requirements should be complete.

As far as possible.

If by oversight or some other reason, there are chances of missing out on requirements documentation.

Example: In an application, user needed to edit the documents. This should include offline as well.

So, while documenting/capturing this requirement, someone missed to include ‘offline’ edition feature.

Product developed and tested without offline edition feature.

This product is launched.

Within few days of launch, there were user feedbacks. They were asking for adding the feature, where documents can be edited without internet connection.

So, you have seen the impact of not capturing requirements completely.

Not developing the software as per the user requirements

This scenario is different.

The team has the full requirements. Fully documented. But development team might have missed the requirements.

Example:

Consider a banking application.

There, one of the requirements is, user should be authorized to transfer more than 1000 INR. But the development team missed this one.

The application was developed without this requirement.

This lead to huge bug escaped to production. Users were able to transfer any amount. That lead to illegal activities.

The central bank imposed huge fine to the bank, who had this product.

This clearly demonstrates how a missed requirement creates huge impact.

Not involving testers/developers in product discovery phase

This one is really game changer.

Involvement of engineering team, that is developers and testers in product discovery phase is very important.

They will be involved from stage 1.

From this, they get first hand information regarding the requirements. They may assess/gauge the technical challenges very early in the cycle.

But this involvement is not practiced. Generally.

Only product team, UI/UX team and Business analysis team participate in discovery phase.

This according to me is a huge set back. And may lead to defect escapes.

Example:

Consider a last mile delivery app.

The requirement was to pickup the ordered item from the warehouse and deliver to the customer.

The engineering team was not involved in the discovery.

Many months were spent in further marketing survey to understand more on this las mile delivery app (to be built).

After multiple months, the engineering team had a blocker. That is most of the warehouse operators do not have APIs to integrate.

This pointed the team to develop APIs for these warehouses themselves.

This lead to delayed product launch.

But still, they launched the product with only limited number of warehouses.

Customers started complaining about not getting ordered product delivered to them quickly.

I hope you are able to picture this scenario.

Also read : Reasons for testing failures

Not communicating the requirements correctly to engineering team

Communication is key.

Specially when it comes to communicating the requirements.

Poor communication between business analysts, project managers, and the engineering teams can lead to misunderstandings.

It also leads to misinterpretations of the requirements, ultimately causing software bugs.

Any change in the requirement also needs to be communicated. At the earliest.

Example:

Consider automotive software product.

T he requirement calls for the vehicle to alert the driver when the fuel level is low.

However, due to a communication gap, the engineering team interprets it as an audio alert only, not realizing that a visual warning is also needed.

This miscommunication can lead to incomplete safety features and potential accidents.

So, let’s embrace the lessons learned in this article.

Implement best practices, and stay vigilant in the pursuit of software excellence.

With well-documented requirements and a collective dedication to quality, we can build products that not only functions flawlessly but also transforms the way we live and work

Conclusion

Requirement as he basis for the product, its functioning and its quality. By recognizing the importance of capturing complete, accurate, and well-communicated requirements, software development teams can pave the way for smoother, more efficient, and successful projects. This isn’t just about avoiding bugs; it’s about creating software product that truly meets the needs and expectations of its users.

Subscribe to newsletter to know more about testing like this.

Follow me !

Here is my Linkedin profile.