Testing in the dark, or testing without written requirements is a tricky and challenging situation for every QA. When you don’t have written requirements or when the requirements are incomplete you can not know what is expected, which behavior is correct, and basically, there is nothing to compare with your actual behavior of the app. However, this tricky situation is more common than you think, especially in fast-paced environments, but there are still some things that you can do to make your situation easier, and your testing better.
The first thing that you can do is to gather as much information as possible from the team and all the stakeholders. This will help you to understand the product and the features that you are testing. You can find out what is the core functionality of the product, how it will be used, what is its purpose, what kind of problems it can solve, who are the end-users, what are they expecting from the app and any other information that can help you in better understanding the product.
Sometimes, some of the stakeholders or someone from the team can have some kind of prototype or wireframes that could also help you in your testing.
Try to gather as much information as possible, ask all your questions, and clear all your assumptions. This will help you a lot in the testing process, because you will have some knowledge about what is expected, and you will be able to come up with different test cases and scenarios that you can cover in your testing process.
The second thing that you can do is to do exploratory testing. Image that you are the end-user and that you are exploring the app. By looking from a user perspective, navigate through the app and think about what the end-user could do. By doing this, you could be able to identify its key features and the overall flow of the app.
If it is easier for you, you can also pick a piece of paper and draw the flow while you are going through the app. This can help you to visualize the scenarios.
While you are going through the app you can also check some negative scenarios, for example, check some form validations and see if there are some error handlings or not. There might not be any requirements written, but look at the app from a user perspective and give your opinion about the actual behavior of the app, whether is it correct or not.
The most important thing here is to document everything. Document your questions, assumptions, proposals for improving the app, scenarios that you think are working fine, scenarios that you think are not working as expected, etc. This documentation can help you prepare test cases, it can help you in discussion with your team so you can discuss the questions, assumptions, proposals, and scenarios that you think are not working as expected, and it can also serve as informal documentation for the app.
Now, that you have some information about the app, when you have done some exploration, and you have some knowledge about how the scenarios should work, it is time to write some test cases. As usual, write test cases about the positive flows, cover all the critical scenarios, and also cover the negative scenarios. This will provide you with a set of documentation where it is defined what is expected in each test step, so you don’t forget the next time when you test it. And you will also have more streamlined and controlled testing.
Based on your understanding of the product, you can also create a checklist that covers the most critical scenarios. Then you can use these checklists to ensure you’re not missing any important areas during testing.
Communication and sharing knowledge with developers are very valuable in situations like this when the written requirements are limited or nonexistent. As a QA, you can participate in Dev meetings, code reviews, and ask questions, and you can also consider testing with some of the developers to confirm what is expected and how the feature is developed. Also, always share your knowledge, findings, assumptions, and questions, because those information could help the developers to improve the app and the overall quality of the app.
After you have done all of this, make sure that you iteratively refine and improve your test approach by updating your test scenarios, communicating with the team regularly, and adapting to the new changes quickly.
As you can see, if you have a planned approach, good communication, if you are creative and engaging, you will manage to get through this situation, and no matter if the written requirements are not completed or non-existent, you will be able to keep the quality of the product on a highest possible level.
