Requirement Testing: Creating a Well-Defined Test Package
If you’re in the business of product or requirement testing, you have certainly come across cases where the results didn’t match your expectations. Many times, you have a test that ran properly but failed correctly. But more often than desired, you have tests done improperly, incompletely, or just late. When you dig further, you find out that the test team members were confused, made wrong assumptions, or didn’t have “all the info” they needed to complete the test.
But you may ask yourself, “how is that possible?” You knew what was needed, and you gave the test procedure or test case documentation. Where does the problem lie? Is it as simple as not following the test correctly? Did they have to augment the test package because it was incomplete? How can you ensure your tests execute correctly?
It All Starts with a “Well-Defined Test Package”
The main goal here is not only to have the test parts and test procedures that are needed for the test but to ensure that you’ve answered most or all of the questions your tester will ask. These can be things like “what are the test conditions, do I have any key parameters/KPIs, where does this assembly/system fit into the larger context of the product.” And if you have not predicted all of their questions, you may consider providing them links back to the source data so that the test team can easily find the answers they are looking for.
In the video below, you can see test packages created for different purposes; and what can or should be in them. These range from simple requirement validations to more refined test packages managed by multiple teams to achieve an overall goal.
Which Test Package Type is Best For You?
Defining Your Test
As you create your test package, you may want to take advantage of any relationships you already have between your artifacts, like links between requirements and systems or simulation models. Having a tool that lets you define these relationships and easily include them in your test package will minimize the cases where you’ve “missed something.”
Of course, if you want to put your test procedure and parts into a test package object and hand them to your test team, this should be easy to do as well. The Teamcenter Test and Verification Management toolset handles both simple test scenarios and more complex and in-depth cases. The system supports the more lightweight options even as simple as “images of your napkin-sketch,” all the way examples where you have fully-related system designs and corresponding simulations that must be run with specific parameter values across multiple runs. It will also auto-build the test package for you if you have already built the traceability between your artifacts.
Teamcenter Test Management
With the increasing complexity of your products and the shorter lifecycle from design to delivery, it sure helps to create your test package right the first time. As we’ve seen, the Teamcenter Test and Verification Management solution allows you to author a well-defined test package that can remove all questions from your downstream testers. It allows you to automatically grab related elements and quickly add more meaningful artifacts and directions as needed. Remember, your goal is to provide all the artifacts and directions to your test organization so that they can get about the business of “testing,” not “researching.” Teamcenter Test and Verification Management can get you there quicker and more completely.
To learn more about model-based systems engineering (MBSE) or, more specifically, our requirement testing capabilities, visit the MBSE webpage or read other MBSE blog posts.
