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 case or cases covers X requirement. Generally, test rules do not replace test cases, although in some instances they can. For example if an experienced tester believes the test rules give 100 percent coverage of all the requirements. This can never be a unilateral decision. Test rules should be seen as the first line of defense when verifying feature requirements. Test cases can then be used to document more inventive test scenarios, safe in the knowledge that the main features actually work as expected.

I have seen cases where a tester has verified that a system is functioning, but when the product manager later checks to see that the software works as intended, she finds that the system doesn't meet customer expectations. Test rules deal with this situation in three ways. Firstly, test rules assure the developer that the tester has a thorough understanding of what should be delivered. The group review the test rules together and the tester can show in one or two test rules how a requirement is met. This could take reading through numerous test cases to achieve the same result. Secondly, the developer is able to use these succinct rules to test his work before delivery into the test environment. Third, the product manager is confident of what to expect because everyone is verifying the work from the same page.

In conclusion, we all appreciate the difficulty in specifying requirements. As software professionals, we have to ensure that we can give confidence to stakeholders that what was expected was what was delivered. That is one of the main prerequisites of ensuring quality. I would put forward that test rules are an important tool to assist testers in achieving that goal.

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

StickyMinds is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.