Check your app in a real browser
Ask Jigward to click through your app the way a QA engineer would, and get a replayable recording, the console and network logs, screenshots and a report. What to set up, what you get, and the limits.
Some checks only make sense in a browser: does sign-in still work on staging, does the booking form accept a ride that crosses midnight, does the new page break on a narrow window. This guide shows how to give that check to Jigward, and what it leaves behind for you to look at.
The example is set at Orbit Cab, a made-up cosmo-taxi company. It describes what Jigward does and keeps on every browser check. It is not a recording of a real Task.
Before you start
An admin sets up a browser profile on the organization’s integrations screen:
- A name, such as “Orbit Cab staging”.
- One or more
httpsaddresses. The browser opens the first one. List the address of a separate sign-in provider too, if your app uses one. - The Context whose Tasks may use it. A Context is one area of work, such as a product, with its repositories and Tasks. Only that Context’s Tasks can open the profile.
- The values Jigward may type, each under a key such as
LOGINorADMIN_PASSWORD, with a line saying what it is for. Every value is secret and hidden on screen until a member asks to see it.
The site has to be reachable from the public internet. A site behind a private network is out of reach.
1. Ask for the check
Give a Task from anywhere you give one: the web, a Chat, a Slack thread or a Jira issue.
Example request
On Orbit Cab staging, book a ride from Earth Port to Moon Base 2 at 23:50 UTC and another at 00:10 UTC. Check that both show the same fare, and tell me what you see if they don’t.
2. Jigward works in the browser
Jigward opens the profile in a browser, reads each page, clicks and types, and signs in. It picks the values it needs by their keys and descriptions and types them itself: the model names a field and never sees the value. A value is typed only into the profile’s own sites.
It may follow links to any public site the work needs, and it may open the browser again later in the same Task. Each session keeps its own recording.
3. What you get back
Before it reports, Jigward closes the browser and waits for the session’s recording, so everything below is already on the Task when it says what it did:
- A recording that replays on the Task’s Recording tab.
- The console log of the session.
- The network requests the page made: when each was made, where to, how it was answered, and the request id the server gave it. Of an address, Jigward keeps the path and a request or trace id, never the rest of the query.
- Screenshots of what it saw.
- The report: what it checked, what it found, and its verdict, Done, Partly done or Blocked. The verdict is Jigward’s word, not a check.
The request ids let a bug seen in the browser be followed into the server’s logs. With AWS CloudWatch Logs connected, the same Task can search the log groups an admin allowed.
For a Task given in Slack, the screenshots and the recording follow the report into the thread as files.
4. Keep the check, if you want it again
Jigward keeps no library of tests of its own. When you ask it to keep a check it explored, it writes the check as a small Playwright test project in the repository you name: assertions on what the request cares about, stable locators, its own test data, the address and any sign-in read from the environment rather than from the profile, and a README on how to run it. It runs the test as the repository’s tests run and offers it as a draft pull request.
Example follow-up
Keep this as a Playwright test in the orbit-cab-web repository.
A recording, a screenshot or a script that asserts nothing is never presented as such a test.
Where people come in
- You decide what the evidence means. The report says what Jigward saw; you watch the recording and judge whether it matches what you asked.
- You review the test it proposes, like any pull request. Jigward never merges it.
- An admin owns the profiles: which sites, which values, which Context.
Limits worth knowing
- A session is not watched live. You see it afterwards, in the recording.
- Private networks are out of reach. The browser works on publicly reachable sites only.
- A screenshot shows what the page shows. A page that displays a credential shows it in the screenshot, and for a Slack Task that screenshot is posted in the thread, where everyone in the channel sees it.