Test results in Microsoft Teams, as a card worth reading
A failed automation test, a dropped device session or a finished accessibility scan posts to your channel as a colour-coded card with a facts table and a button that opens the run.
Paste an incoming webhook URL · nothing to install in Teams
Automate test failed — Checkout suite
- Product
- Automate · Chrome 152 on Windows 11
- Started
- 4 Sep 2026, 12:48 UTC · [email protected]
- Duration
- 2m 41s
- Reason
- assertion failed on the payment step
View details
- No Teams app
- paste an incoming webhook URL
- Failures-only preset
- or every result, per product
- Readable UTC times
- a 4 Sep 2026, 12:48 UTC string, not a reader's clock
- 5 retries
- before a delivery is marked exhausted
What lands in the channel
Every message is an Office 365 MessageCard built from one neutral description of what happened, rendered in the format Teams understands.
A severity you can scan past
A theme colour set by severity runs down the edge of the card — green for a pass, red for a failure, grey for something that is neither — so it is readable while scrolling, before anybody has read a word of the title.
The facts as a two-column table
The build or test name, the product and the device it ran on, who started it, when, how long it took, and a plain-English reason when a session ended for one — rendered as a labelled table of name and value pairs, which stays scannable at six or seven facts.
Readable UTC start times
The start time arrives as a readable UTC string — 4 Sep 2026, 12:48 UTC — built from a fixed month table, so it is the same on every card. Only Slack, of the four channels, has a token to render a time on the reader's own clock; Teams does not.
No 'N/A' clutter
A fact with no value is dropped rather than printed as N/A — device sessions have no test-management project, so the Project fact simply doesn't appear rather than reading N/A on every card.
A View details action back to the run
At the foot, an OpenUri action — a real View details button — opens the session or scan, where the recording, console output and network log for that run are waiting.
Reliable delivery
The webhook URL is re-validated before every dispatch, redirects are refused, and a slow channel never holds up the test that triggered it.
Every event you can subscribe to
Pick events per product — by hand, or with a preset (all results, or failures only). These are the only events that exist.
Device farm & accessibility
- Automate test passed, failed or errored
- Live session ended (neutral) or failed
- Accessibility scan completed or failed
Test management
- Test case created or deleted
- Cycle created, completed or deleted
- Plan created, completed or deleted
- Bulk execution completed
Deliberately absent
- Visual — appears in the picker with an empty list; nothing emits a visual event yet.
- No automate.build.completed — a build is a label, not an object with a lifecycle.
- Attempts before a delivery is marked exhausted
- 5
- After which an incomplete send is abandoned
- 10s
- Delivered records are swept after a week
- 7 days
- Unsuccessful records are swept after a month
- 30 days
Sending is fire-and-forget — a slow channel never holds up the run. Retries are spaced a minute, five minutes, half an hour, two hours and eight hours apart. The webhook URL is re-validated before every dispatch; loopback, private, link-local, carrier-grade NAT and multicast addresses are refused; redirects are not followed; and only the HTTP status is kept, never the reply body. The same guards cover a raw JSON webhook.
Frequently asked questions
No. You create an incoming webhook for the channel, paste the URL into TestKase, name the integration and choose its events. There is no app to publish and no bot to register, and the integration is outbound only — nothing listens and nothing replies in the conversation. The card also cannot tag a person, a team or a channel, so it will not raise a personal notification for a named owner; your own channel notification settings in Teams are the only control over who is alerted. Whether creating the webhook needs an administrator is a question about your tenant's policy, not about TestKase.
A MessageCard — the Office 365 connector format — with a theme colour set by severity, a title, a facts table of name and value pairs, and a View details action that opens the run. We do not send an Adaptive Card. It carries no screenshot, no video thumbnail and no attached log, and a message is posted once and never edited — a re-run produces a new card rather than updating the old one. If your channel's webhook is a Workflows URL rather than a connector one, it is worth confirming against Microsoft's current guidance for your tenant that a MessageCard renders the way this page describes.
No. Teams receives a readable UTC string such as 4 Sep 2026, 12:48 UTC, built from a fixed month table rather than the server's locale. Slack is the only channel that can render a per-reader local time, because it has a date token for it; Teams, Discord and Google Chat all get the UTC string.
Take the failures-only preset per product rather than all results, and leave test-management events off unless somebody wants them. A Live session ending is deliberately neutral rather than a success, because a tick on every closed session is exactly the noise that gets a channel muted. Events are sent as they happen — there is no digest, no batching and no quiet hours to lean on instead.
It is retried up to five attempts, spaced a minute, five minutes, half an hour, two hours and eight hours apart, then marked exhausted. Switch the integration off part way through and the pending delivery is cancelled instead. Only the HTTP status is recorded, never the body of the reply.
No. One integration is one webhook URL and therefore one channel. Create a second integration, with its own event list, for a second channel.
Send the next failure to the channel your team already has open
Create an incoming webhook, take the failures-only preset, and see what the first real card looks like.