Power Apps Test Studio can replay UI actions and check visible results in a canvas app. It is useful for repeatable regression checks, but it does not replace connector, permission, security, accessibility or user-acceptance testing.
Microsoft requires the tester to be the app's creator or co-owner. Test Studio also has documented control gaps, including components, PCF code components, nested galleries, media controls and Person-type columns. Read the current Test Studio limitations before choosing which scenarios to automate.
Start with one valuable journey
Choose a journey whose result is easy to prove, such as submitting an expense request. Write down:
- the starting screen and data state
- the user role and permissions
- the values entered
- the action performed
- the visible result
- the record or side effect that must be cleaned up
Use a test environment and test accounts. A UI test that writes into a production list can create real notifications, approvals or records.
Create a suite and case
Open the canvas app for editing, then open Advanced tools > Open tests. If the current Studio labels differ, follow Microsoft's working with Test Studio guide.
Create a suite for a coherent feature, then add a test case. Cases in a suite run sequentially and app state persists between them, so order matters. Either make that dependency deliberate or reset the state at the start of each case.
Record a first draft
Use the recorder to capture the basic interaction, then inspect every generated step. Recorded steps are a draft. Rename them so a failed result explains the intended behaviour.
A generated action may resemble:
SetProperty(txtTitle.Text, "Laptop request")
and a button action may use:
Select(btnSubmit)
Only controls supported by the Select and SetProperty test functions can be driven this way. Avoid changing a control solely to make a weak test pass.
Add assertions that prove the outcome
An action without an assertion proves only that the step ran. Add a check after submission:
Assert(lblConfirmation.Visible, "Confirmation should be visible")
Check meaningful values as well as visibility:
Assert(
lblConfirmation.Text = "Request submitted",
"Expected the submitted confirmation"
)
Use exact assertions for stable application state. Do not assert volatile generated IDs or time text unless that value is the behaviour under test.
Control test data
Tests become unreliable when they depend on whatever records happen to exist. Create uniquely named test records, store their identifiers, and remove them after the case or suite. If cleanup fails, make that visible rather than leaving silent data behind.
For connectors, test at least three identities:
- a normal authorised user
- an authenticated user without the required row or list permission
- the app owner or support account
The owner's successful run does not prove the shared user's connection, licence or data permissions.
Run and diagnose
Run the case in Test Studio, then run it in the browser option documented by Microsoft. Inspect the failed step, the formula result and the app state.
Use Power Apps Monitor when the UI failure may come from a connector, network request or data response. Monitor helps show what the app requested and received. It does not establish that the backend data or authorisation rule is correct.
Build a sensible test portfolio
Cover the paths that can cause damage or support calls:
- required-field validation
- create, update and delete operations
- duplicate submission
- connector failure and retry
- empty data and large data shapes
- nondelegable queries
- each relevant security role
- keyboard use, focus order and screen-reader labels
Test Studio is strongest when paired with formula review, data-source tests, accessibility checks and a short manual acceptance script on the real device form factors.
Release boundary
Store the app and dependencies in a solution and run the agreed checks after importing into the target environment. Connection references, environment variables and security roles can differ after deployment.
A green Test Studio suite proves that those recorded UI checks passed with the selected identity, app version, environment and data state. It does not prove every user journey or production condition.
For practical app testing routines that include permissions, failure paths and release evidence, join the Power Apps Builders Space.
