The testing a Software application is an art, however it is more interesting when tester has to perform his job with the minimum or no requirement documentation. It might be possible that the tester joins the project late. In such situations it’s not only difficult to work but also impossible to estimate and planning the project testing activity. As a result the return of investment may be affected under such conditions. In this article we are going to discuss a challenging job i.e. How to Test Software without any requirements listed? No SRS and no FRD and how effectively a tester can perform his work.
How To Test Software Without Any Requirements?
Let’s discuss the difficulties a tester will face if there are no formal requirement documents provided to him.
1. To Design Test Cases or writing down test case scenarios becomes challenging since you don’t have any document to refer.
2. When we have the requirements, we know how a system would look upon completion but here, we can only put Unit Level Approach.
3. Also, requirements can be easily Misunderstood or Changed Frequently which can make system unstable and difficult to test.
To handle such projects, one should have good understanding, effective oral and written communication and proper planning. There are few important things to know before starting the testing phase, such as:
1. Type of testing we are going to perform on the system (Functional, Regression, Load etc.)
2. If this a child version of an old product then we should have all the old specifications with us to refer.
3. Who are the people from client side available for clearing doubts because such approach (testing without requirements) requires frequent meetings and doubt clarification sessions to make it run smoothly.
4. What are the documents Developers are referring for coding purposes, so that tester can refer the same to get an idea how the product will work.
5. What could be the known risks related to the software product.
Once we have analysed all the above points, it will be easier for us to organize our testing process and planning accordingly. Now let’s see some of the key points to follow while testing such product, below are the important tips to follow to make testing less challenging:
1. Read documents properly which are referred by developers to develop the product and share your test cases with them. In this way, you will know how developers are developing the software and you can design your test cases based on it. Also, by sharing your test cases with them, you are making sure that you understood the functionality and will test it properly.
2. In case of any ambiguity, make it clear as soon as possible. Involve all the teams i.e. testers, developers, business analysts and clients. Make sure that after the meeting all the teams are on the same understanding level and then proceed with the process.
3. Make proper documentation of what you have tested and the work flow. This will help in better understanding of the approach. Use flowcharts and easy to understand diagrams.
4. Prepare a list of In-Scope and Out-of-Scope items and share with all team members and get approval from your manager. You can update the list any time later after discussion with team members.
5. If possible, make test cases out to user stories. Sometimes, end user (at client side) is there to test the product at early stages too. If you have few user stories with you, you can always make few test cases out of them to know their expectations and usefulness of the software.
6. Perform more Exploratory Testing, since you don’t have any formal requirements listed, you can perform random testing frequently and whatever you feel is not right, you can discuss with clients and make them correct by sending it to developers team.
7. Think from all user’s perspective and make software more useful. Give your suggestions and solutions. There are various users who are going to use the software in different ways, if you could think from their perspective then software will become more compatible and versatile.
8. Divide the whole system into small modules and understand each one in detail. This way you will do deep testing of each part of the software making test coverage maximum. It is easier to test a small module than to test the whole system at once. Start testing early for better understanding.
9. Automate test cases which are now fixed to save time and efforts. In the beginning of the project when requirements keep changing, this step might look unnecessary but after a while when few requirements or functionalities are fixed, you can automate few test cases. For example, a login screen. You know what are the key fields will be present, Name, Password, Captcha (Optional) etc. so you can write basic test cases related to this screen and automate them.
Conclusion:
When we have get a project without requirements, proper planning in advance can lead us to success. There will be challenges which we just discussed but there are ways to handle them too. Communicate well with client and developers and know what their expectations are and take their feedback frequently. When you know what to test and how to test, you can make your own documents stating the requirements and can refer / modify the same throughout the process. If you have more suggestions based on your experience, feel free to share in the comment section below.
⇓ Subscribe Us ⇓
If you are not regular reader of this website then highly recommends you to Sign up for our free email newsletter!! Sign up just providing your email address below:
Happy Testing!!!