Kevin Carroll

How to Expedite Your Feature Requests for testRigor

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

1. 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.
2. Go to that email and verify the testRigor account.
3. 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

1. Before creating the test case, submit a Freshdesk ticket responding to the following questions:
   1. Why: What problem are we solving?
   2. What: What should the user or system be able to do?
   3. How: How would we achieve what you need? Add any implementation details, wireframes, design docs, etc
   4. Success criteria: What does success look like?

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.

1. Your Freshdesk ticket should also include the following:
   1. The URL to your SDD suite.
   2. 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.]
2. 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

1. 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. 
2. 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).
3. 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. 
4. 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.)
5. 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.
6. 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.

Making Changes Over Time

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

1. Create a new SDD test case reflecting the updated behavior
2. Submit a new Freshdesk ticket
3. 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.