How to Expedite Your Feature Requests for testRigor

Kevin Carroll

How-to Articles

Would you like your feature requests and bug fixes to be released faster? We are introducing a way for you to help us do just that by creating SDD test cases for the scenarios you want us to implement.

What Is an SDD Test Case?

Specification-Driven Development (SDD) is a collaborative way to build software where clear specifications drive everything—including development, testing, and delivery.

An SDD test case is a plain-English step-by-step description of how a feature should behave. It is written before development begins and serves as the shared understanding between you and our team of how you expect the functionality to work on our platform.

An SDD test case:

Is written in plain English using testRigor steps or rules
Is based entirely on the feature specification
Clearly defines what “done” looks like
Fails until the feature or fix is complete
Becomes the acceptance criteria for delivery

The feature is only done when the test case passes. Simple as that.

Why Do We Ask You to Create SDD Test Cases?

SDD test cases help us move faster with fewer surprises.

By asking you to describe the desired behavior up front, we’re able to:

Eliminate ambiguity early
Align on expectations from day one
Reduce back-and-forth during development
Deliver features and fixes more quickly

Most importantly, your SDD test cases are fed into codeCake, our proprietary AI development tool that builds features from the ground up. This allows us to:

Translate specifications into working code faster
Validate behavior earlier
Improve overall delivery speed and accuracy

Clear specifications = faster, better outcomes.

Where Do You Create SDD Test Cases?

All SDD test cases for your requested features and fixes are created directly inside our testing platform. This keeps everything centralized, traceable, and easy to reference during development and testing.

The test case itself becomes the single source of truth shared between your team, our QA team, and our engineering team.

How to Create a High-Quality SDD Test Case

1. Set Your Cases Up for Success

Create a test user account who will be the user in your SDD test cases.
1. It is important that you sign up with this user at https://testrigor.com/sign-up/ so that they can always log into testRigor with username and password. This way we can avoid any extra authentication issues.
Go to that email and verify the testRigor account.
Log in to your regular testRigor instance and create a test suite using the following indications:
1. Enter “SDD TEST CASES FOR testRigor” into “Test Suite Name.”
2. Enter “https://app.testrigor.com/” into “URL to run tests on.”
3. Enter the test email account into “Username.”
4. Enter the test account password into “Password.”
5. Select “0” from “Number of test cases to generate using AI.”
6. Click “Create Test Suite.”

This will be the suite you use for all of your testRigor SDD test cases.

2. Start With the Desired Outcome

Before creating the test case, submit a Freshdesk ticket responding to the following questions:

Why: What problem are we solving?
What: What should the user or system be able to do?
Success criteria: What does success look like?
How: How would we achieve what you need? Add any implementation details, wireframes, design docs, etc

If the behavior can’t be explained clearly, the specification likely needs refinement. For requests that cannot be shown on our UI, discuss with the support team on the ticket if an SDD case is viable.

Important: Our AI uses your ticket AND the SDD test case for context to build code, so the quality of your ticket is just as important as the test case.

Example of a well-designed Freshdesk ticket:

Scenario: testRigor wanted to add a feature auto-suggest variables from test data while writing specifications into the editor.

Ticket Subject: Code complete for stored values

Why?

Currently, when a user wants to use a variable in a test case, they need to manually type the exact variable name. This increases the chance of errors due to mistyping and slows down test case creation. By providing auto-suggestions and filtering variable names as the user types, would be very convenient if, when referencing a variable, a filtered list of available variables is displayed as the user types. This would help reduce errors caused by mistyping variable names

What?

When user types enter stored value " we should list all stored values created in the test case AND from stored values.

When a user starts typing a variable name in a test case, the system should automatically suggest and filter the available variables that match the typed text. For example, if variables such as “projectNumber” and “projectName” exist, typing “project” should display both options. Users can then select the correct variable from the list or press “Tab” when it’s highlighted.

Customer Description:

If a user created a variable and want to use the variable in the test case, when typing the variable name it would be filtered accordingly. For example:

Variable Name: projectNumber

Variable Name: projectName

enter stored value "project" into "project_number"

When typing “project”, listed variables to display should be “projectNumber” and “projectName”.

User can then either click on the correct variable or tab when variable is highlighted.

How?

As the user types into the input field, the system will dynamically filter and display matching variables.

Users can click on the correct variable or navigate using keyboard shortcuts (e.g., arrow keys, Tab) to insert the selected variable into the test case.

The client wants the feature where typing a few letters shows the relevant options automatically.

Your Freshdesk ticket should also include the following:

The URL to your SDD suite.
A request testRigor support to port all of testRigor’s rules into your suite. [Your SDD test case will be both the basis for the development and consequent testing of the functionality, so it must be congruent with our internal test case structure. Using our rules will help speed up test creation, reduce duplication of rules, improve consistency with our cases.]
Feedback and Refinement

testRigor will review your test case and provide feedback before accepting it.

If we see opportunities to improve clarity or structure:

We’ll provide guidance directly on the Freshdesk ticket, but you may feel free to reach out on your Slack or Teams channel if more clarity is needed.
Suggestions will focus on making the test case as stable as possible and easier to validate and maintain.
Think of this as a collaborative refinement – not re-work.

3. Including Preconditions

Any setup required for the test must be included inside the steps of the test case itself.

How to do this:

testRigor will assume that all necessary test data and reusable rules are already updated in the test suite.
testRigor does not use dependencies, so it assumes preconditions as steps in the test case itself.
If there are preconditions that for some reason cannot be shown in the steps, mention them in the Freshdesk ticket.

Example:

If the preconditions in a test case management tool are the following:

User is logged in
Required permissions are enabled
Test data already exists
Test suite already exists,

testRigor will assume that the username and password with required permissions were added during suite setup and that all required test data is updated in the Test Data section. The only steps in the precondition would be the following:

login
create new desktop web suite with url stored value "homePrefix"

If the case requires a different user and password, save those as respectively as username and password before logging in.

For example:

save stored value "admin" as "username"
save stored value "adminPWD" as "password"
login

Setting up preconditions properly ensures anyone can understand and run the test without extra context.

Important note: We are currently only focusing on environments under our explicit control. This is why all preconditions must be provided within the test case, rules, or test data. If anything requires access to another platform, we will not be able to proceed with the expedited path to feature releases.

4. Writing the Test Case

You will need to think of testRigor as taking your place as the user. That means the steps in your test case should reflect everything a user on testRigor does.
testRigor builds its cases so that any environment can test a different environment. That means all of our test cases begin by logging in (as the user would) and creating a new suite (because we can’t assume that every testRigor environment will already have the required suite).
From there, write the steps that would allow any user to successfully complete the flow to the point where it is currently possible on testRigor.
When the steps take the user up to the point where your requested feature or fix would be different, add the steps necessary to achieve the rest of the flow with the desired functionality as if it already existed. (An SDD test case MUST fail until the feature is successfully delivered.)
Wherever you want to specify an expected result, use a validation to prove the desired flow is progressing exactly as envisioned. See our documentation page for more details on validations.
Every test case should end with a validation.

Remember:

Represent a real user or system action
Be as clear and concise as possible in your flow
Focus on behavior, not implementation
Avoid combining multiple actions into one step unless it is a reusable rule previously provided.

Example testRigor Test Cases

We have put together a collection of real test cases from our regression suite to help you understand how to create your test cases.

Real Test Cases From testRigor’s Regression Suite

Examples of SDD Test Cases (They should fail until the feature is created correctly)

The test case Verify that “Re-test combination” and “Debug” buttons are inside a drop-down named “Other re-test options” is an example SDD case that proposes to testRigor what it would be like to put test case buttons inside a dropdown.
The test case Verify that “Download PDF” button is displayed on the test case to download a PDF of steps for the test case proposes placing a button to download the PDF of the last execution in the test case area.

Making Changes Over Time

If requirements change or the feature’s desired scope evolves:

Create a new SDD test case reflecting the updated behavior
Submit a new Freshdesk ticket
Reference the original test case and feature/bug ticket

This allows us to track evolution cleanly while preserving original intent.

Please avoid editing existing test cases to represent new behavior. You can copy the test case steps into a new test case, and make the necessary changes there.

Tools, Integrations, and Special Notes

If your feature involves third-party tools, integrations, or environment-specific behavior, please document these details in the feature request or bug ticket, not inside the test case itself.

In Summary

By investing a little time up front to clearly define behavior, you help ensure faster delivery, higher quality, and fewer surprises.

Great specifications lead to great software, and SDD is how we get there.