Writing Test Rules to Verify Stakeholder Requirements

[article]
Summary:
Some organizations employ business analysts who are very good at specifying requirements at the beginning of a software project. The advantage of this step is the reduction in ambiguity for the developer and tester of what should be delivered.

Some organizations employ business analysts who are very good at specifying requirements at the beginning of a software project. After all, it’s cheaper to review requirements than code. Other organizations take the next step of breaking those requirements down into finer details. The advantage of this step is the reduction in ambiguity for the developer and tester of what should be delivered.

Once the requirements document has been reviewed and signed off on, it is ready to be handed off to the developer and tester. The tester’s job is to take that document and write test cases from it.

Test cases have to verify that the software does what is expected of it as specified in the requirements document. They also have to try to find possible defects in the software. We usually do this by writing negative or edge cases . For example, we validate that input fields work when given correct information but we also check the input fields using invalid information.

Another use for test cases is testing for the sin of omission , i.e., we have to verify not just what is there but, ideally, also what is not there. For example, did the analyst remember to specify that a user can only log into the system if he has the latest version of Java installed?

There are several organizations that do not solely use test cases to ensure that functionality in a software package is verified. Some organizations use a mechanism called a test rule . Test rules are very similar to business rules —very specific statements of intent to explain how a feature is suppose to work and interact with other components.

Test rules get the tester to think like a developer but also to think atomically about each sentence written in a requirements document. They are written as follows:

IF…………………Event/Input

WHEN …………..Condition

THEN ……………Output

If: Event/Input —Trigger or event that must occur for that requirement to be verified (end-user action or system activity), e.g., open account.

When: Condition —What must be fulfilled within the system during or before the event occurs, e.g., user must be over a certain age.

Then: Output —The system’s expected response behavior to that situation (input + condition), e.g., an account is created.

Additional parameters can be added.

Test rules help the tester to understand the requirements in more detail, and they help in identifying omissions. For example, here are two rules that could follow each other:

IF a user attempts to log into the website using his correct user name and password

WHEN he has Java Version 7 installed and presses log in,

THEN he will be moved to his home screen in the application.

IF a user attempts to log into the website using his correct user name and password

WHEN he does not have Java Version 7 installed and presses log in,

THEN he will get a security pop-up to install Java 7.

In the original instance, the tester may not have known about the Java 7 requirement, but when he was forced to ask the BA about the preconditions for a user to be able to log into the system, the BA may have realized she did not specify all of the requirements. The developer would not have needed to know Java 7 was a precondition to create a perfectly acceptable login authentication system.

Test rules make it easier for a BA and developer to review a tester’s understanding of what they are testing. Test rules are there to assist with the verification of requirements in a more definitive manner than just saying a test

User Comments

2 comments
Dan ODacre's picture
Dan ODacre

Good one Brendan. This style also makes it easier to automate the test case.

March 21, 2013 - 4:11pm
Brendan Quinn's picture
Brendan Quinn

Thanks Dan, If any one uses them for automation I would like to know how you get on. Regards.

March 22, 2013 - 10:21am

About the author

Brendan Quinn's picture Brendan Quinn

A software test professional based in Dublin, Ireland, Brendan Quinn is currently the senior mobile test engineer for a betting exchange. For fifteen years, Brendan has worked in software localization, finance, telecoms, insurance, and gambling industries. He has worked as a test team lead in several companies. Brendan is a strong advocate for process in the SDLC. You can contact him at brendan.quinn@outlook.com.

StickyMinds is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, TechWell.com is the place to go for what is happening in software development and delivery.  Join the conversation now!

Upcoming Events

Oct 12
Oct 15
Nov 09
Nov 09