> ## Content Index
> Fetch the complete content index at: https://blog.jestor.com/llms.txt
> Use this file to discover other available public pages before exploring further.

# How to test a process before releasing it
- URL: https://blog.jestor.com/test-a-process-before-releasing-it/
- Published: 2026-09-16T18:55:28.000Z
- Updated: 2026-09-16T18:55:28.000Z
- Author: Bruno Bannach

To **test a process before release**, the cases that matter are the ones you did not design for. In **Jestor**, app versioning lets a new version be built and tested while the team continues on the stable one, so testing does not require a separate environment.

## Why internal processes are released untested

Internal tools are built by the people who need them, under time pressure, and the builder tests by doing what they intended. That confirms the design works as designed, which was never in doubt.

The failures come from the cases nobody considered, and those appear in production, in front of colleagues.

What structured testing catches:

- Required fields that block a legitimate case
- Automations firing when they should not
- Permissions hiding something a role needs
- Conditions that are wrong at a boundary
- Cases where the process simply has no path

## What to test

| Case                   | Why it matters                         |
| ---------------------- | -------------------------------------- |
| The normal path        | Confirms the basics                    |
| Boundary values        | Exactly at an approval limit           |
| Missing data           | What a real user will submit           |
| Rejection and reversal | Almost never designed                  |
| Each role's view       | Permissions are hard to predict        |
| The abandoned case     | What happens to something left halfway |

## Step by step to test

1. **Build the new version** without publishing it to the team.
2. **Run the normal path** first, to confirm the basics.
3. **Test boundary values**, particularly at approval thresholds.
4. **Submit incomplete data**, as a real user will.
5. **Test rejection and reversal**, which are usually unbuilt.
6. **Log in as each role** and check what is visible.
7. **Publish deliberately**, keeping the previous version available.

## Why the abandoned case deserves attention

Every process has records that start and never finish. If nothing handles them, they accumulate silently, distorting every metric built on that process. Deciding what happens to an abandoned record is a five minute design decision that prevents a permanent data quality problem.

## Why choose Jestor

In **Jestor**, app versioning allows a new version to be built while the team works on the pinned stable one, with rollback available. Conditional rules, required fields and permissions can all be tested before release, and the execution log shows exactly which automations ran during a test.

## Frequently Asked Questions

### Do I need a separate environment to test?

Not necessarily. Versioning allows a new version to be built while the team uses the stable one. See [jestor.com](https://www.jestor.com/?ref=blog.jestor.com).

### Which case is most often untested?

Rejection and reversal, which are rarely designed at all.

### What should happen to abandoned records?

Decide explicitly, or they accumulate and distort every metric.

## Video Tutorial: Step by Step

With **Jestor**, you can automate workflows, connect teams, and build internal systems your way, all without code and powered by **AI**. Discover Jestor at [jestor.com](https://www.jestor.com/?ref=blog.jestor.com) and see how to take your company's operations to a new level of efficiency and control.