Test a kanban stage move and the probability with it

Failure modes in this flow

The failure worth catching is a stage that moves without its probability following, because the board looks right and the forecast is wrong.

• The starting column - Qualification at 25%, with the card badged to match.
• The move - to the Proposal column.
• The new probability - the badge reading 50%, matching the column header.
• The amount is untouched - still $48,000.00, because a stage change is not a value change.

Asserting the amount after the move is a cheap guard against a card that is rebuilt on drop and loses a field. It is the kind of thing that only shows up in a revenue report.

Writing the objective

The column headers carry their probabilities, so the card badge and the column it sits in can be checked against each other rather than in isolation.

---
mode: testing
url: https://my-testing-repo-main.vercel.app/salesforce-clone-app/opportunities?reset=true
max_steps: 40
tags: [salesforce, crm, pipeline]
---

# Salesfource 28.2: Opportunity kanban

Catalog objective: move an opportunity to the next stage on the kanban board.
Key assertion: the stage updates and the probability changes with it.

## Verify where the opportunity starts
Verify the "Qualification · 25%" column holds "Northwind - Platform Licence" at "$48,000.00" with a badge reading "25% probability".

## Move it to the next stage
Click "Move to Proposal" on the "Northwind - Platform Licence" card.

## Verify the stage changed
Verify the card now sits in the "Proposal · 50%" column.

## Verify the probability changed with it
Verify the card's badge now reads "50% probability" and its amount is still "$48,000.00".

The stage and the probability are asserted in separate steps, which means a move that lands in the right column with the wrong probability fails on the specific thing that is wrong.

The assertions in detail

A starting position, a move, and two independent checks.

Splitting the stage and the probability into separate steps is the detail worth copying. Combined, a half-correct move reads as one failure instead of two facts.

Running it locally

kane-cli testmd run tests/salesforce/opportunity-kanban_test.md

Add a backward move, since pulling a deal back should lower the probability and regression logic is usually written for the forward case only.

Forecast figures are worth checking on every release of the pipeline UI. Kane CLI in a pipeline covers that, and checking the UI before a pull request covers catching it earlier.