Fintech Requirements in Azure DevOps

Introduction

30 Second Summary

Payment approval policies can sound clear until amount limits, recipient risk, and approver roles overlap. One vague rule can leave a finance team unsure whether to release a payment or stop it for review.

In this project, you will turn a fictional FinPay approval policy into a precise User Story with acceptance criteria in Azure Boards. You will use linked manual tests to expose ambiguity before turning a failed maker-checker check into an actionable defect.

What You'll Build

You will run FinPay scenarios in Microsoft Test Runner and watch your Stories board show passed, blocked, and failed evidence linked back to the approval policy.

By the end of this project, you'll have:

• An ordered approval policy with a decision table that lets a reviewer predict whether each payment is auto-approved or routed to eligible Finance Managers.
• A five-test evidence trail covering the simple path, the exact amount boundary, conflicting rules, and approval-role restrictions.
• A linked Bug and saved query that let a reviewer move from failed maker-checker evidence to an active defect through one traceable workflow.
• Secret Mission: Add CFO approval above $25,000 while preserving the existing rule precedence.

Are there any prerequisites?

You need access to a Windows device with Microsoft Edge plus an Azure DevOps Services account. The setup verifies Basic access without requiring Basic + Test Plans.

Before We Start

Before any hands-on work, this is your moment to commit to the FinPay workflow you are about to specify. That purpose will anchor every requirement that follows.

Set Up the FinPay Requirements Lab

Your FinPay commitment now needs a workspace that turns payment policy into traceable evidence. Azure DevOps Services provides that workspace through Azure Boards.

Inline tests require Basic access. Verifying that access now prevents the testing workflow from stalling later.

The Agile process supplies User Stories with Acceptance Criteria. It also supports the Bugs you will use for defect reporting.

In this step, get ready to:

• Verify that your Azure DevOps account has Basic access.
• Create the private FinPay Requirements Lab project with its required configuration.
• Reach the Stories board with the Agile process confirmed.

Verify your Basic access

Basic access is the minimum level required to view or run inline tests. Stakeholder access does not include those testing capabilities.

Why use inline tests?

Azure Boards supports lightweight inline test creation from a Kanban board with Basic access. Microsoft Test Runner supports browser-based execution at the same access level.

The first five Basic users in an organization are free. This lab does not need the paid Basic + Test Plans features.

• Press the Windows key to open the search bar.
• Type Microsoft Edge into the search bar.
• Press Enter to open Microsoft Edge.
• Navigate to the sign-in page for your Azure DevOps Services organization.
• Sign in with your Azure DevOps account.

You should see the home page for your Azure DevOps Services organization.

• Select Organization settings from the lower-left navigation.
• Select Users.
• Locate the row containing your account.
• Read the access level shown for your account.

✔️ I see Basic access

Your account shows Basic. That access unlocks the inline testing workflow you use throughout the lab.

ⓧ I see Stakeholder access

Stakeholder access cannot view or run the tests used in this project. A personal organization can assign one of its first five Basic seats without cost.

• Switch to an Azure DevOps Services organization you own.
• Follow the Azure DevOps sign-up guide to create a personal organization if you do not own one.
• Repeat the access check until your account shows Basic.

Can't verify Basic access?

Make sure you selected Users under Organization settings. Project settings contains different controls.

If Organization settings is unavailable, use an organization you own. This gives you control over the access level assigned to your account.

Help me verify Basic access in Azure DevOps.

Create the private Agile project

A private project keeps the fictional FinPay policy inside your organization. Its selected process determines the work item structure available later.

• Return to the Azure DevOps Services organization page from earlier.
• Select the Azure DevOps logo to open the Projects page.
• Select New project.

The project form collects the name and visibility. Its Advanced section controls the version control system plus the work item process.

• Enter FinPay Requirements Lab in the Project name field.
• Set the project visibility to Private.
• Expand Advanced.
• Select Git under Version control.
• Select Agile under Work item process.
• Select Create.

Azure DevOps opens the project welcome page. That's the workspace foundation in place.

Your private FinPay project now uses Git version control with the Agile process.

Can't create the project?

If New project is missing, your account may lack project-creation permission. Switch to an organization you own before trying again.

Help me create my FinPay Requirements Lab project.

Confirm the process and Stories board

The project process controls which work item types you can create. The Stories board becomes the browser workspace for the remaining steps.

Before you check the project, which process value and board control do you expect to see?

• Select Project settings inside FinPay Requirements Lab.
• Select Process.
• Confirm that the displayed process is Agile.
• Return to the FinPay Requirements Lab project navigation.
• Select Boards.
• Select Boards from the opened menu.
• Select the Stories board.
• Locate New item on the board.

In Project settings, you see Agile as the process.

On the board, you see Stories with New item available. Your browser-based requirements lab is ready for its first User Story.

Can't see the Stories board?

Confirm that you are inside FinPay Requirements Lab. An organization-level page does not show the project board.

Check that the project process is Agile. Another process can use different work item names.

Help me find the Stories board in Azure DevOps.

Your private Agile workspace is ready. Next, you'll turn the first FinPay payment rule into a linked passing test.

Create a Passing Payment Test

Your private Agile project is ready on its Azure Boards Stories board. Now the project needs a requirement that someone can test.

A single visible requirement-to-test path gives you an early win before the approval policy grows more complex. You will carry one User Story from policy wording to a passing result in Microsoft Test Runner.

In this step, get ready to:

• Create the payment-routing User Story with testable policy wording.
• Link an inline test for a low-risk payment below the amount boundary.
• Execute the test with the supplied RC-1 result.

Create the payment User Story

Acceptance criteria define the observable conditions that a requirement must satisfy. The first criterion gives FinPay one precise outcome for a low-risk payment below $5,000.

• Return to the Stories board from the previous step.
• Click New item on the Stories board.
• Type Route outgoing payments for approval as the User Story title.
• Press Enter to create the User Story.
• Select the Route outgoing payments for approval card to open the work item.
• Enter As a finance operations analyst, I want FinPay to route outgoing payments according to approval policy so that payments receive the required review. in the Description field.
• Enter Given a low-risk recipient and an amount below $5,000, when the payment is submitted, then FinPay sets the outcome to Auto-approved and requires zero reviewers. in the Acceptance Criteria field.
• Use the save control at the top of the work item to save the User Story.

You now have a requirement with a named user need and a measurable result. A test can compare FinPay's behavior directly with that result.

Link the first inline test

An inline test created from a board work item is automatically linked to that work item. This requirement-to-test traceability lets a reviewer move from the policy to its evidence.

• Return to the Stories board.
• Open the Work item actions menu on the Route outgoing payments for approval card.
• Select Add test.
• Enter Auto-approve a low-risk payment below $5,000 as the test title.
• Press Enter to create the inline test.

You will see the inline test beneath the User Story on the Stories board. Azure DevOps creates the link automatically.

• Select the Auto-approve a low-risk payment below $5,000 test title to open it.
• Enter submit fictional payment P-001 for $4,999 to a low-risk recipient. in the first action cell.
• Enter Outcome is Auto-approved: required approval count is 0. in the expected result cell.
• Use the save control at the top of the test to save the test step.

Why Use Inline Tests Here?

Inline tests keep quick checks beside the User Story. Azure DevOps also preserves the link automatically.

Basic access supports adding tests from the Kanban board. It also supports web-based execution from Microsoft Test Runner.

Run the test and record a pass

Manual testing compares an expected result with behavior observed in a specific release candidate. This run uses RC-1 as the source of the observed behavior.

The Run test action opens Microsoft Test Runner in a new browser window. Microsoft Edge may pause the launch if pop-ups are blocked.

Before you run the test, do you expect the RC-1 result to satisfy both expected conditions?

• Return to the Stories board.
• Open the inline test menu for Auto-approve a low-risk payment below $5,000.
• Select Run test.
• Allow the new browser window if Microsoft Edge prompts you.

Microsoft Test Runner opens with the linked test step. The runner is where the supplied RC-1 behavior becomes saved execution evidence.

• Enter Auto-approved, 0 approvals as the RC-1 observed result.
• Mark the validation step as Passed.
• Use the runner's save control to record the result.
• Return to the Stories board.
• Confirm that the inline status for Auto-approve a low-risk payment below $5,000 shows Passed.

Strong work. Your first FinPay rule now has evidence behind it. A reviewer can trace the User Story to its linked passing test.

Microsoft Test Runner Did Not Open?

• Allow pop-ups from dev.azure.com in Microsoft Edge.
• Confirm that JavaScript is enabled in Microsoft Edge.
• Return to Organization settings to recheck your Basic access under Users.

If the window still does not open, help me troubleshoot Microsoft Test Runner in Azure DevOps.

Your low-risk path is precise. Next, you will expand the approval policy to test whether every payment still has one clear outcome.

Expose the Approval-Rule Conflict

Your Azure Boards User Story now proves that FinPay can auto-approve one low-risk payment. Approval policies become harder when one payment matches several conditions.

In this step, you will expand the acceptance criteria. A decision table will show whether those rules produce one clear outcome for every payment.

In this step, get ready to:

• Expand the User Story with amount, recipient-risk, and initiator-ineligibility rules.
• Map the rule combinations in a decision table.
• Assess a high-risk inline test against the expanded policy.

Expand the payment policy

Each added rule is clear when read alone. The overlap becomes visible when the same payment matches multiple rules.

• On the Stories board from earlier, select the Route outgoing payments for approval User Story.
• In Acceptance Criteria, add these three statements as separate lines: A payment of $5,000 or more requires one Finance Manager approval. A payment to a high-risk recipient requires two different Finance Manager approvals. The payment initiator cannot approve that payment.
• Use the work item's save control to store the updated criteria.

You should see three new criteria below the original low-risk rule. They cover the amount boundary, high-risk recipients, and initiator eligibility.

Good. The User Story now contains every rule needed to challenge the original simple path.

Build the decision table

Rules can look complete in a list while still producing multiple answers for one input. The decision table places each combination beside its implied outcome.

• In the User Story, select either Description or Discussion as the home for your table.
• Add a three-column table with these entries: Header row: Recipient risk, Amount, Rule outcomes currently implied. First row: Low, Below $5,000, Zero approvals. Second row: Low, $5,000 or more, One approval. Third row: High, Below $5,000, Zero approvals and two approvals conflict. Fourth row: High, $5,000 or more, One approval and two approvals conflict.
• Use the work item's save control to store the table.

You should now see two high-risk rows with conflicting approval counts.

There it is. Both high-risk rows carry competing outcomes, so the requirement cannot predict one result.

What Did the Table Expose?

Below $5,000, the amount rule implies zero approvals. The high-risk rule implies two approvals for the same payment.

The policy has no rule precedence. A Blocked test records that the specification needs clarification before the implementation can be judged.

Assess the high-risk scenario

A manual test needs one expected result for each validation step. The high-risk scenario now tests whether the current wording can supply one.

• Return to the Stories board from earlier.
• Open the User Story's Work item actions menu.
• Select Add test.
• Enter Route a high-risk payment below $5,000 in the inline test title field.
• Press Enter to create the test.

You should see the second test listed beneath the User Story.

That connection is in place. The high-risk scenario is now linked to the same requirement as the passing low-risk test.

Can't See the New Test?

• Confirm that you opened Work item actions on the Route outgoing payments for approval User Story.
• Check that Add test appears in that menu.
• Return to the Basic access check from Step 1 when Add test is missing.

Help me find Add test for this User Story.

• Select Route a high-risk payment below $5,000 to open the new test.
• In the first Action row, enter Submit fictional payment P-002 for $100 to a high-risk recipient.

Before you complete the expected result, do you think the current policy supports one definitive outcome for P-002?

• In the matching Expected Result field, enter Unresolved: the current requirements imply both Auto-approved and two approvals.

The expected result itself has to record two incompatible outcomes. This is the intended shortfall in the current specification.

• Use the test's save control to store the scenario.
• In Discussion, enter Rule precedence is missing.
• Use the test's save control to store the note.

You should see the missing-precedence note saved with the test.

• Return to the Stories board.

Before you update the inline status, what do you expect the board to show beside each of the two tests?

• Open the inline menu for Route a high-risk payment below $5,000.
• Set the test status to Blocked.

The high-risk test should now show Blocked. The original low-risk test should still show Passed.

You have captured the ambiguity without mislabeling it as a software defect. The board now preserves one proven path beside one requirement gap.

Statuses Not Matching?

• Refresh the Stories board.
• Expand the inline tests beneath the Route outgoing payments for approval User Story.
• Confirm that only the high-risk test is Blocked.
• Confirm that the original low-risk test remains Passed.

Help me correct the inline test statuses on my Stories board.

The policy conflict is now visible as test evidence. Next up, you will clarify the approval order and build coverage around its boundaries.

Clarify the Policy and Add Coverage

Your blocked P-002 test in Azure Boards exposed a conflict in the User Story before it could become an implementation defect. The current acceptance criteria cannot choose one outcome for a high-risk payment below $5,000.

Explicit rule precedence removes that conflict. Boundary tests and role tests then check that the clarified wording covers its most important edges.

In this step, get ready to:

• Replace the conflicting rules with ordered acceptance criteria.
• Update the blocked high-risk test with a deterministic expected result.
• Add boundary and role tests until the User Story has five linked tests.

Order the policy rules

The policy needs a clear evaluation order. High-risk recipient rules come first so their two-reviewer requirement wins at every amount.

• Select the Route outgoing payments for approval User Story on the Stories board from earlier.
• Select the current content in the Acceptance Criteria field.
• Replace the current content by pasting this ordered list:

1. If the recipient is high-risk, FinPay requires approvals from two different Finance Managers, regardless of amount.
2. Otherwise, if the amount is below $5,000, FinPay sets the outcome to Auto-approved.
3. Otherwise, FinPay requires one Finance Manager approval.
4. The payment initiator is not eligible to satisfy any required approval for that payment.

How Does the Order Resolve the Conflict?

• The first criterion evaluates recipient risk before amount.
• The second criterion auto-approves only payments that did not match the high-risk rule.
• The third criterion sends every remaining payment to one Finance Manager.
• The fourth criterion excludes the initiator from every required approval.

• Leave the existing decision table in the Description or Discussion section.
• Save the User Story using the work item's save control.
• Review the saved Acceptance Criteria field to confirm the four rules appear in order.

You should see the high-risk rule first. The existing decision table now has an explicit order that resolves both conflicting high-risk rows.

Criteria Order Not Saving?

Confirm that you used the work item's save control after replacing the criteria. Check that the high-risk rule remains first if the editor reformats the numbered list.

Help me preserve the ordered FinPay acceptance criteria in my Azure DevOps User Story.

Resolve and rerun the blocked test

The blocked status represented a requirements gap. The ordered policy gives Microsoft Test Runner one expected result to assess.

• Select the linked Route a high-risk payment below $5,000 test beneath the User Story.
• Replace its current Expected Result with Outcome is Needs approval; required approval count is 2.
• Save the test case using its work item save control.

The saved test now shows one deterministic result for high-risk payment P-002.

Before you run the test, do you expect the clarified high-risk scenario to remain blocked or pass?

• Launch the updated test by selecting Run test from its inline test menu.

Microsoft Test Runner opens in a new browser window with the updated validation step.

• Enter Needs approval; 2 approvals as the supplied RC-2 observed result.
• Mark the validation step as passed.

You should see the validation step change to a passing result.

• Save the test result using the runner's save control.
• Switch back to the Stories board from earlier.
• Refresh the board to load the latest inline status.

The formerly blocked high-risk test should now show Passed.

Test Runner Did Not Open?

• Allow browser pop-ups from dev.azure.com.
• Confirm that JavaScript is enabled in Microsoft Edge.
• Verify that your account still has Basic access and permission to view test runs.

Help me launch Microsoft Test Runner from my Azure Boards inline test.

Add the boundary and role tests

Boundary testing checks the exact $5,000 threshold. Negative testing checks whether FinPay rejects an ineligible approver.

The final sequence tests the maker-checker control across two eligible Finance Managers. Together these cases turn the policy into five focused inline tests.

• Open the Work item actions menu on the Route outgoing payments for approval User Story.
• Select Add test.
• Enter Route a low-risk payment at exactly $5,000 as the test title.
• Press Enter to create the linked test.

You should see the new boundary test beneath the User Story. The inline test count is now three.

• Repeat the same add-test process using the title Reject approval by the payment initiator.

You should now see four linked inline tests beneath the User Story.

• Repeat the add-test process using the title Approve a high-risk payment after two eligible managers.

You should now see five linked inline tests beneath the User Story.

How Does Inline Traceability Help?

Tests created from a board work item are automatically linked to that work item. A reviewer can move directly between the FinPay requirement and its coverage.

• Select the Route a low-risk payment at exactly $5,000 test.
• Enter Submit a low-risk payment for exactly $5,000. as the test-step action.

The action now targets the exact point where FinPay stops auto-approving low-risk payments.

• Enter One Finance Manager approval is required. in the Expected Result field.
• Save the boundary test using its work item save control.

The boundary test now pins the $5,000 threshold to one required approval.

• Select the Reject approval by the payment initiator test.
• Enter Attempt approval by the payment initiator. as the test-step action.

The action now isolates the prohibited approver role.

• Enter The approval attempt is rejected and the payment remains pending. in the Expected Result field.
• Save the maker-checker test using its work item save control.

The negative test now defines the safe outcome when an initiator tries to satisfy their own approval.

• Select the Approve a high-risk payment after two eligible managers test.
• Enter Record approval from the first eligible Finance Manager. as the first test-step action.

The first test step now captures the intermediate state after one eligible approval.

• Enter One approval remains pending after the first eligible Finance Manager. as the first Expected Result.
• Add a second test step with the action Record approval from a different eligible Finance Manager..

The two test steps now distinguish the first manager from the second manager.

• Enter The payment becomes Approved only after a different eligible Finance Manager approves. as the second Expected Result.
• Save the high-risk approval-sequence test using its work item save control.

The completed sequence requires two distinct eligible Finance Managers before the payment becomes Approved.

Before you check the board, how many linked tests do you expect to see under the User Story?

• Return to the Stories board from earlier.
• Expand the inline test list beneath the Route outgoing payments for approval User Story.

You should see five linked inline tests. The original low-risk test and the updated high-risk test should both show Passed.

That is a major requirements win. Your User Story now has deterministic rules and focused coverage for its boundary cases.

Next, you will execute the maker-checker scenario and turn a failed result into a traceable defect.

File the Maker-Checker Defect

Your ordered policy now has five linked tests in Azure DevOps Services. The high-risk scenario already passes against RC-2.

A clarified requirement only protects the workflow when a failing implementation result becomes traceable evidence. You will preserve that evidence in an Active Bug. A saved query then makes the defect easy to find.

In this step, get ready to:

• Capture a failed maker-checker result for the payment initiator scenario.
• Create an Active Bug from the failed test evidence.
• Save a flat-list query that returns the defect.

Run the maker-checker test

A maker-checker control keeps the person who starts a payment from approving it. This negative test checks that separation with Leo occupying both roles.

• On the Stories board from earlier, locate the Route outgoing payments for approval User Story.
• Expand its inline test list.
• Find Reject approval by the payment initiator.
• Open the inline test context menu.

Before you run the test, do you think RC-2 enforces the separation between initiator and approver?

• Start the test by selecting Run test.

Microsoft Test Runner opens in a new browser window. The expected result still requires the approval attempt to be rejected while the payment remains pending.

For this execution, use fictional payment P-004. It is a $6,000 low-risk payment initiated by Finance Manager Leo.

• Evaluate the validation step using the supplied RC-2 evidence.
• Record Leo approves as the approval observation.
• Record outcome becomes Approved as the resulting state.
• Mark the validation step as Failed.
• Add the failure comment the initiator satisfied their own required approval.
• Save the test result.

The overall test is now recorded as Failed. That result proves the implementation violated the role restriction in a reproducible scenario.

Why Is This a Defect?

The acceptance criteria explicitly make the payment initiator ineligible for every required approval. RC-2 allows Leo to satisfy the approval on the payment he initiated.

The failed result preserves the difference between the required behavior and the observed behavior. That evidence gives developers a specific control gap to investigate.

Test Runner Did Not Open?

Allow pop-ups from dev.azure.com in Microsoft Edge. Confirm that JavaScript is enabled.

If the window still does not open, verify that your account can view test runs.

Help me launch Microsoft Test Runner from my inline test.

Create the linked Bug

Creating the Bug from the failed Test Runner result carries the test steps into the defect. It also carries the failure comment into the defect.

The test relationship remains available through Related Work. That link connects the defect directly to its execution evidence.

• In the failed Test Runner result, select Create bug.

A Bug draft opens with the failed test evidence included.

• Enter Initiator can approve own payment as the title.
• Save the Bug.

That catch now has a defect record carrying its execution evidence.

• Open the newly created Initiator can approve own payment Bug.
• Set the State field to Active.
• Save the Bug.

You should see the Bug title with its state set to Active.

• Review the preserved failed test steps.
• Confirm the failure comment says the initiator satisfied their own required approval.
• Open the Related Work section.
• Confirm the failed test relationship is present.

Missing Test Evidence or Related Work?

Confirm that you created the Bug from the failed Test Runner result. A standalone Bug does not inherit the execution evidence automatically.

Help me restore the failed test traceability.

Save the defect query

A saved flat-list query turns a growing backlog into a repeatable defect view. This query filters by work item type so the Active Bug stays easy to retrieve.

• Return to the Azure DevOps project tab from earlier.
• Select Boards in the left navigation.
• Select Queries.
• Select All.

The All view contains the controls for creating a reusable query.

• Select New.
• Select New query.

The Query Editor starts with Flat list of work items selected. Its Work Item Type clause starts with the value set to any work item type.

• Keep Flat list of work items as the query type.
• Set the filter to Work Item Type = Bug.

Before you run the query, which work item do you expect the Bug filter to return?

• Run the filter by selecting Run.

The results should contain the Active Bug titled Initiator can approve own payment.

• Save the query under My Queries with the name FinPay Defects.

Your reusable defect view is now stored with the project.

• Return to My Queries.
• Select FinPay Defects.

Before you run the saved view, do you expect it to retain the Bug filter?

• Run the saved query by selecting Run.

You should see the Active Initiator can approve own payment Bug in the results. You have closed the loop with a saved view that surfaces the traceable defect.

Query Returns No Bugs?

Confirm that the query filter is Work Item Type = Bug. Check that the defect was saved as a Bug.

Open the defect to confirm its state is Active. Run the saved query again after saving any correction.

Help me troubleshoot my empty FinPay Defects query.

Secret mission

Add CFO Escalation Without Breaking Existing Rules

FinPay now needs extra oversight for very high-value payments. In this mission, you will add a CFO approval without changing the existing amount and recipient-risk paths. Two passing tests will prove that the boundary and high-risk combination still behave predictably.

Clean Up Your Resources

Clean Up Your Resources

Your Azure DevOps Services lab stays at $0 while you use one of your organization's first five free Basic users because it has no running compute resources. Choose whether to keep the private project, sign out for now, or delete it.

Resources you used:

• Private project named FinPay Requirements Lab using the Agile process.
• Two User Stories containing ordered approval rules and decision tables.
• Seven linked inline tests with stored Microsoft Test Runner results.
• Active Bug named Initiator can approve own payment with its failed test relationship.
• Saved query named FinPay Defects under My Queries.

Keep everything running

No action is needed. Choose this if you want to preserve the lab as evidence of your requirements engineering and manual testing workflow.

• Keep the FinPay Requirements Lab project private in your Azure DevOps organization.
• Keep your access level at Basic because this project does not require the paid Basic + Test Plans tier.
• Return to the Stories board whenever you want to review the User Stories, tests, Bug, or query.

Pause - I'll come back to this later

Sign out for now while keeping every project artifact available for your next session. There are no running compute resources to stop.

• Sign out of Azure DevOps Services from the account menu in the page header.
• Close Microsoft Edge after the sign-out completes.
• Leave the FinPay Requirements Lab project unchanged so your stored test evidence remains available.

Delete - I don't want to use this again

Remove the entire project if you no longer need its requirements or test evidence. Azure DevOps keeps a deleted project recoverable for 28 days before permanent deletion.

• In Azure DevOps Services, select Organization settings.
• Select Projects.
• Select the FinPay Requirements Lab project.
• Select Delete.
• Enter FinPay Requirements Lab in the confirmation field.
• Confirm the project deletion.

The project leaves your active project list. Its User Stories, inline tests, stored results, Bug, links, and saved query leave normal project access with it.

Nice Work!

Nice Work!

Outstanding work! Your FinPay Requirements Lab in Azure Boards now converts a fictional payment policy into testable requirements with traceable evidence.

You've learned how to:

• Translate a plain-language approval policy into a User Story with ordered Acceptance Criteria. Use a decision table to make rule precedence deterministic.
• Design five linked inline tests across the full approval policy. The set covers the happy path, amount boundaries, high-risk combinations, plus maker-checker restrictions. A Blocked result exposes the ambiguity before the policy is clarified.
• Run manual tests in Microsoft Test Runner. Preserve the failed maker-checker result in the Active Bug Initiator can approve own payment. Retrieve the defect through the FinPay Defects saved query.
• Secret Mission: Extend the approval model with an additive CFO escalation rule for amounts greater than $25,000. Prove that exactly $25,000 requires no CFO. Confirm that a high-risk payment at $25,000.01 requires two different Finance Managers plus one eligible CFO.

Ready to quiz yourself?