When you’re testing a new feature on an app or website, it’s considered a best practice to have test cases. Ideally, the tester will be given acceptance criteria for the feature being developed. When QA knows exactly what a feature should or shouldn’t do, writing test cases can be easy enough. (If you’re feeling lost, see our article explaining test cases.) But how do you write test cases without requirements?

After all, in the real world of a fast-paced Agile process, chances are you won’t always have them. It’s pretty common to encounter a Jira ticket with a simple description, and no real list of requirements. Sure, you could ask the person responsible to add them. But it’s not always clear who that should be. (The developer? Project manager? Product manager? Higher up?)

In many scenarios, the task can get passed back and forth so long, it delays the testing process by days – if you even end up getting requirements at all.

How to Write Test Cases Without Requirements

It can feel daunting to even imagine writing test cases without requirements. But if you follow the tips below, you’ll have a solid plan in place for the next time you feel intimidated by a sparse Jira ticket ready for QA.

Write them based on ideal user experience.

Most QA testers are well-versed in advocating for good user experience. Even if you don’t know exactly what a product owner intended for a given feature, you can assess what actions would make the most sense to the end user.

Ask questions of product managers/developers.

Don’t expect to get a full list of details. But if you’re stumped or want to double check, they can be a great resource for clarification.

It’s best to ask specific questions, rather than leave them too open-ended. This will get you an answer more quickly, and reduce the chances of having to ask follow-ups. For example, you might be wondering, “How should this button work?” Instead, you could word it as, “When a user taps this button, which section should they be taken to?”

Research similar features on other apps/websites.

Just because a feature is new to the app or website you’re testing doesn’t mean it’s revolutionary in the tech space.

Brainstorm any possible action you can do with the feature.

Look at each selectable button, and every combination of options that you can. Even if it’s something a user wouldn’t likely do, it’s good to include in a test case. For example, “If user enters numbers in the name field and attempts to save, error should come up.”

Ask developers what logic they used in the code.

Writing code involves a pretty intense amount of logic. Every feature has to be explicitly written out, line by line. If you’re wondering if it’s expected that form fields don’t clear after saving, you can ask the developers if the code is set to do so. If their code is written in a way that should result in a certain behavior, and it isn’t happening on the front end, you’ll inherently know it’s a bug.

Provide a summary of what you’ll be testing.

When you’re writing test cases without requirements, you might end up testing based on assumptions that are different from the product manager. While it wouldn’t be practical to stop and ask them how every little thing should work (after all, they would provide requirements if they wanted to take the time to do that!), it makes sense to keep them in the loop.

Have a standard list of expectations for any feature.

Even if the list is short, there are requirements you can expect for any feature. For example, if it’s an app – it should work on both iOS and Android. Or if it’s a website, it should work on all major desktop and mobile browsers. (Learn more about cross browser testing.)

You could also include common accessibility standards. For example, “A person who is blind or deaf should be able to use the feature.” (There’s more to accessibility testing than this, but it’s a great start.)

Or if the software has paid tiers, maybe it’s a given that only premium users should be able to access new features.

No requirements? No problem!

Being asked to write test cases without requirements can be nerve-wracking. But if you follow the guidelines above, you can navigate the situation with ease.