How to make everybody happy with your product? By testing software requirements

5 min

read

Quality Assurance specialists should participate in the software development process from the very beginning of the project. It might seem a bit weird for people with no IT background since usually they associate testing with checking a finished product. The question arises – what is QA responsible for when there are no ready functionalities to be checked yet? One of the most important tasks for the QA team at the beginning of the project is requirements testing. In this article, I’ll show you an example of software requirements and explain why testing software requirements is so important.

I can tell you from my personal experience when talking about Quality Assurance, very often people not familiar with this role have the idea that a QA specialist is just there as the last element in any development to check the quality of the final product. You’ve got a car – you’ve got a person responsible for checking the correct production of certain elements for the vehicle. You’ve got an app – you’ve got a person who checks if the buttons work correctly. Technically yes, but also a big NO.  

You should remember that QA engineers take the responsibility for the correct course of the software development process, not only the testing but the entire development phase. And that starts with software requirements specification.

Now, you’re probably wondering how the heck can you test software requirements. Let’s see.

💡 Read more: ABC of QA. Why do you need a Quality Assurance engineer?

What is a requirement?

We can’t start analyzing any requirement in software engineering without a proper definition. According to Mastering Business Analysis Standard Practices by Kelley Bruns and Billie Johnson:

“It’s a condition or capability that is necessary and is a usable representation. A requirement represents what is needed for a product, service, or result”.

The second part of this definition is very important because it mentions NEEDS. In software development business needs are represented by requirements (multiple requirements can meet one business need!). I’ve recently written a piece about business needs and user stories in software development, so give it a read if you’re interested.

Types of software requirements

Requirements can be divided into several types:

  • business requirements – critical for the organization as a whole, include software requirement document with needs and expectations for a future product,
  • stakeholder requirements – describe what users can do with the product (use cases, scenarios, user stories),
  • solution requirements – sums up business and user requirements to describe problems that the product must effectively solve.

There is also a division into:

  • functional requirements – basic product behaviour and responses to inputs (what it does and mustn’t do),
  • non-functional requirements – performance of a system as a whole, rather than specific behaviours (that includes security, scalability, usability, etc.).

All the aforementioned requirement types should be taken into account during the software project duration and written down in the software requirements document so as not to omit anything.

There are several methods for describing requirements and creating software requirement documents. The most popular ones are definitely User Stories and Use Cases. Regardless of what form of requirements document you choose, you can start testing them from the moment the requirements specifications are created.

💡 Read more: How to write good User Stories in Jira: The Software House’s way

Why should you do this at such an early stage? A good argument for testing at such an early stage, that I wholeheartedly agree with, is presented here:

“Many bugs emerge in software because of incompleteness, inaccuracy and ambiguities in functional requirements”.

It shouldn’t come out as a surprise. After all, before you start to develop any software you need to make sure that everybody in the development team is on the same page and clearly understands the project’s logic.

How to write a good description?

What should you pay attention to in order to deliver a high-quality requirement? The table below presents a software requirement specification template prepared by gitconnected. By following these recommendations, you can create good software requirements that are independent of each other and at the same time meet business needs.

software requirements example
The best practices on writing software requirements by gitconnected

A very similar approach to the one presented in the table above can be found in the INVEST method. From this abbreviation, you get the following values:

  • Independent – there are no elements making the completion of our task dependent on other teams,
  • Negotiable – until the work begins, you can work on the content and scope of the task,
  • Valuable – provides new value, primarily for the user,
  • Estimable – everything must be valued, otherwise, it won’t be tasked,
  • Small – possible to plan and task,
  • Testable – the task is only finished when the team is able to successfully test it.

A good rule that I personally try to follow when describing requirements (in particular at the stage of creating acceptance criteria) is to consider dividing tasks into smaller ones when the number of acceptance criteria begins to exceed four points. Of course, this is not a rule of thumb, but it works in most cases.

You should also remember that the task description must be adapted to your readers. Some people like very detailed descriptions, while others prefer high-level descriptions so that they have freedom of action. Nevertheless, regardless of the task description, its quality should be thoroughly checked.

💡 Read more: Quality Assurance standards – a simple way to improve software quality

An error becomes an error when it is born as truth

Everyone who deals with maintaining quality and software testing knows that an error detected early causes lower fixing costs. Therefore, you should maintain high quality from the very beginning of the project while preparing the software requirement documentation. Luckily, there are several methods to check whether the written requirements and software specifications meet your quality criteria.

The first step you can take is to validate the requirements. It’s a very important element of the requirements gathering process. It involves evaluating the business analysis information to ensure that it accurately reflects the stakeholder’s intent. In other words, you present what you heard and ask if you understood your stakeholders correctly. Remember that even the best stakeholders may omit some significant elements with an impact on the final implementation, so stay vigilant.

💡 Read more: Project Manager’s guide to stakeholder management in Agile

To avoid this situation, follow the entire process-to-be with the requirements you’ve created. To conduct this type of requirement analysis, it is worth writing test cases at the stage of creating your requirement description.

I personally use the Gherkin language for this purpose which, using a descriptive language, guides you through all the steps that your user or the system itself will perform in the future.

It is a very simple form that often allows me to find some inaccuracies or missing information that needed to be completed. Gherkin comes from the so-called “Behavior-Driven Development” and includes some fixed elements:

  • Feature – description of the functionality that you will implement or test,
  • Scenario – description of what the given case will check, what path you want to go,
  • Given – description of the initial condition that must be met in order to perform a test case,
  • When – description of the action that triggers the reaction of your system,
  • Then – description of our system’s reaction to the previously triggered action,
  • And – description of elements that must be met in the initial conditions or the reaction that will follow the action.

How to create your own software requirements specifications?

As I mentioned earlier, QA specialists should be included from the very beginning of the project and also be involved in creating the project documentation to ensure the highest quality of the delivered product. Spotting inaccuracies or gaps at the early stage of creating requirements will significantly reduce the cost of fixing the system in its later stages of development.

Nevertheless, not only the QA team but also all stakeholders involved in the process should be responsible for the final quality of the delivered product. Everyone who participates in creating and analyzing requirements should ask themselves some questions, presented by Karolina Zmitrowicz and Radosław Smilgin:

  • Are all the requirements correct?
  • Are all the requirements feasible?
  • Are all the requirements measurable?
  • Are all the requirements testable?
  • Are all the requirements single?
  • Are all the requirements understandable?
  • Do all the requirements have a priority?
  • Are all the requirements unambiguous?

If you answer YES to all those questions, then you can conduct a validation with stakeholders whether their need is understood well, and then proceed to implementation.

By taking proper care of creating good requirements in software engineering, you will have greater certainty that the delivered solution is honestly well done and will meet the expectations of your end-users and stakeholders. But what is equally important, it will reduce the risk of complications or other negative effects of a wrongly written requirement of software specification.

💡 Read more: Software testing trends for 2019-2020: What the future holds for Quality Assurance

What do you want to achieve?





You can upload a file (optional)

Upload file

File should be .pdf, .doc, .docx, .rtf, .jpg, .jpeg, .png format, max size 5 MB

Uploaded
0 % of

or contact us directly at [email protected]

This site is protected by reCAPTCHA and the Google
Privacy Policy and Terms of Service apply.

Thanks

Thank you!

Your message has been sent. We’ll get back to you in 24 hours.

Back to page
24h

We’ll get back to you in 24 hours

to get to know each other and address your needs as quick as possible.

Strategy

We'll work together on possible scenarios

for the software development strategy in sync with your goals.

Strategy

We’ll turn the strategy into an actionable plan

and provide you with experienced development teams to execute it.

Our work was featured in:

Tech Crunch
Forbes
Business Insider

Aplikujesz do

The Software House

CopiedTekst skopiowany!

Nie zapomnij dodać klauzuli:

Kopiuj do schowka

Jakie będą kolejne kroki?

Phone

Rozmowa telefoniczna

Krótka rozmowa o twoim doświadczeniu,
umiejętnościach i oczekiwaniach.

Test task

Zadanie testowe

Praktyczne zadanie sprawdzające dokładnie
poziom twoich umiejętności.

Meeting

Spotkanie w biurze

Rozmowa w biurze The Software House,
pozwalająca nam się lepiej poznać.

Response 200

Response 200

Ostateczna odpowiedź i propozycja
finansowa (w ciągu kilku dni od spotkania).

spinner

Webinar for CTOs: How to update your company’s legacy software

Sign up