What is traceability?
The intent of requirements traceability is to ensure that no functionality is missing from testing and to prevent scope creep. Prevent scope creep you say? Yes, if you find that you have a test case for functionality that doesn’t trace to a requirement, then you’ve obviously encountered scope creep. This means you need the ability to trace backward as well as forward. This article focuses on the forward traceability but keep an eye out for a future article regarding backward traceability.
Traditionally a traceability matrix is delivered as a spreadsheet or document that maps/traces requirements to test cases and identifies whether or not there is full coverage for all requirements. Often this is a single unwieldy and difficult to manage document.
A better way with validateMyApp – In App Traceability
With In-App Traceability, validateMyApp once again introduces the concept of metadata driven and context aware components. The validation station component can be dropped into any lightning record page and because it is context aware, it knows if you have already written backlog, test cases, or logged test defects related to the current object.
In the screenshot below, the validation station component is dropped into an Enterprise record page. Imagine that you have configured a form that allows you to create and manage records related to your enterprise vision and mission per your business requirements and now you have a new requirement to enhance the form. With the Validation Station component in validateMyApp you can modify the requirement, users, story, test case, etc from directly with your application.
The Validation Station component can be dropped anywhere on your form and visibility can be toggled on and off. In the screenshot below, the Validation Station component is dropped into the right side of the Enterprise screen but it can be placed anywhere on a record layout page. The important thing is that you can now view, edit, and create requirements, stories, test cases, and test defect from within your application with full traceability. No need to leave your business application to manage spreadsheets!
Context Aware Backlog
Your team will have a much better understanding of the backlog because they are written and stored in the context of their location.
Product Owners and business analysts love this functionally, because they can author, communicate, and discuss backlog from directly within the application being built without having to switch to another app or spreadsheet.
Filters can be applied to narrow the list to:
- Capabilities (user requirements)
- Features (functional requirements)
The backlog list contains a list of filtered items related to the current object. and selecting an items opens up the ability to edit the item as seen in the screenshot above.
Context Aware Test Cases & Test Defects
Just as with the backlog, any related test cases and test defects can be managed here is well.
Testers love this functionally, because they can read and execute test cases from directly within the app being tested and log defects without having to switch to another app or spreadsheet.