How to Test Without Requirements

Ruslan Desyatnikov, Founder and CEO, QA Mentor
711
1217
252
Ruslan Desyatnikov, Founder and CEO, QA Mentor

Ruslan Desyatnikov, Founder and CEO, QA Mentor

Just as it seemed QA was finally getting development teams on board with documenting clearly-defined requirements, the entire world shifted. The explosion of mobile computing further pressed the need for even faster development and that combined with the increased popularity of Agile methodologies turned the tide and documentation has started to wane. In some cases, that’s a welcome shift. In other cases, not so much. 

“QA analysts are often part of the requirements gathering process, if not the ones actually writing the requirements.”   

One area with a documentation deficit of particular interest for QA is requirements. In the recent past, wireframes and prototypes were increasingly common. Nowadays such things are luxuries. As most QA pros will attest, vague requirements can create huge problems down the line, leading to business rule confusion and/or incorrect or even insecure functionality. 

Aside from those obvious issues, the lack of requirements makes it difficult for testing teams to build their test cases early and prepare for the upcoming (and necessarily rapid) testing cycles. Notice that I said difficult, not impossible. Developers are coding against something, right? 

So, how do you test without requirements? The answer to that questionis that there are always requirements. It’s just a matter of finding them. Without clearly defined and documented requirements, testers have to approach things a little differently and do a little sleuthing. 

Strategy 1 – Interview the Stakeholders 

By interviewing all project stakeholders, business analysts, and anyone else involved in the initiation of the software application, testers can glean requirements by asking all of the right questions to the right people. As long as those individuals are accessible and willing to talk, a good QA analyst can identify what functionality should be present, the business rules, and the expected results of user behaviors. 

Strategy 2 – Talk to the Developers 

The developers of the application are a fantastic source of information. They built or are building the application with some sort of requirements and guidance. Get together with them and pick their brains since they will have many – if not all - of the details. This is even extra useful if you’ve already spoken with the stakeholders so that you can determine if there are discrepancies between what they expect and what the developers have envisioned. 

Strategy 3 – Investigate on Your Own 

Become a QA investigator in order to find what you need. This may mean doing quite a bit of sleuthing in order to determine which individuals on the team have the information you need. It may also mean tracking down and reading both finished and unfinished documentation from multiple sources and piecing it all together into something more coherent and useful.  

Strategy 4 – Build the Requirements Yourself 

Take the initiative and build the requirements yourself. QA analysts are often part of the requirements gathering process, if not the ones actually writing the requirements. Sometimes this is planned and sometimes it just means the analyst saw a gap in the process and took the initiative to start a requirements document on their own. Even if you don’t plan on distributing the requirements to anyone else, gathering and writing the document will help your testing process immensely. Not only will it help you to understand every aspect of the system, but it will give you what you need to write your test cases. 

Strategy 5 – Combine Strategies 

This strategy involves a combination of the above with some additional steps. Analysts should interview stakeholders, business analysts, and developers to get as much information as possible. Following that, they build their test cases based on that information and then review those test cases with the stakeholders. In this way, stakeholders can see the step-by-step process and give immediate feedback on whether or not that’s what they envisioned. By reviewing the test cases, stakeholders can easily see gaps in the process and give additional information to fill those in.  

Strategy 6 – Exploratory Testing 

The final strategy is simply to wait until the application is built and delivered to QA and then perform exploratory testing. When using this strategy, the QA analyst will have to rely on their experience with similar applications to help determine if they feel the application is behaving correctly. This means that the analyst will do some testing, jot down questionable areas or functionality, and then discuss with stakeholders and developers to determine if the behavior is expected. 

The takeaway from all of this should be one main point: The lack of a requirements document should not be used as an excuse by testers to claim they cannot build test cases or otherwise do their jobs.  Such an excuse can only be used by the least experienced testers or those who have no initiative. There are always requirements, but in some cases the QA team has to take extra steps to find the needed information, document it, and/or build their test cases from it. By utilizing these six strategies, any QA professional can test any system in Production or QA Environments with or without requirement documents. 

Read Also

Cloud Adoption-The Key to Business Success

Cloud Adoption-The Key to Business Success

Pankaj Sabnis, Principal Architect, Cloud Computing, Infogain
Software Quality in 2016: The State of the Art

Software Quality in 2016: The State of the Art

Capers Jones, VP & CTO, Namcook Analytics LLC
Onshore, Offshore, and Models for Testing Teams in Light of Recent Data Breaches

Onshore, Offshore, and Models for Testing Teams in Light of Recent Data Breaches

Jennifer Bonine, VP, Global Delivery and Solutions, tap|QA LLC
Shortcut Time-to-Market with Automated Code Testing

Shortcut Time-to-Market with Automated Code Testing

John Chang, Head of Solution Design, CAST