Testing without Requirements or Functional Requirements Document

Is it possible to test a system where no requirements documentation exists? It’s pretty rare but the situation can arise where we are expected to review without being given a functional specification document.

Without a set of the usual testing documents, we will be unable to follow the standard testing practices. This makes it a challenge to prepare test cases, track testing progress when a big team is involved, and train team members but these issues cannot prevent testing from happening.

This article will show you some techniques that can be used by testers in the absence of software requirements specification. The methods can be leveraged to extract as much information as possible by the reviewer so they can perform a quality review of the system.

Become familiar with scenarios where requirements documentation are not referenceable

Before I dive into the details on how to perform testing without requirements, let’s first understand some of the real-time scenarios which can put the tester in this situation.

1. The development happened directly by interacting with the customer, and the requirements were either discussed over a call or exchanged via email. There wasn’t ever a requirement written since the developers already had the information they needed.
2. Sometimes, a platform upgrade is required, with slight or no changes on the functionality. Requirements documentation are mostly ignored in such cases because a system already exists for reference.
3. Outdated documentation can be one of the most common occurrences, where the team starts with adequately documenting the requirements, and due to the frequent changes and multiple channels of communication, upkeep becomes tedious and an effort to keep the document updated and current. Even though the requirement document exists, it becomes increasingly irrelevant, and similar to not having one. Referring to incorrect documentation for testing purposes can drive a lot of non-issues.

Now, that we are clear on what can lead to this situation, here’s the approach you as a tester can take to optimize the overall testing efforts and bring in the best output from your testing cycle.

What you must do prior to starting your test

As part of the requirement/ information gathering phase, the focus must be on identifying what to test? Here’s what can be done to make this phase the most productive:

1. Know your team – It’s a good practice to be aware of not only the developers on the project but business analysts, product owners, project managers, graphic designers, test module leads and all your peers involved in the testing. Knowing the people on the project helps you in reaching out to the right person at the time of need, and it is more required when we are missing documentation.
2. Frequent Interaction – Apart from scheduled meetings, it is good to have regular interaction with those involved. One way to draw out information could be to make a note of any questions that you can think of then discuss them over email or chat. Keep in mind that testers need to be very clear on what they are supposed to test. Clarifying assumptions beforehand will also help eliminate any non-issues identified during the later stages of execution. Interaction must not only be limited to the requirements understanding phase, but proactiveness from testers is required at every step.
3. Explore Other Artefacts – Functional or Software Requirements Specifications is just one of the several documents prepared during the software development phase. The availability of design documents are equally helpful, so check out if wireframes or mockups are available. Other useful resources can be business requirements, use cases, process flows or technical documents.

Once the team and testers have an idea of the scope, making a list of all critical components helps in planning resources and total effort. Another useful self-help designed by the QA team can be the creation of process flow diagrams. It doesn’t have to be highly presentable or beautifully designed but showing the correct flows will help in overall end-to-end and system testing.

How to Test without Documentation

In the earlier section, we discussed on what to test, the next part of the whole process is to focus on how to test?

1. Functionality Checklist – A checklist of identified components will work as the testing scope document. Utilize the same for work allocation and tracking within the team.
2. Use Experience-based testers – The most valuable step in this overall process of testing without requirements is to have experienced testers in the team. Their experience not only counts for the total experience in this field but what matters most is the domain experience. The knowledge will help in identifying the gaps in the built system, also assist in mentoring other team members. If for some reason, an experienced tester isn’t available to assist during test execution, have them help with the requirements understanding and gathering phase.
3. Perform Exploratory testing – Exploratory testing is the most suitable for this type of requirements. The knowledge and experience aids to identify the conditions in which the system may not work as expected and more stress is given on those areas of testing. When there are no formal test steps to be followed, the system requires one to come and test in and out. A lot of testing flows are randomly generated. A tester plans to test path A, but upon encountering an issue, they decide to take path B as well, so many scenarios can be generated spontaneously.

Finally

Even though having no documents creates a challenge, it can also occasionally work as an advantage. Testers find this kind of testing to be fun and exciting when they get a chance to perform more ad-hoc testing than being restricted by a defined test plan. The challenge can help them think beyond and produce better, more considered output.