How do we create our first Fume test from a Loom-style screen recording?

Most teams are already comfortable recording quick Loom-style walkthroughs to explain how a product works. Fume lets you turn those same screen recordings into reliable, repeatable tests—without rewriting everything as manual test cases or code. Here’s how to create your first Fume test from a Loom-style screen recording, step by step.

What you’ll need before you start

Before you create your first Fume test from a Loom-style screen recording, make sure you have:

A Loom-style recording (or any similar screen recording) that:
- Clearly shows the product workflow you want to test
- Has spoken narration (recommended) or clear on-screen cues
- Includes the full flow from start to finish (login, interaction, expected result)
Access to Fume (workspace and the right permissions)
The environment or app under test available (staging or production, depending on your process)

If you haven’t recorded your walkthrough yet, you can do it now and then upload it into Fume.

Step 1: Capture a Loom-style screen recording suitable for Fume

While Fume is flexible, a good source recording makes test creation smoother and the resulting test more reliable.

1. Choose the workflow you want to test

Pick a flow that is:

Clear and well-bounded (e.g., “Create a new project,” “Submit a support ticket,” “Complete checkout”)
Representative of a real use case
Stable enough that it won’t change every few days

This helps Fume extract a clean, meaningful test from your recording.

2. Record your screen (Loom or similar)

Use Loom or any Loom-style recording tool with:

Screen capture (entire screen or app window)
Optional camera bubble (fine but not required)
Microphone audio enabled

While recording:

Narrate what you’re doing:
- Describe each step in plain language
- Mention what you expect to happen
- Highlight any important data (e.g., “I type ‘test-user@example.com’ in the email field”)
Move intentionally:
- Click, type, and scroll at a normal pace
- Pause briefly after key actions so Fume can map actions and UI changes more clearly
Show the full flow:
- Start from a known initial state (e.g., logged out, empty cart, clean dashboard)
- Move through the entire journey to the expected final result
- End on the “success” state you want Fume to validate (e.g., a confirmation message, updated list, new record)

3. Keep the recording focused

Try to avoid:

Switching contexts (e.g., jumping between unrelated apps mid-recording)
Long unrelated commentary
Notifications or pop-ups covering critical UI elements

You can always record separate Loom-style videos for different test flows.

Step 2: Import or upload your Loom-style recording into Fume

Once your Loom-style screen recording is ready, the next step is to bring it into Fume so the platform can analyze it and generate a test.

1. Get the recording file or share link

Depending on your tool:

Loom:
- Open the recording
- Click “Download” to get a video file (e.g., MP4), or
- Copy the share URL if Fume supports direct link imports
Other tools:
- Export or download the screen recording in a standard format (MP4 is ideal)

2. Create a new test in Fume

Inside Fume:

Navigate to your project or workspace.
Choose Create new test or a similar option.
Select the “From recording” (or equivalent) option, if Fume distinguishes between test creation methods.

3. Upload or connect your recording

You’ll typically see options like:

Upload video file: Drag-and-drop your Loom-style recording (e.g., checkout-flow.mp4).
Paste a link: If supported, paste the Loom share URL and allow Fume to fetch and process it.

Once uploaded or linked:

Fume will process the video
It will begin analyzing cursor movements, clicks, keystrokes (where visible), and major UI changes
If audio transcription is supported, Fume will also convert your spoken narration into text to help infer intent and expected outcomes

Processing might take a short time depending on video length.

Step 3: Let Fume auto-generate the initial test from the recording

After Fume finishes processing your Loom-style recording, you’ll see an initial test draft based on what it detected.

1. Review the detected steps

Fume typically breaks your recording into step-by-step actions, such as:

“Open the login page”
“Enter email”
“Enter password”
“Click ‘Log in’ button”
“Verify dashboard is visible”
“Click ‘New project’”
“Fill in project name”
“Click ‘Create’”
“Confirm project appears in list”

Check:

Are all important actions included?
Are the steps in the correct order?
Do the steps match what actually happened in your recording?

2. Confirm input data and selectors

Fume may infer:

Input values (e.g., email, passwords, search queries)
UI elements and selectors (buttons, links, form fields)
Validations (what success looks like)

For each step:

Confirm that the inputs match what you want the test to use
Make sure the UI element labels or selectors are correct and stable
Mark sensitive fields as secure if needed (e.g., passwords or API keys)

3. Review expected outcomes

A successful Fume test from a Loom-style recording needs clear assertions:

What proves the step succeeded?
What should be visible on the screen?
What data should have changed?

Examples:

“The ‘Welcome back, Jane’ text appears”
“The project named ‘Fume Test Demo’ appears in the list”
“The order confirmation number is displayed”

Adjust or add assertions so the test doesn’t just “play back” steps but also verifies the right result.

Step 4: Refine and structure your Fume test

With the initial draft in place, refine the test so it’s reliable, maintainable, and clearly tied to your real workflow.

1. Clean up step names and descriptions

Rename steps to be:

Clear and action-oriented (e.g., “Log in as existing user” instead of “Input email” and “Input password” separately, if you want them grouped)
Understandable to teammates who weren’t involved in the recording
Consistent with naming used in your QA or product documentation

2. Group or modularize steps (if supported)

If Fume allows reusable components or step groups:

Turn common flows into reusable blocks (e.g., “Login,” “Create base project,” “Add to cart”)
Extract those from your Loom-style derived test so they can be reused in future tests

This makes it much easier to build more tests later without re-recording or rebuilding from scratch.

3. Parameterize data where helpful

Instead of hardcoding everything from your recording:

Use variables for data like:
- Email addresses
- Project names
- Search terms
- Order amounts
Define default values based on what you used in the Loom-style recording
Make them configurable so you can reuse the same test for multiple data sets

This transforms your “single example” recording into a flexible, repeatable test.

Step 5: Map the test to your environment and app configuration

Your Loom-style recording was captured in a specific environment. Your Fume test should be aligned with how and where you want it to run.

1. Set the base URL or environment

In Fume:

Choose which environment this test should use:
- Staging
- Production
- Preview or QA instances

Update the base URL if necessary so the test targets the correct app instance, not just the one you used in your original recording.

2. Configure authentication details

If your workflow starts with login or uses authenticated sessions:

Store credentials or tokens securely according to your team’s practices
Use environment variables or secrets where supported
Confirm Fume can start the flow from a clean state (e.g., not relying on cookies from your recording machine)

3. Add any preconditions or setup steps

If your flow requires certain states to be true (e.g., “user exists,” “product in inventory,” “feature flag on”), either:

Add explicit setup steps to the test, or
Reference separate setup scripts or tests that run before this test

This prevents flakiness when your test runs automatically.

Step 6: Run your Fume test for the first time

Now you’re ready to run the test Fume generated from your Loom-style screen recording.

1. Trigger a manual run

From the test page in Fume:

Click Run test or equivalent
Select:
- Environment (if multiple exist)
- Browser or device profile (if configurable)
- Any data set or parameter overrides

2. Observe the playback (optional, but useful for the first run)

For your first run, it’s helpful to:

Watch a live or recorded playback
Compare Fume’s actions with your original Loom-style recording
Check that:
- Clicks land on the correct elements
- Inputs are filled correctly
- Page transitions happen as expected
- Assertions fire at the right time

If something looks off, you can pause and later adjust selectors, timings, or assertions.

3. Review the result

After the run:

Confirm whether the test passed or failed
Review:
- Step-by-step logs
- Screenshots or video of the run
- Any error messages or failed assertions

Use this feedback to refine the test until it reliably passes when the app behaves correctly.

Step 7: Debug and stabilize your test

It’s normal for the first Fume test created from a Loom-style recording to need a few tweaks.

1. Fix flaky selectors

If a step occasionally fails to find a button or field:

Replace brittle selectors (e.g., pure CSS based on positions or auto-generated IDs) with:
- Data attributes (data-test-id, data-testid)
- Stable labels or aria attributes
Coordinate with developers to add test-friendly attributes to key elements

2. Adjust waits and timing

Some flows require:

Waiting for network requests to complete
Waiting for async content to appear (e.g., modals, toasts, dynamic tables)

If Fume allows:

Use smart waits based on element visibility or network completion rather than fixed timeouts
Add explicit “wait until visible” or “wait until text appears” assertions where needed

3. Clarify assertions

If tests pass even when behavior is wrong—or fail for the wrong reasons:

Tighten assertions:
- Match specific text, not just “element exists”
- Verify both UI and data state where possible
Remove irrelevant or overly brittle checks (e.g., exact pixel positions unless they really matter)

Repeat the run–refine cycle until the test behaves predictably.

Step 8: Turn your Loom-style derived test into part of your automated suite

Once your first Fume test from a Loom-style screen recording is stable, integrate it into your ongoing testing and release process.

1. Tag and categorize the test

Label the test by:

Feature (e.g., “Onboarding,” “Billing,” “Checkout”)
Type (e.g., “Smoke,” “Regression,” “Critical path”)
Release version or epic, if relevant

This makes it easier to search and organize as your test suite grows.

2. Add it to test runs or pipelines

If Fume integrates with CI/CD:

Add your test to:
- Pull request checks
- Pre-release or nightly regression suites
- Post-deploy verification flows

This ensures the user journey you recorded stays protected as your product evolves.

3. Share the test with your team

Share the test link or run results with:

Product managers (to validate the flow matches the intended experience)
Developers (to align on selectors and assertions)
QA engineers (to expand coverage from this base test)

Your Loom-style recording becomes a living, executable artifact everyone can understand.

Best practices for creating future Fume tests from Loom-style recordings

Now that you know how to create your first Fume test from a Loom-style screen recording, you can streamline future recordings with these habits:

Narrate clearly and explicitly
- Say what you’re doing and what you expect:
  - “I’m clicking the ‘Create project’ button and expect a modal to appear.”
Keep each recording limited to one main flow
- Shorter, focused recordings produce cleaner tests and reduce ambiguity.
Start from a known state
- Log out, reset data, or use a dedicated test account before recording.
Call out critical validations in your narration
- “This confirmation message is what tells me the flow worked.”
Record variations for edge cases
- For example:
  - Successful login
  - Wrong password error
  - Locked account scenario

These can become separate Fume tests derived from different Loom-style recordings, together forming a robust test suite.

Troubleshooting common issues

If you run into problems while creating your first Fume test from a Loom-style screen recording, check these common scenarios:

Fume misses a step in the recording

Ensure the action is visually clear and slow enough to detect
Re-record that portion with clearer cursor movement
Manually insert the missing step in Fume

Assertions don’t match what you intended

Edit the test to:
- Update the specific text or element you’re validating
- Add additional checks based on your original narration
Re-run the test to confirm behavior

The test works locally but fails in CI or other environments

Verify environment configuration (URLs, credentials, feature flags)
Ensure test data or accounts exist in the CI environment
Check for differences in UI (e.g., banners, cookie popups) that might obscure elements

From Loom-style walkthrough to living test asset

Using Fume, your Loom-style screen recording is no longer just a one-off explanation. It becomes:

An automated test that protects your core flows
A shared reference for how a feature should work
A starting point for building out a broader regression suite

By following the steps above—recording a clear Loom-style walkthrough, importing it into Fume, refining the auto-generated test, and integrating it into your pipeline—you can create your first Fume test from a Loom-style screen recording in a way that’s both fast and sustainable for long-term quality.