Defining Testing Structure in RMsis

Owned by Sanjay Sahani
Last updated: Mar 09, 2012
3 min read

In this article, we will look at the issues surrounding the organization of Testing Entities and one possible way to effectively structure them in RMsis.

However the user should note that

  • this methodology is just a suggestion, based on past experience.
  • this article is specific to RMsis 1.5.0. Functional evolution in the product may require corresponding changes in strategies as well.

Introduction and Problem Statement

RMsis users have considerable flexibility in terms of how they structure their requirements, using the following features

  • Hierarchies
  • Dependencies
  • Categories

Some users may also decide to build Requirement hierarchies according to abstraction level of requirement. For example

  • Product Goals
  • User Needs
  • Functional Requirements
  • Product Features

However, the Testing Functionality offers just a flat structure for defining the Test Cases. This may leave many users wondering, "what would be an optimal way to organize the test Assets ?".

The following sections present analysis and suggestions against this question.

Analysis and Solution

Generic Guidelines

The following generic Guidelines should help in structuring the Testing Requirements

  • Build a manageable structure. The hierarchy should neither be too deep or too too wide.
  • The entities should be grouped in such a way that an entity at any level of hierarchy (including it's children) can be moved around, if a reorganization is required.

Recognize the fact that Requirement and Testing Hierarchies are different

A user may decide to structure the requirement hierarchy against the abstraction level of Requirement, like

  • User need
  • Product Requirements
  • Product Features

or the user may decide to structure as per the system components, like

  • System Requirements
    • Sub-System Requirements
      • Module Requirements
        • Product Functions

On the other hand, Testing Hierarchy will be largely determined by the scope and extent of Testing Requirements. For example

  • A unit testing hierarchy will closely follow the developmental hierarchy.
  • User oriented Testing will be structured as per the roles and use cases
  • Integration and Non Functional Testing Hierarchy will be determined by the Testing Steps designed for the same.
  • ...

Hence a simple conclusion is that the Requirements and Testing Hierarchies should be isolated as per the needs of project. A sample structure is show below

Establish dependencies between Testing Requirements as well

Establishing dependencies between requirements can really help in improving the effectiveness and efficiency of testing. For example, it can be used in the following ways:

  • If an initial test fails (say environmental setup) , then the rest of the test cases need not be executed.
  • In determining the coverage of requirements.
  • In determining the coverage of Testing Goals / Objectives.
  • ...

The following example shows one such dependency of a Test Requirement on the 

  • Previous step
  • Testing Goals
  • Product Feature

Logically Group the Test Cases and map to Test Requirements

This mechanism can help in

  • Tracing the source of problem in the hierarchy.
  • Quick reorganization of Test Suite

The following example shows grouping of test cases and their mapping to test requirements

Categorize the Test Cases for easy filtering

Test cases and Test Requirements should be categorized and this practice can help in quickly building alternative test suites with a specific focus.

Use Requirement hierarchy for Unit Test Cases

For organizing the Unit Test Cases, a separate hierarchy need not be created and a group of Test Cases can be directly mapped to the Requirement. This is shown in the following example:

References and Resources

Demonstration
Feedback

For any suggestions or questions, please send a mail to: solutions@optimizory.com