Writing more effective Requirements

Before we get to work, let’s get one thing straight. Testing is not just about testing, as helpful as that can be. Being more effective can really change your life. Imagine yourself as a child, building things, you feel elated and happy. You come to your workplace, you build a framework, you become empowered. You gain confidence. You create value, both in the form of not testing to make sure everything is working as expected and also in the fact that you’re opening up future opportunities to improve yourself and the others around you.

This is your journey, start thinking about the development process. As the tester, ask yourself – What would the improvement of the testing process mean for you? What will be different about your testing process now and the future?

Today, we are going to talk about requirements and a few points on how to think about them

Consider these statements below:

Just because it’s a requirement doesn’t mean it’s needed

When you are in a project, you have a goal, to achieve these goals what do you need to do? You set objectives. Then we try to meticulously plan for things that might occur in the future, and as humans we will miss some stuff. Let me ask you this – When do we question if we truly need to do a project? One of the roles of a team member in the development team and also the wider business team is to make better decisions to reach the goal. Let’s say you are about to start a project, this project have been given an estimation by the developers to have completed coding and their side of testing for 2 days – Great!. You haven’t been part of the process, the feature set comes to you, only for you to tell them that it was a waste of time because there’s already a feature that the system can do but was hidden to the user. Frustrating and the developers time are wasted.

As a critical member of the team, it is your responsibility to tell management what you feel about the project, ask why this project is needed, look at the current system to be added and ask “Can we already do this?”, “Is there an easier way of implementing this?”. It could be that the management decides that the project will still continue, it could also be that the your ideas have now made implementation easier and you cut off some work for the developer. Whatever the case, you have made an impact and made yourself responsible – What you find in the early stages of the project is critical to how the rest of the project goes.

A requirement is a quality that matters to someone who matters

How do you define a “requirement?” To me, it is a description of the intended purpose and environment for the software under development. A requirement will describe what the software will do and how it will be expected to perform. “Requirements” are a testers best friend.  When you are testing, you must become aware of whose opinion about quality matters. Understand this – not everyone matters equally. Imagine you are working with a set of “requirements” then you feel that a particular requirement has been missed out – usability. What will you do? Ofcourse, you seek answers to your curiosity.  You will find out who is going to be affected, you talk to your wider business team and learn what they want in the product and what they don’t want. Once you have investigated this, you can put some evidence forward and challenge the requirements document.

Ask yourself – Is this person my only stakeholder? Think back to this post for some of the other stakeholders that you may encounter. The short answer, no. You will have different stakeholders and they all want different  things, they don’t know what they want (most of the time), their wants changes. This is unavoidable – accept the change. There is no need to waste your time complaining about why things change – accept and move on.

It’s easier to fool people than to convince them that they have been fooled

So you think you know everything and you can’t be fooled – Think again. You don’t know everything, you find the answers through trial and error.  Mark Twain mentions this quote but some websites say that there isn’t significant evidence to show that it was actually his quote but let’s use this anyways.

You are easy to fool – When you are reading requirements and creating test scripts based on these requirements ask yourself – Why am I thinking this? What other ways am I not looking at this correctly? Have I talked to the wider business team as to why they need this and possible use cases? Notice that whenever someone else finds a problem that you could have found but you didn’t. When you think yourself as a fool and question why you’re doing things you become more alert and find answers to your own questions to enhance your test strategies and scripts. The excellent individual understands the pain of a one sided view of things “That should never have happened”, “I didn’t think about that”.

Prevent this by thinking you are a fool and asking yourself  Why am I thinking this? What other ways am I not looking at this correctly? Have I talked to the wider business team as to why they need this and possible use cases?

New eyes, a different perspective

When you try to make sense of something, the brain does some magic to make it work with what you currently know. After you’ve made sense of this, you’ve formed a map of it in your brain and you don’t have to think so hard when you do it. Like when you are playing any sport, you get the foundation laid out and based on your experiences you have adapted and don’t even have to think long and hard as to where to go, almost like a reflex.

Testing wise, you know your product too well, you make assumptions about it and you test these assumptions les and less – this is a problem. This has multiple implications on your testing

Testing Pothole – You’ve been testing in the same way for months now and you wonder why you haven’t found issues with the tests you are doing. If you are the only tester, for a release – explain to  a team memberwhat you are testing, why you are testing, and the decisions as to why you chose this method. They will offer sound advice and give you a breath of fresh air. I have found this extremely useful, when I speak of my own test strategies I often find flaws myself immediately after talking about it.

Fresh Meat – You have a new team member, hoorah! Explain the product to them, watch how they react to things and note them down. These findings are invaluable as overtime we have developed a certain way of thining about things. Fresh eyes find failure. When you are testing a product, pay attention to how you feel – Is it annoying? Is it too slow? Is it confusing? note this down. Functional requirements are not the only requirements.

Implicit and Explicit Requirements

We’ve all been there, a set of requirements that are incomplete.

Team Member 1: “How come this has stopped working?”

Team Member 2: “It’s not part of the requirements?”

Team Member 1 : “But it should work”

Ah, If I get a penny for how many times a conversation along these lines I’ve heard then I’d probably have enough to buy myself a 4 bar kitkat – yum.

An explicit requirement is a source of information that has been acknowledged by everyone through writing. For example, When I click on X button I should be redirected to page Y.

An implicit requirement is a source of information that is not acknowledged by everyone through writing. For example, the button style should be consistent with our “house style”.

There is no use in complaining “Oh that should have been in the requirements list”, we are human, we miss things and it’s best if we move on rather than waste our energy on the past. Another thing to consider is that “Our clients trust us to use whatever references are required to find important problems fast” – Lesson 34 in Lessons Learned in Software Testing.


Happy Testing!




One Comment

  1. An enjoyable and insightful post. I loved the “A requirement is a quality that matters to someone who matters” definition. You won a new subscriber.

    I hope you allow me to reference your article here: https://dialex.github.io/start-testing/#/concepts/requirements

    Found some typos 😉
    – “Ofcourse” > “Of course”
    – “their wants changes” > “change”
    – “assumptions les” > “less”
    – “to a team” > “to a” (double spacing)
    – “memberwhat” > “member what”

Leave a Reply

Your email address will not be published. Required fields are marked *

I accept that my given data and my IP address is sent to a server in the USA only for the purpose of spam prevention through the Akismet program.More information on Akismet and GDPR.