Journey Lanes

How it works

How journey testing works: from repository to monitored flow

The same user journey goes from description to diagram, from diagram to an end-to-end run, and from one run to a synthetic monitor that runs on its own.

A woman writing on coloured sticky notes on a dark wall
Photo: Vitaly Gariev on Unsplash

  1. Create your organization and a project

    Create an account with your name and email, confirm the email, and choose a password. Then name your organization and start a project. Invite the people you work with as viewers, editors or owners.

  2. Connect your repositories

    Connect GitHub, GitLab or Bitbucket and pick the repositories of your API and, if you have one, your frontend; or add an OpenAPI document, GraphQL schema or gRPC service. Journey Lanes reads endpoints, records, roles and pages from them. A scan takes seconds, and every source is scanned again daily to catch API changes.

  3. Describe a journey, or take a tour

    Write the journey the way you would explain it to a colleague. Journey Lanes draws it with a lane per role, and you can edit every step. Or pick a role and get a tour of everything it may do, or build the flow by clicking endpoints from the menu. Start new flows with saved roles, so signing in is already set up.

    “A company admin logs in. The company admin sees the users and can create a user. An employee logs in. The employee sees the products and can order a product and update their order.”

    1. Company AdminPOST /realms/portal/protocol/openid-connect/token
    2. Company AdminGET /api/users
    3. Company AdminPOST /api/users
    4. EmployeePOST /realms/portal/protocol/openid-connect/token
    5. EmployeeGET /api/products
    6. EmployeePOST /api/orders
    7. EmployeePATCH /api/orders/:id

  4. Run it against the mock

    Press “Run flow”. Each role signs in to the mock, steps call their endpoints with ids from earlier answers, and the canvas marks every step as it passes or fails. “Help me” on a step sets up its body, parameters and checks from the code behind it, and “Explain this failure” says why a step failed.

  5. Add a live environment

    Give your test or acceptance environment an address, the way your users sign in, and a test account per role, and the same flow runs there. Writes stay off until you allow them. A test inbox lets a flow follow the emails your app sends, such as invitations, and a relay agent reaches an environment on a private network.

  6. Monitor, audit and load test

    Switch on monitoring and choose where alerts go. Run the access audit to see what each role can reach that it shouldn’t, and load test the steps that matter under traffic. Call the deploy hook from CI to check every deploy.

Step by step, with the buttons to press: getting started.

Start with one journey

Sign-in, and the one action your users do most, is a good first flow.

Create an account See how it works