Testing without Requirement Documentations

As the requirements in subsequent development cycles are shared over email or on calls, hence, they tend to get scattered. Insufficient requirements also add to this problem. Lack of documentation asks for a smarter way to collate and translate the requirements into testing artifacts such that they don’t get missed out.

Hence this blog is an attempt to share some practices which helped me to understand software requirements.. These methods or practice can be very helpful and effective and we can follow them when we find that requirement is not sufficient enough to proceed with testing.

Start with whatever requirements you have:
Explore and understand the available requirements first, Work with whatever little documentation you have in your plate. You can use client emails and his previous feedback (if any), and whatever documents are available. Understand the requirements and note down the queries and clarify them with stakeholder. Ask for application flow diagrams and wireframes for better understanding of the requirements.

Translate available Requirements to Test Cases:
• After understanding the available requirements create all the possible test cases.
• Emails, Notes, Recorded issues and marketing materials can be used to create test cases.
• Document on a high level first and keep adding the details as you proceed.
• Add more details while testing, connect high-level requirement and detailed test scenarios.

Attend team meeting and client meetings:
Actively participate in the team meeting and discuss your queries in the meeting. Raise your concerns and feedback about the app to the entire team. Attend client interactions, observe his approach and his requirements what he actually wants in the app. Create notes of the call and share it with team time to time. Time to time interaction with team and client will help tester’s to get better idea and clarification on the queries. It’s a good platform to raise queries and concerns.

Refer other similar apps in market:
In this wide market many options are available for users. User is not dependent on one app. We can use these aps for our advantage; we can refer other similar apps available in the market. Testers can write high level test cases using the application as a reference. Referred application might have some bugs for e.g. In an online shopping app after registration it takes user screen 1 then never assume that it is correct behavior. Never assumes things observe the scenarios carefully and for doubts always take help team for clarification.

Explore the software:
• Perform the exploratory testing on the project. Exploratory testing is about exploring, finding out about the software, what it does, what it doesn’t do, what works and what doesn’t work.
• The tester is constantly making decisions about what to test next and where to spend the (limited) time. This is an approach that is most useful when there are no or poor specifications and when time is severely limited.
• Think from the user’s perspective and try to observe things as user.
• Try to explore most critical and high use features.
• Focus on the features which will be released soon.
• Learn the software behavior.
• Learn users, objects, workflows, product properties.
• Explore competitor’s product.

Hints and hacks:

• Always inform team and stakeholders about the risks.
• You cannot test everything –test by priority.
• Discuss doubtful issues.
• Always follow up discussion with written notes.
• Keep calm and Test, Test again then test some more.