How to do QA for a service missing requirements

Introduction

Imagine, you are a QA engineer doing your work on a project with crystal clear requirements and use cases defined by PM or BA. The development team has well-written code and documented technical details. The QA team has test cases covering almost all functionality, and all regression tests are automated.

Sounds perfect, yes? Now, let’s get back to the reality XD. If you have experience working in IT, you understand that achieving everything described above is a utopian scenario. I have never encountered this scenario in my experience.

In real-world projects, the following situation is common. Requirements and use cases described just in tasks and documented decentralised somewhere in service’s documentation. Typically, documentation is not updated alongside task creation. Automated tests cover only the main flows. Sometimes, nobody fixes or updates them because the team lacks an AQA or doesn’t have time to do so.

So, how to do QA?

First of all do not panic. It sounds cheesy, but this is the only way to accomplish this. You need to stay professional and demonstrate your full set of skills.

Let’s list all the things you need to do in this kind of situation:

1. Understand the scope and timeline of the change;
2. Split the scope into logical parts and create related tickets;
3. Analyse the very first part and ask questions;
4. Analyse the next part and repeat point 3 and 4.

Scope and timeline

The very first thing you need to understand is the scope. To better understand the scope, the first question that must be answered is “Why?”. By understanding the “Why” behind a feature, you can grasp the business goal, see the flow more clearly, and identify potential weak spots.

The next step is to collect the flows (features) that need to be implemented. It’s not enough to simply list the names of the flows; you need to understand the details within each one. For example, if the business wants to implement issue reporting, it sounds straightforward, but you need to understand how customers should report issues, where user can find the form, what the form should look like, and where it should be sent etc.

Timeline is also an important factor. You need to clearly understand it because a new feature might be too extensive for the set timeline. At this point, you can start negotiating the timeline or reducing the scope. Since you’ve already finished collecting flows, you’ll have the necessary arguments to demonstrate that the deadline is tight.

Split scope and create tickets

After understanding the scope and timeline, you need to break down the entire feature into logical parts. Returning to our issue reporting example, we can split the scope into the following parts:

1. Create a POST incident endpoint.
2. Expose the POST incident endpoint.
3. Create an “Issue Reporting” form.
4. Connect the “Issue Reporting” form to the API.

Once you have a clear picture of the feature’s components, you can start creating tickets.

Analyse and questions

Now you’re ready to define the first ticket. In our example, the first part of the feature is creating a POST incident endpoint. You need to document all the questions you have and send them to the business. This will help them understand the specific points they need to clarify if they’ve overlooked something.

Don’t hesitate to ask any questions, even if they seem trivial. A question that may seem unimportant to you could be crucial for others. Let’s consider some questions we might identify in our example:

1. What is the route?
2. What fields need to be exposed?
3. What are the valid (expected) values for the fields?
4. What service do we need to send the incident information to?
5. Is there any specific logic that needs to be applied based on the provided values?

This strategy can be applied when everything is being defined from scratch. However, if you want to connect your service to an existing one, you can use reverse engineering.

To connect to an existing service, start by reviewing all the information stored there. Based on your research, you might identify the following questions:

1. What fields do we need to populate?
2. What are the business rules governing the fields we need to populate?
3. What values are expected for the fields we need to populate?

Once you’ve documented all your questions, send them to the business. Additionally, you can set up daily calls with stakeholders to discuss these questions and address any other topics of interest.

Next steps

The next steps are similar: analyse and ask questions about other parts of the feature while continuing to follow up on questions from previous parts.

It’s very important to document everything. This can save you time in the future and provide visibility on how the feature works. You can also share the document with other teams or third-party stakeholders.

Conclusion

In real-world QA work, things are rarely as perfect as they seem. Instead of clear requirements and complete documentation, you often deal with incomplete information and only partial tests.

To handle this, stay calm and use your skills wisely. Start by understanding what needs to be done and the timeline for the changes. Break down the work into smaller tasks and create tickets for each one. Make sure to ask any questions you have to get all the details you need. This helps you understand the work better and can also be useful for negotiating deadlines.

Keep detailed notes on everything. This will help you and others understand how things are supposed to work and make it easier to share information with the team. Regularly communicate with stakeholders to address any issues or questions.

In short, while perfect conditions are rare, a careful and organized approach will help you succeed in real-world QA work. Stay focused, communicate clearly, and keep good records to ensure the quality of the project.