Refer to Requirements from the Model

In general tests should be specified based on requirements on how an application should operate. Requirement coverage is the easiest means to communicate to other stakeholders like managers what you are working on, what is the level of complexity of the functionality to be tested, and why are some models taking more time than others to complete.

If requirements are stored in ALM tools or Excel files they can be imported to Creator using Requirement Providers and then drag & dropped from the Requirements view in the Conformiq Modeling perspective to activities. Often users however are confronted with a lack of (properly) documented requirements – in these cases we encourage users to use Excel or create Creator ad-hoc requirements in models to capture and trace what they test.

A known challenge in modeling with requirement references (see section Measuring Model Complexity) the granularity of requirements. In particular when coming from different source they scope and clarity of requirements may vastly differ. Some authors write six requirements in one. Some requirements are not testable. Some are not clearly defined. Finally, testers generally do not have the right to modify requirements in ALM systems.

Requirements can also be understood and used “way points” or “[pure] testing requirements” in model coverage. They can be useful to track specific data coverage or to even troubleshoot coverage issues. For example, adding an ad-hoc requirement with a skip action pre-condition “Username is Stephan and password is 123” after a fill form action, makes it easy to pinpoint via the Test Targets view in the Conformiq Test Design perspective all test(s) where this user and password is used at this point of the control flow.