Exploratory Testing in Requirement Analysis

When you think about exploratory testing, do you imagine a tester clicking through the app or a tester analyzing requirements? I bet the answer is a tester clicking through the app!

Both answers are correct, but in this blog post, you’ll read more about exploratory testing in requirement analysis. Don’t worry if you’re not a tester, anyone included in the requirement analysis will benefit from this blog.

Requirements can be explored in a requirement discussion or later when requirements are already defined and written. Exploring requirements is actually a ‘thinking’ activity. In this blog, you’ll learn how to explore requirements and why it’s important.

But first – what is exploratory testing?

This question deserves (at least) its own blog post! However, take a look at this simple example to understand what exploratory testing is. Let’s say that you are looking into a requirement like this: ‘As a user, I want to be able to log in with my username and password.’

If you enter your credentials in a username and password field and click on the Login button, you are not exploring. But, if you click on the Login button without entering credentials, you are exploring. Furthermore, you can check what happens when you click multiple times on the Login button after entering valid credentials or observe what happens when you enter an invalid email or password.

In short, everything you test that is not specified in the requirements or test cases can be considered exploratory testing. If you want to know more about exploratory testing, I recommend an excellent book that describes exploratory testing in detail – Explore it! by Elisabeth Hendrickson. This book offers great examples and tips for exploratory testing. And how does exploratory testing fit into the requirement analysis? Let’s find out!

Exploring requirements during requirement discussion

I would say that this is the perfect start for testing. Well yeah, you don’t have a product you can test, but you can save a lot of time (and nerves) if your testing starts here.

During the requirement discussion, the main focus is to define what a system should do. First, so-called happy paths are discussed. After defining and understanding what those happy paths are, other scenarios should be discussed – and that is the moment where exploratory testing should start.

What can go wrong?

Each happy path is likely to have scenarios that can go wrong. Let’s stick to the mentioned login example – what will happen if the user enters invalid credentials? If there are no warning messages saying that the username or password is incorrect, the user can be confused. Raise a question about scenarios that could go wrong following the defined happy paths.

What should always work?

This is a happy-path question, but it’ll help you understand where to put a great effort into breaking that thing. Ask stakeholders to define the most important use case(s). For example, imagine that your team is building a webshop and you’re discussing a payment flow in a webshop – one of the most important use cases is to always show correct prices and a correct total price.

You can discuss with stakeholders anything you think will affect the correct prices (reducing the number of the same products in the chart, removing products, discounts, promotion codes)

What should never happen?

Discuss with stakeholders what should never happen. For example, products from the wishlist should never disappear. Try to cover scenarios in which products may disappear from the wishlist and how to handle those scenarios.

One of those scenarios is that the product is out of stock. The end-user wants to see all products he ever saved on the wishlist, although the product is out of stock. The product can be grayed out, or the ‘out of stock’ warning may appear under the product, but the product should remain on the wishlist, and the user should be informed that the product is out of stock.

Are there any variables affecting other functionalities?

This question is very important because it helps prevent defects in multiple functionalities. Let’s continue with the webshop example – one of the requirements is ‘As a seller, I want to be able to remove my products’. Now think about what functionalities depend on products:

• chart – should the product be removed from the chart? Do I need to notify a buyer about the removed product? Should the product be disabled and greyed out or completely removed?


• product list – when the seller removes his product, can the buyer see his product in the product list?


• search – can the buyer find the removed product by search option?


• filter – can the buyer find the removed product by filter option?


• payment – what should happen if the seller removes the product at the moment when the buyer is paying for the product?


• bought items – if the buyer bought the product before the product was removed, can the buyer still see the product in his bought items list after the product is removed?

Once you start doing exploratory testing in the requirement analysis following these questions, you’ll reduce many discussions that occur during the development – doesn’t it sound perfect?

Exploratory testing in defined requirements

I’m sure that you already know that any defined and written requirement can be changed. So don’t take for granted defined requirements, analyze them and raise your concerns.

When you understand what the requirements ask for, you can analyze them with the questions mentioned above:

• What can go wrong?


• What should always work?


• What should never happen?


• Are there any variables affecting other functionalities?

And questions not mentioned above:

• Does the end-user need the functionality as described?


• Is it going to be too complicated for the end-user?


• Are there any scenarios that are not described within the requirements?

As in the previous examples, these questions will lead you to other questions. And sometimes, defined requirements won’t give you answers.

However, stakeholders will. You can forward your questions or concerns to a business analyst, project manager, project owner, or your clients – this depends on the organization within the project you work on. Just make sure to contact a person responsible for defining business logic and/or requirements.

If you have any suggestions on how to handle your questions, don’t hesitate to raise them with your questions – moreover, it’ll help stakeholders to make a decision, and your previous experience will probably generate some great ideas.

Benefits of Exploratory testing in requirement analysis

Exploratory testing in the requirement analysis doesn’t make sense if there are no benefits to it, right? Great benefits can be brought to both product quality and teamwork.

Let’s start with some benefits of exploratory testing during requirement discussion, where questions are raised before development starts:

• The time for discussing requirements is saved – you’re already brainstorming and discussing requirements with stakeholders so it’s faster and easier to discuss any new questions at this moment than discussing them later and waiting for answers


• Preventing bugs – while exploring requirements, you’ll detect questions and scenarios that probably wouldn’t be detected without exploring requirements, which means that potential bugs are prevented


• Reducing the number of change requests – anything discussed in the requirement discussion will not be discussed later, causing change requests. But not just that, it’ll save unnecessary work that could be made in the development


• Better planning – clear requirements that cover most of the scenarios lead to more accurate estimation and prioritization, which leads to better planning


• Better communication – anything discussed in the early phase will prevent misunderstandings between the client and the team or between team members


• The time is saved – everything stated 1 – 5 is saving the time: time is not spent to discuss requirements again or to discuss change requests or misunderstandings, unnecessary work is avoided, the work is better planned


• The money is saved – time is money. Now read everything 1 – 6 again

If requirements are already defined, your team still can benefit from exploring them:

• Better Quality – discussing missed scenarios or something that can be done better than it is, and implementing it, provides better product quality


• Better UX – end-users probably won’t praise your dedication and great work, but be sure that you will prevent user complaints caused by poor user experience. Besides that, satisfied users are likely to bring to your product more users and to continue to use your product


• More satisfied clients – clients will recognize team dedication to deliver a high-quality product, and they will appreciate it

Conclusion

Although exploratory testing is about simultaneously learning, designing, and executing tests, exploratory testing can be done in requirement analysis. You need to think outside the box and let your results bring great benefits!