Skip to main content
Recent releases are detailed below. The full history since the very first version lives in the repository changelog.
​
2026-09-09
A line of a PDF report could come out unreadable, letter by letter, whenever it carried a character the PDF font cannot draw. The promotion decision of an exploratory session — the one line a change board reads first — printed as Q U A L !' P R O D — O K instead of QUAL > PROD — OK.
  • The cause was a single arrow. The PDF engine switches an entire string to a two-byte encoding as soon as one character falls outside the font’s repertoire, then writes it into a font that cannot read it back: every letter ends up preceded by a byte that draws nothing, and the offending character reads as two stray glyphs. One character was enough to break a whole line.
  • Seven places carried the same defect, four of them for months: the promotion band and the date range of the aggregated session report, the human decision override and the unstable-tests table of the standard report, the step detail, the Epic lines of the traceability, and the outdated requirement marker.
  • All seven are fixed at once and by a single mechanism rather than one patch each: every report now passes its text through one place before drawing it, tables included. A new screen cannot make a report unreadable again by forgetting to.
  • French typography is untouched. Em dashes, ellipses, curly apostrophes, guillemets, bullets, œ and € are all part of what the PDF font can draw, and they print exactly as before — verified character by character. Only the handful of symbols the font never could draw change: an arrow prints as >, the step marker as ->, the Epic marker as -, the warning sign as (!). Everywhere else in the product — the work item comment, the closing dialog, the HTML report — an arrow is still an arrow. The PDF is the constrained surface, and it is the one that adapts.
  • A character we have not given a printed form to now becomes a visible ? rather than vanishing: a mute gap in a signed report is worse than a question mark you can see and report. One such character remains today — the ≈ on the remaining effort line of the metrics page, which prints Reliquat ? 1 tester-day. It was unreadable before this release and is merely imperfect now; giving it a printed form is a separate decision.
​
2026-09-09
When you close an exploratory session, you can now record whether the delivery may move to the next environment stage — and that decision lands where the change board actually looks. Until now that conclusion was taken outside the tool and appeared nowhere on the work item the change board reviews. See Promotion decision.
  • Every project starts with a suggested ladder — TEST → QUAL → PROD — that an administrator can rename, reorder, extend or shorten under Settings › Environment stages. Picking the stage when you start a session is optional and nothing is preselected; without a stage, no decision is offered and the session behaves exactly as before. Emptying the ladder disables the feature for the whole project.
  • At closing, a Promotion decision block appears under the verdict, showing the transition (QUAL → PROD, or Validated in PROD on the last stage) and three values: OK, Reserved, Blocked — a comment is required for the last two. The decision is optional, final once the session is closed, and counted nowhere: no pass rate, no quality score, no GO / NO-GO, no campaign export.
  • It is written in three places: a queryable tag on the session task (Passage:QUAL>PROD:OK), a coloured band on the session PDF cover page with the comment and an audit line, and — new for TestPulse — a tag and one discussion comment on the work item the session was run from.
  • That last write is bounded on every side: one target (the work item the session was run from), two fields (its tags and one comment — never a state, an assignment or a link), one trigger (your click on Close with a decision selected, after a preview box has named the work item and shown the exact tag), one switch (an administrator can turn it off). It only replaces a previous decision on the same transition.
  • It is also never blocking. If the work item form carries unsaved changes, the write is skipped rather than risking a conflict with your own save — you are told what to do. If Azure DevOps refuses it, the session still closes, the task is still created, the decision is still recorded and exported, and the message quotes Azure DevOps’s own wording. Which outcome occurred is printed on the PDF audit line, so a report never claims a write that did not happen.
​
2026-09-07
The file drop zone of an exploratory session is now hard to miss, and a missed drop no longer costs you the session. Dropping a Win+G recording or a log onto the timeline meant aiming at a strip about 40 px high, with no visual feedback of any kind and no alternative to dragging. Miss it and the browser did what a browser does with a file dropped on a page: it opened the file in the tab, and the session you were running left the screen.
  • The zone now follows the pattern the Import tab has used for months — a dashed border, an icon, a title, an explanatory line and a Browse… button, at least 100 px tall. Its size never changes during a session: a target that moves is a target you have to find again.
  • While you drag a file, the whole timeline panel becomes the target. An overlay covers it and says what dropping will do, and releasing anywhere on the panel is treated exactly as if you had aimed at the zone. Crossing an element inside the panel does not make that overlay flicker, and dragging selected text does not raise it at all — only files do.
  • A file released beside the panel is now swallowed: the browser does not navigate, nothing is attached, and your session stays on screen. That guard lives in the Explore tab alone and leaves with it — the Repository tab’s drag & drop is untouched.
  • The Browse… button opens the native picker, for a file you cannot reach by dragging or simply if you prefer a dialog. No type filter is applied: the size limit remains Azure DevOps’s to enforce, not ours to guess.
Dropping several files at once now attaches all of them, and a failure part-way through is named. The timeline accepted one file per drop. Files are now uploaded one after another, each entry computed from the session as it stands at that moment — a note you type while the batch is still uploading is kept, not overwritten. A progress line shows the rank, the total and the name of the file being sent, and a second drop attempted during a batch is ignored without an error.
  • If the second of three files is refused, the first and the third stay attached, and the message names the second one with Azure DevOps’s own wording, unchanged. Nothing is rolled back — what is attached stays attached.
  • The one failure that stops a batch is a permission failure: the re-approval banner is raised, and the remaining files are not attempted.
  • A file released on the drop zone itself was also being uploaded twice, the zone and the panel each handling the drop. The panel is now the only handler.
See Capture & create.
​
2026-09-04
In the standard report, the name of an attached file is now a link, and its type is readable. A file attached to a test result already appeared in the PDF, in a File / Type / Size table — but the name was dead text, and the only way to open it was to go and find it by hand in Azure DevOps. The HTML report has carried the link since it existed: the gap was between our own surfaces.
  • The file name is rendered as a link to the attachment. Every attachment is clickable, whatever its extension — an extension we do not recognise changes the label, never the link. A limit of our own lookup table must not cost you your access.
  • The Type column read application/octet-stream for everything that was not an image, because that value came from a table that only ever knew six extensions, all image formats. It now shows a readable label derived from the file name: PDF, Word, Excel, PowerPoint, CSV, JSON, XML, Archive, Email, Text, Log, Image, and a plain File for anything else. That table is not exhaustive and does not pretend to be — the fallback is nominal behaviour, not a defect.
  • A link is omitted only when there is nothing to link to: a missing URL, or one using neither http nor https. The name is then plain text.
  • Embedded images, the image / non-image split of the page, height estimation and pagination are unchanged.
The Attachments section is now shown by default, on the PDF and the HTML report alike.
  • Everything it shows was already read from Azure DevOps on every generation, so nothing extra is fetched — the report simply stops throwing away data it had already paid for.
  • Stated rather than discovered later: if you had never touched the section list, your reports will now carry an Attachments page, and the HTML report shows its section too.
  • Nothing you saved is rewritten. A report whose sections you had already chosen keeps your choice, including a section you had deliberately turned off.
  • The Reset button in the settings now returns the stored defaults instead of a hand-copied list that would have kept saying Attachments: off.
  • Screenshots of individual steps are a different setting and are untouched.
​
2026-09-04
Session evidence is now listed in the report, and the PDF makes it reachable. A file dropped into an exploratory session is uploaded to Azure DevOps as an attachment of the work item — but the report only mentioned it in passing, announcing a proof without giving any way to open it.
  • Both surfaces now carry an Evidence section listing every attachment of the session, dropped files and pasted captures alike, with name, time and size, in chronological order. No attachments, no section.
  • The report written into the tracking Task is a register: written once at closing and never revisited, it lists what was produced and carries no link. Real access is one tab away on the same work item, and that tab always reflects reality.
  • The PDF is the access surface — the only one that travels outside Azure DevOps, and the only one that can tell the truth at the moment it is produced. That is where the links live.
  • At generation, one grouped call reads which attachments are still linked to the Task. One that is no longer there reads Attachment unavailable rather than offering a dead link. Never one request per file — and if that call fails, nothing is concluded and every link renders as usual, because a network incident must never look like evidence being deleted.
  • An image you dropped stays an attachment line rather than becoming a thumbnail; only pasted captures are embedded. That distinction is deliberate.
Every session row now carries its start date and time, and sessions are ordered inside each story.
  • Expanding a story listed its sessions in whatever order storage returned them, with no date shown at all: on a story carrying four sessions, nothing said which one was the most recent.
  • Each row now shows when the session started — date and time, formatted in your language — so two sessions run on the same day are told apart without opening either.
  • Within a story, sessions run from the most recent to the oldest, and any session still open sits at the top: that is the one you came back to finish. The order between stories has not changed.
Three fixes around sessions whose tracking Task no longer exists.
  • On the story’s Explore tab, the previous-sessions list built its link straight from the stored identifier without ever checking the Task still existed — clicking it landed on an error page. The history now checks every tracking Task in a single grouped read: one that cannot be found loses its link and reads The linked task is no longer available. Never “deleted” — a deleted work item goes to the recycle bin and stays restorable, and a grouped read cannot tell the two apart. Restore it and the link comes back on the next refresh.
  • In the hub, the same session vanished from the inventory altogether. The hub resolves a session’s tester from its tracking Task, and it applies a Tester filter by itself when it opens: unresolved plus filtered-by-default meant a silent drop from an inventory presented as complete. A filter you chose is an intention and still hides what it must; a filter applied for you no longer removes anything you did not ask it to remove. The row keeps its Export button — the session record is intact, only its materialisation is missing.
  • The period filter excluded the very day it claimed to include: asking for sessions from 31/08 to 31/08 returned nothing, even with a session started that afternoon. Both bounds now compare calendar days as you see them on screen, in your own time zone, never an instant. The period printed on the aggregated PDF cover follows the same rule.
​
2026-09-01
Reading the same plan after a reassignment showed the state from before. Returning to the first step worked and the plan list was read again, but picking the same plan brought back exactly what you had seen before applying — only a full page reload showed reality.
  • The test points of a suite were held in memory for the whole session and nothing ever discarded them, so the second read was served from a snapshot taken before the write. The suites an operation touches are now dropped from that memory as soon as it finishes.
  • Suites the operation failed on are dropped too. A conflict means the suite moved; a permission error leaves a doubt about what actually went through. Re-reading costs one call, a wrong figure costs more.
  • Everything else stays in memory: plans the operation never touched open as fast as before, and replaying failed points behaves the same way.
  • The same now applies when test cases are added to an existing suite from the repository — that suite’s contents are read afresh rather than from before the write.
​
2026-08-31
Starting another reassignment takes you back to the first step, on a freshly read plan list. And a saved view no longer produces a report dated months ago.
  • v2.67.0 kept the scope you had chosen and rebuilt its inventory behind a dedicated screen. In real use that proved disorienting — you landed on an inventory with no way of telling whether it showed the state before or after what you had just applied. You now return to Scope, nothing pre-selected, plan list read again, so a plan created, renamed or deleted meanwhile shows up as it is now.
  • The dedicated rebuild screen is gone. The scan it duplicated is the one Analyse the scope has always announced, with the same per-suite progress and the same cancel button. Two clicks more, and you always know where you are.
  • Opening a saved view now sets the report date to today. A view stores the metadata it was saved with, report date included, and re-applied it on opening: a view saved in June and reopened in August generated a June report — and an Excel file named after that date, since the filename derives from it. A view is a reusable model, not a snapshot.
  • Nothing is written back to the view: its saved date stays its own until you save it again. A non-blocking banner names both dates and offers to restore the saved one, for the rare case of regenerating a past report — and says nothing at all when the view was saved today. Editing the date by hand dismisses it: you have decided.
  • A scheduled report carries the date of the run that produced it, with no banner — nobody is in front of the screen. The date read is the local one, so a report generated at half past eleven at night is not dated tomorrow.
​
2026-08-31
The configuration catalogue announced in v2.67.0 was never actually loaded. The call reading a project’s configurations had been answering 404 since the feature that introduced it, and the failure was swallowed silently.
  • The project configuration catalogue is read again. The call targeted the legacy area with an api-version that area does not know, and returned 404 on cloud and on-premises alike. It now targets the test-plan route, with the legacy one in v5.0 as a fallback — the same pattern already used for plans, suites and points. Not an extra call: the same call, at the right address.
  • When both routes fail, the screen says so and falls back to the configurations of the scope, instead of the silent empty list you got until now.
  • Beyond bulk reassignment, the Covered configurations indicator of the report (X / Y) recovers its Y, which had been stuck at zero.
  • A configuration marked inactive in the project is now shown as such. It stays selectable — hiding it would surprise as much as offering it without warning — but it says so in words and sits at the end of the destination list, behind everything still active.
​
2026-08-31
Bulk reassignment could only reassign towards someone — or something — already there. Both destination lists were built from the scope itself, so a configuration defined in the project but carried by no point yet, and a tester holding no point at all, simply could not be chosen.
  • Any configuration defined in the project can now be a destination. The destination list is the project catalogue rather than the inventory of what the scope already carries. Each entry shows how many points of the scope carry it, and one carried by none says so in words, not by colour alone — and stays selectable. The list you replace from is unchanged: it remains the inventory of what is really there, because that is a different question.
  • Any tester can now be a destination. The tester field searches identities — 500 ms after you stop typing, from three characters — and resolves your pick to a real identity rather than to the text you typed. Reassigning a test point requires the identity itself, so a name that was never resolved would have failed only after the review screen, once you were convinced the operation would go through.
  • Testers already present in the scope are offered straight away, without typing and without a search, and Unassigned remains available. Where identity search is restricted — it can be, on Azure DevOps Server — the field says so and falls back to those known testers instead of leaving an empty box.
​
2026-08-31
Bulk reassignment gets usable at real volumes. Two selectors that worked on a demo plan did not survive 175 plans and a 172-suite tree.
  • Search the plan list instead of scrolling it. The scope step now has a search field, in both single-plan and multi-plan modes, matching on plan name, iteration, or an exact identifier. It filters the list already loaded — it never goes out to look for anything. Filtering hides, it never deselects: a selected plan that the search masks stays selected, and the counter keeps showing the real total.
  • Pick a starting suite from the tree, not from a flat list. Suites are now rendered hierarchically, with expand/collapse per node plus expand-all and collapse-all, and a name search that keeps a match visible together with its ancestors. Each node shows the same figures as before — sub-suites and points of its subtree — only somewhere more readable.
  • A suite with no test point of its own no longer hides its children. The flat list was built from the test points, so a suite holding none simply was not in it — harmless as a list, but as a tree it made every descendant unreachable. The tree is now built from the parent-child relation instead. A suite whose whole subtree holds no point is shown disabled and says so in words, not by colour alone.
  • An inconsistent suite hierarchy no longer empties the picker. A parent chain looping back on itself — possible on an older on-premises server — left the tree with no root and every suite off screen. Such a chain is now broken at one point and the suites are shown at top level.
​
2026-08-31
Recorded after the fact: this version shipped without release notes. Its content is described here.
Reassign the tester or the configuration of a whole test plan in one pass. Azure DevOps can assign testers at the level of a single suite, but the action does not cascade into child suites — so a plan of 172 suites meant opening up to 172 of them for 296 points. Neither CSV import nor the bulk-edit grid can reach these two properties either: they belong to the test point, not to the Test Case work item.
  • A new Bulk reassignment tab walks the plan, inventories what is there, and applies the change in one pass — across a single plan or up to ten at once.
  • See the current distribution before deciding anything. Testers and configurations side by side, sorted by volume, each row showing its point count, how many already carry an execution result, and its share of the scope. A configuration accounting for less than 2% of the points is marked residual. Unassigned is a row of its own, not an absence. Nothing is cached: the inventory is rebuilt on every analysis and carries the timestamp it was read at.
  • Three ways to define what changes — replace one or more values with another, apply to the whole scope, or apply to a suite and all its child suites, recursively and at any depth.
  • A mandatory review before anything is written. Points affected, suites touched, points already run, cases skipped, and the estimated number of API calls — plus the operation in plain language and the exact endpoint that will be called. The apply button stays disabled while the impact is nil, and the prior state can be exported as CSV first.
  • Changing a tester and changing a configuration are not the same operation, and the interface says so. Changing the tester keeps the test point and its result attached. Changing the configuration rewrites the test case’s assignments, which Azure DevOps may implement by destroying the point and recreating it — taking its result with it. Different endpoints, different warnings, and a different subtitle on the “include points already run” choice.
  • A test case already carrying the destination configuration is skipped, never merged — merging would delete one of its assignments. Such cases are listed with their suite and identifier, and exportable as CSV.
  • The operation cannot be undone, and says so. Azure DevOps offers no undo and TestPulse keeps no prior state — a deliberate decision, not an omission. See Read-only by default.
  • A partial failure is a valid outcome, not a corrupted one. Nothing is rolled back: points already reassigned stay reassigned. The report lists each failure with its HTTP status and a plain-language cause, and a retry button replays only the failures.
​
2026-08-30
The quality verdict is stricter, on purpose — and some reports will now read NO-GO.Two new floors, and a criterion switched on. The composite score is a weighted average, and an average compensates: with execution, coverage and defect hygiene at their maximum, a plan where most tests failed — or where most were simply never run — could still clear the GO threshold. Each scale now carries a pass-rate floor and an execution-rate floor, both set to that scale’s own GO threshold (0.85 Strict · 0.75 Standard · 0.65 Ramp-up), so there is no new number to learn. Below either one the verdict is NO-GO and the grade is capped at C. A case marked Not Applicable is not a skipped case — taking something out of scope costs nothing. A report with no executed test stays not evaluated, never an E.The failure without a linked defect criterion is now on by default on all three scales, and triggering it caps the grade at C as well. Defect hygiene only ever counted declared bugs, so a failed test with no linked bug scored a perfect 20/20, while declaring the bug properly cost points — the incentive ran backwards.The scale that decides is now visible on the report. One discreet line under the grade names the scale in force and the GO threshold actually applied, so a verdict can be defended without opening Settings — and it carries the low confidence reserve when fewer than five tests ran, instead of keeping it to itself. On screen only: PDF, Word and HTML gain no new line. The scale settings also move to the top of the Settings page, with a sentence stating what they decide.Reports already saved keep their verdict. Each carries the scale captured when it was generated and is re-read under that one. Reports generated before project scales existed at all (before v2.15.0) have no captured scale and are re-read under the current one, so those can change on reopening.See Quality Gate and Decision support.
​
2026-08-30
Your report history now says which project each report came from. Personal history is stored per user across the whole organisation, so anyone working on several projects saw every report in one undifferentiated list. A Project column now sits immediately after Test plan, and a Project filter sits between the status filter and My reports. It opens on your current project, or on All projects when that one has nothing to show — an empty list would read as data loss. The header count switches to of reports whenever a project filter is active.Reports saved from now on record their project. Older ones are derived at display time from the Azure DevOps links they already carry — shown with a dotted underline, naming their source on hover, so a derived value never carries the authority of a stored one. Where neither is possible, reports are grouped under Unknown project, an entry of its own with its count. Nothing is dropped.You can also see who shared a report before approving it. The Shared badge moves next to the plan name, with a Shared by line under it carrying the sharer’s initials and name; your own reports read Shared by you. Reports that are not shared gain nothing.No new Azure DevOps call, no new permission, no report rewritten, and the history CSV export is unchanged. See Report history.
​
2026-08-29
Loading a report from your history now actually takes you to it.Clicking Load restored the report into memory and left you sitting on the History tab, with no visible sign that anything had happened and the plan selector still showing whatever was there before. It now opens the Report tab with the report displayed, and puts the context back with it: the report’s plan is selected again, and its suites are re-checked. A suite deleted from Azure DevOps since the report was built is skipped silently rather than raising an error. For a report consolidating several test plans, TestPulse switches to multi-plan mode and ticks all of the report’s plans — no suite selection is restored there, because multi-plan mode does not offer one in the first place. Reports saved long before this release restore just as well: the plan and suites are read from the report itself, so nothing had to be migrated.And the plan you had just chosen is no longer wiped by the list refreshing behind you.At start-up the plan list appears immediately from cache while fresh data loads in the background. That background refresh used to replace the entire selection state, so anything you picked during that window — through a saved view, a template, the list itself, or the automatic first selection — was silently lost, and you had to choose again. Your selection is now kept whenever the plan is still there in the fresh list; only the list itself is replaced. When the plan has genuinely disappeared from the project, the previous behaviour is preserved exactly and the selection is cleared.We considered simply disabling the “load a view” and “load a template” buttons during the refresh. We rejected it: it would have covered two of the four ways of choosing a plan, left the most common one — picking from the list — still broken, and locked you out for the whole refresh, which is longest on Azure DevOps Server, precisely where the problem was most visible.A dozen labels now follow the language you chose. Cancel and OK buttons in several dialogs, the History status column, the screen shown when a tab fails to render, and the three messages shown when TestPulse cannot start were written in French whatever your language; three screen-reader labels were written in English. All of them now follow your setting — including the start-up messages, which read your stored preference synchronously and stay translated even when it is the initialisation itself that failed.
​
2026-08-29
Excel exports came out in French whatever language you had selected.A customer working in English received a workbook entirely in French, on every one of its sheets — sheet names, column headers, KPI labels, even the Yes/No cells. Of the five export formats only Excel was affected, which is why the anomaly survived so long: PDF, HTML, Word and PowerPoint were already correct, so testing any of them showed nothing wrong.There were two distinct causes. The report workbook received your language and deliberately ignored it. The Repository hygiene workbook resolved its dictionary once, in French, when the module loaded — a value fixed at start-up, from which even the sheet names derived. Both now resolve the language for each export, and the history CSV export follows too, its column headers and its file name included.Nothing changes if you work in French: the workbook you receive is identical, cell for cell and sheet name for sheet name. GO/NO-GO, OK, NOK and N/A stay untranslated in both languages, as everywhere else in the product. Sheet names are now also cleaned of the characters Excel rejects and shortened to its 31-character limit before the file is built, so a translation can never make an export fail — and an existing shortened name is reproduced exactly as it has always been, never quietly “corrected”.
​
2026-08-19
The update notice showed raw asterisks and ran four lines long.The notice that announces a new version was reading the first entry of the What’s New panel word for word — a text written for documentation, not for a single line. Markdown syntax appeared literally on screen, and the sentence ran to whatever length its author had given it. Each release now carries a short, plain-text sentence written specifically for the notice. When none is available in your language, the notice simply shows no second line rather than falling back to the other language or to documentation text. The What’s New panel itself is unchanged.
​
2026-08-19
The Repository now offers only the tree-seeding source that actually works.Seeding used to ask you to choose between your Area Paths and your plan/suite hierarchy. On a real, plan-heavy project the plan/suite option produced a tree several times more crowded than the same project’s Area Paths, from far more requests — and not through an implementation defect: a tree with one parent per folder cannot structurally mirror plans that share their test cases, so making those requests faster would still have produced the same unusable tree. That option is gone, and the source picker with it: a single remaining option had nothing left to choose, so the dialog opens straight on the counted preview and confirmation. Nothing you already seeded from either source is migrated, purged or rewritten, and the Coverage Builder, the “used in” panel and the orphan scan keep working exactly as before.And the tree finally has room to breathe. A folder’s four row actions stay out of the way until you hover the row, select it, or reach it with the keyboard — their space is always held in reserve, so nothing jumps when they appear. A long folder name truncates to one line, with the full name a hover away. A draggable divider between the tree and the case list lets you choose how the width is split, adjustable with the arrow keys too, and remembered for you personally rather than for the whole project. With nothing selected, the tree takes the full width instead of leaving half the screen to an empty panel — and selecting a folder restores the width you chose, never resetting it.
​
2026-08-19
The hub now tells you when TestPulse itself has been updated.TestPulse updates automatically, and until now nothing on the product side ever said so. A small notice above the hub reports announces a new version, with a short summary and a link to What is new — shown only when the major or minor version changes, so a patch release stays silent. Closing it is per user: a colleague dismissing it never hides it for you, and it does not come back until the next meaningful version.It also stays quiet when it should. Opening TestPulse for the first time never claims an update happened, and reinstalling an older build on a server never announces one either.
​
2026-08-18
A closed exploratory session can now carry a verdict — and it deliberately counts for nothing.Passed, Failed or Blocked, chosen at closure, optional, nothing preselected: skip it and the session closes exactly as it did before. The verdict appears as its own badge in the hub, beside the status badge rather than in its place, and a new Verdict filter narrows the list — including down to sessions carrying none, which is a distinct answer from “all”. The same value lands as a tag on the tracking Task, so you can query it from Azure DevOps itself.Three limits, stated plainly because the vocabulary is borrowed from test outcomes and would otherwise suggest the opposite. The verdict is final once the session is closed. It never reaches the report indicators or the quality gate — a session marked Failed increments no failure count anywhere, by design and by test. And the tag on the Task is an informative mirror: if someone edits it by hand in Azure DevOps, the session document remains what TestPulse reads.
​
2026-08-18
The blur now shows you the blur.The annotation editor used to draw a dashed frame and apply the real blur only once you attached the capture — you were validating a mask you had never seen. The blurred region is now rendered live, by the very same painter that produces the final image, so what you check is what gets attached. The dashed frame survives as a drag indicator while the mouse button is held. Nothing changed about when the blur is baked: it is still destructive at attach time, and the original pixels still never leave your machine.And a session’s timeline is no longer append-only. Correct a note’s wording or its type, fix a caption, remove an entry you did not mean to keep — while the session is still active. Deleting removes the reference from your session; the attachment itself stays in Azure DevOps, and the confirmation says so rather than implying a cleanup TestPulse never performs. Entries tracing a real bug, task or test case cannot be edited or deleted at all — they exist in Azure DevOps and belong there. Neither can a capture already sent to one. Once a session is closed, nothing is editable.
​
2026-08-18
The hub now tells your own active session apart from a colleague’s — and stops promising a resume it couldn’t deliver.An active session has no tracking Task yet, so it read “Tester: not identified” with the same link whoever started it. Ownership is now settled by comparing account identifiers directly, matched against the identical value the session was stamped with at creation — never a display name, the exact mismatch that left the 2.57.0 filter silently inert. Three outcomes, never a boolean: your own session shows your name and offers to resume it; a colleague’s only opens the work item, since Azure DevOps restores a session solely to the account that started it; and when ownership can’t be determined, the link stays neutral rather than picking a side.A requirement’s exploratory history is no longer invisible from its own work item. Opening the Explore tab on a story explored three times used to say only “No active exploratory session” — true of the present, false of the past. Closed sessions are now listed there, each linking to its tracking Task, with the start form still right where it was. On the Test coverage tab, the depth analysis gains one informational line naming the count and pointing at the Explore tab — never a warning, and never touching the coverage pill: an exploratory session is not a test case, and crediting coverage for it would inflate a number nobody could defend.Screenshots can now say what they show. Mark a capture as a step to perform or an obtained result — at capture time, when you still remember why you took it, and editable afterwards from the timeline. Generating a test case then keeps the timeline’s own order: each note opens a step, and the captures following it attach to that step rather than to the work item at large. A capture marked as a result fills the step’s expected result with “See screen capture” and turns it into a validation step, the way Azure DevOps itself distinguishes the two. Sessions with nothing marked produce exactly the test case they did before.
​
2026-08-18
The hub’s “Discoveries” tile is retired — from the screen and from the consolidated PDF report alike.It summed the work items created from inside a session. A tester who logs the same findings straight into Azure DevOps by hand scored zero, so the number never measured what its name promised. Removed outright rather than relabelled to something accurate but still useless. A session count takes its place on screen — matching the rows actually listed, incomplete sessions included, so you can verify it by counting. The PDF’s synthesis table simply loses the row.An active session can now be reopened straight from the hub, through a link to its own work item where the Explore tab picks it back up.For that link to be reachable at all, sessions without a tracking Task — which is every active one, since the Task is only created at closure — are now exempt from the Tester filter. Without it, the default “my sessions” view introduced in 2.57.0 would have hidden the very sessions the link exists for. Every other filter still applies to them.
​
2026-08-18
The “Filtered to my sessions” default shipped the day before never actually applied.The hub read the account’s email, and compared it against tester names resolved from each session’s tracking Task. The installed SDK’s own typings are unambiguous — one field is the email/login, the other the display name — so no match was ever possible, and the filter stayed empty every time, indistinguishable from someone who genuinely had no session yet.One line changed. No fallback to the other field was added: an email is never a valid key here, and a fallback would have failed silently instead of leaving the filter empty, which is the correct behaviour when a name truly can’t be resolved.The regression was invisible to the tests because the mock carried the same wrong assumption as the code — a single field, holding a display name. It now carries both, distinct, so a test fails if the wrong one is ever read again.
​
2026-08-17
The Explore hub now opens on your own sessions instead of listing the whole project every time.At the reference client one Azure DevOps project spans every team, so opening the hub meant seeing everyone’s sessions and filtering down by hand. The Tester filter now pre-sets itself to your own resolved name — applied exactly once, the moment the metadata it depends on arrives, and never again: a one-time flag stops it creeping back after you remove it or pick someone else. No session resolved to your name yet, or no identity available: the filter starts empty, exactly as before, rather than active on a value matching nothing.A visible “Filtered to my sessions” chip sits next to the filters, removable in one click — never buried as a pre-selected value in a dropdown, which nobody would notice and which would leave you concluding that no one else explores.
This filter reduces noise; it grants no confidentiality. Exploratory sessions are stored at project scope, readable by anyone with access to the project regardless of Azure DevOps teams. The Privacy page now says so plainly.
​
2026-08-17
Closing an exploratory session no longer means going back to Azure DevOps to assign the Task it just created.A small dialog now opens right after the “End session” confirmation, offering two things: who the tracking Task goes to, and what state it starts in. The assignee field reuses the same identity search as the report’s contacts, and stays typable when that search isn’t available — on some on-premises setups it simply isn’t. The status list is read from your own work item type’s state categories, never from a hardcoded name: if your process says “Terminé”, that’s what you see. The Removed category is always excluded — offering “delete” as a closing status is a trap, and irreversible in some processes. When your process has no completed-category state at all, nothing is pre-selected rather than something guessed.There’s a Skip button, and it’s the part that mattered most. Skipping doesn’t produce a slightly different Task: it produces a byte-for-byte identical patch to the one built before this feature existed, asserted by a dedicated test. An optional step that quietly changes your data isn’t optional.If your process refuses the requested transition, the Task is still created and the session still closes exactly as before. A separate, non-blocking warning names that one failure — using Azure DevOps’ own message rather than a generic “update failed” — and the transition is never retried, because a workflow rule isn’t a network glitch.
​
2026-08-17
A Test Case created from an exploratory session read as “Tested By” its story instead of “Tests” it.Azure DevOps interprets a link from the point of view of the work item being patched — here, the Test Case. The relation now emitted makes it read the right way round. Existing links are not rewritten: only newly created ones change, and the in-product help says so, rather than leaving you to wonder why old and new work items disagree.Two other things about that same panel. Files dropped onto the session timeline had no checkbox at all — only captures were offered for attachment, even though the files had already uploaded and their URL was already known. The gap was in the panel’s own collection, not in what it built. Captures and files are now offered alike.And the panel is available after a session ends, not only while it’s running. Reopen the session’s tracking Task and the same gesture is there, reading the closed session back from storage. A piece that can’t be attached is now shown greyed out with the reason, instead of silently vanishing from the list.
​
2026-08-17
Generating a report on a whole test plan could crash on Azure DevOps Server — never on the cloud.Measured on a real on-premises instance: asking a batch of work items to skip dead ids doesn’t skip them there. It returns null in their place, and counts them. The cloud genuinely omits them, which is what the code assumed. Suites imported from older requirement-based plans carry orphaned requirement ids that no longer resolve; checking every child of an empty parent suite pulls the parent’s own orphaned ids into the batch, and that was enough to stop the whole report.Fixed at the source rather than where it happened to break, so none of that primitive’s twenty callers can receive a null whichever code path answers. Two more independent batches on the work item Coverage tab had the same latent flaw and were fixed with it. Nothing changes when every work item still exists — the overwhelming majority of cases, and the entirety of the cloud.Alongside it, traceability gained a “Requirement suites only” scope, next to “Include inactive plans”. By default it still combines requirement-based suites and the direct links carried by test cases, exactly as before. On a regression plan replayed for years, that second source can drag in links to long-closed stories that have nothing to do with the current campaign — the toggle leaves them out. The choice is remembered per project and changeable without leaving the report screen. A question mark next to it explains what each mode includes, and why the quality score redistributes its coverage weight when nothing is left to measure.
​
2026-08-14
Every run shown in a report is now one click away from the execution that produced it.The Results table carried a “Run” column that had always shown a dash: the link was simply never wired up. Full History showed a plain run number, added the day before, that you could read but not follow. Both now show the same thing — the run number as a link — and both open the exact result, not just the run it belonged to. When the result identifier isn’t available, the link falls back to the run itself rather than inventing one.Those links now leave through the same door as everywhere else in the product. On Azure DevOps Server, the extension runs inside a sandboxed frame where an ordinary new-tab link opens a blank page; the report was still using one in three places, including the failing-tests-without-a-defect panel. All three now delegate to the host, so a new tab opens on-premises as it does in the cloud. A right-click still works as you’d expect.
​
2026-08-14
Full History now tells you which run each row came from — and a report survives a side-by-side check against Azure DevOps.Opening the same test case in both tools could show nine rows here and five there, with no way to explain the gap. Both were right: Azure DevOps hides runs that published no outcome, TestPulse keeps them. But nothing in the report let you establish that, and a number you can’t reconstruct is a number you have to take on faith. Each row now carries its run number, and hovering a None status explains what it means — the run exists, Azure DevOps published no outcome for that case.The Flaky tests tab count now follows the active filter, matching Results and Full History. Filtering to a single test case no longer leaves it announcing the whole plan.Behind the scenes, the completeness safeguard introduced across the previous releases has nothing left to watch: every collection this product reads has now been measured against a live server. Four were paginated, three were shown to have no truncation mechanism at all. The safeguard stays in place for whatever gets added next.
​
2026-08-13
A report’s execution history could collapse to a single run, hiding the very flaky-test fix shipped hours earlier.Azure DevOps numbers test results per run, not globally: four runs of the same 300 cases all carry the identifiers 100000 to 100299. The report used that identifier alone to avoid listing the current result twice — which silently removed every historical result instead. On a plan with 1200 results, the history tab showed 300 and every case reported a single run.Deduplication now keys on the run and the result together. History returns in full, and the instability calculation finally has something to work with.
​
2026-08-13
A test executed once could be reported as 100% unstable.Instability was computed over every recorded outcome, including test points that had never been executed. A single run preceded by one of those produced a “None → Passed” transition — counted as a flip, on a test that had never varied. On a plan replayed with a blocked pass, all 300 cases came out unstable.Only real executions now count — Passed, Failed, Blocked, Inconclusive. Blocked stays in: the tester tried and recorded an obstacle. A case needs two genuine executions before instability means anything.The calculation itself lived in five places, two of which used a hard-coded threshold instead of the one configured in Settings — so the same report could call a test unstable in its PDF and stable in its notification. There is now one implementation, one threshold, and a guard that fails if a sixth copy appears.
​
2026-08-13
The in-product documentation no longer shows internal development codes.The help content carried 198 references to internal feature identifiers, several in section titles a reader sees first — “Generate a plan from a folder (F-53)”. They mean nothing outside the codebase and made the documentation read like an internal draft left in production. All of them are gone, along with internal release-wave labels, and a guard now fails if any reappear.The help also documents the completeness guarantee on execution outcomes, alongside the one on suites.
​
2026-08-13
The pass rate could have been computed on partial data — the endpoint carrying every test case’s outcome was fetched in a single call, with no way of knowing whether it had returned everything.A truncation there wouldn’t have hidden a row you’d notice missing: it would have produced a wrong number, indistinguishable from a correct one. A probe run against both Azure DevOps Services and an on-premises Server 2022.1 instance found the paging parameters honoured identically on both, and an implicit server ceiling that exists but is unspecified. TestPulse no longer depends on it — outcomes are fetched page by page until the collection is exhausted, which stays correct whatever that ceiling turns out to be, and stays correct if Azure DevOps changes it.Suites holding fewer than 200 test cases — the overwhelming majority — still make exactly one round-trip, so nothing loads slower than before. And if outcomes still can’t be retrieved in full, a small non-blocking banner says so on the report, with a distinct message depending on whether some are known to be missing or exhaustivity simply couldn’t be verified. Never inside an export.
​
2026-08-13
The completeness warning introduced the day before could claim suites were missing when TestPulse had no way of knowing — and stay silent when nothing had been retrieved at all.Both now read correctly. “Suites are missing” appears only when a loss is actually confirmed; “completeness could not be verified” appears when exhaustivity is simply unknown; and a plan whose suites couldn’t be retrieved at all is never presented as an empty plan that was checked. Two different situations, two different messages, never conflated — because a report is only worth what its weakest claim is worth.
​
2026-08-13
A test plan with more than 200 suites silently lost everything past the 200th — and showed the rest in the wrong order, with a broken hierarchy.On a 426-suite plan, 227 suites were absent and nothing said so: the suite counter read as though everything was there. Suites were also sorted alphabetically instead of the order you arranged them in Azure Test Plans, and hiding empty suites detached their children and promoted them to the top level.The three are fixed together. Suites now load exhaustively, in Azure Test Plans’ own display order, with their native hierarchy — an empty parent holding a visible child is never dropped, whatever your display filters. Loading a large plan stays as fast as before despite fetching far more than it used to.Three additions come with it: empty suites are shown by default (an explicit choice to hide them is always remembered), a filter on suite names that keeps every ancestor of a match visible so you never lose your place in the tree, and searching a test plan by its numeric ID in the existing search field.
​
2026-08-12
The Explore tab on a work item no longer fails to load on Azure DevOps Server 2022.1.Since 2.46.0, opening it on-premises showed “TestPulse failed to load” and nothing else. On that platform the work-item tab runs inside a sandboxed frame where browser storage is unavailable, and a single unguarded read of it stopped the tab before it could even start. Every other module kept working, which is exactly what made it hard to spot.Your report colour and logo now reach that tab on-premises as well, synced through your Azure DevOps preferences rather than the storage that frame can’t use. The tab renders immediately with default branding, then applies yours a moment later; if it can’t be retrieved, a discreet notice says so rather than letting you export in the wrong colours without knowing.A custom logo too large to sync quickly is now shrunk automatically — you’re told when that happens — and rejected with a clear message if it’s still too large after reduction, keeping your previous logo rather than losing it.
​
2026-07-31
Exploratory sessions: a deleted work item no longer blanks the rest of the list.Deleting a single work item made every other group in the Explore tab lose its title, its type and its tester name at once — Azure DevOps rejects a whole batch read as soon as one identifier no longer exists, and the tab fell back to showing nothing rather than showing the rest. Dead identifiers are now omitted, and every work item that still exists resolves normally. The same protection was applied to the coverage batches, which carried the same latent flaw.Two filter fixes ship alongside. Each option in a filter now carries its own result count instead of repeating the same generic total on every entry. And the area path and iteration path filters now match sub-paths: picking a root brings back everything underneath it, the way Azure DevOps itself treats these paths — while a path that merely starts with the same letters is never caught by mistake.
​
2026-07-31
Exploratory sessions: only true values, and reports in your own branding.A session left open showed NaN min. A tester appeared as a raw identity descriptor rather than a name. And an indicator announcing covered user stories was in fact counting every kind of work item, including the archive Tasks TestPulse creates itself — a figure that said something other than what it measured. All three are fixed: the tester name is recovered from the archived Task when there is one and stays deliberately neutral when there is none, archive Tasks are marked as such and excluded from coverage, and the indicator is renamed honestly when the work item types cannot be determined.Total effort disappears, per-session duration stays. A session left open overnight produces a duration that is arithmetically exact and practically meaningless; summed across a scope, it made the figure untrustworthy. Rather than silently correct the data, the aggregate is gone — the aggregated report now counts sessions by area and by iteration, which no unclosed session can distort. The duration of each individual session remains next to its charter, where a human can judge it.Finally, exploratory reports follow the branding you configured in Settings — header and footer label, theme colour, cover page logo — instead of the tool’s own colours, and every export from the hub opens a dialog with a pre-filled title you can accept or rewrite.
​
2026-07-31
Exploratory sessions: a readable list, and the tab moves up.The first version of the hub tab merged a work item and its sessions into a single row: a story explored twice showed two status badges side by side, with no way to tell which was which, and no way to act on either. Groups now expand into one row per session — status, charter, tester, duration, counts, link to the archived Task — and each session holding at least one entry offers its own Export session button. Statuses carry a colour and a distinct icon, so the list stays readable in dark mode and for colour-blind readers.The group row itself became informative — session count, cumulative activity, last activity date — with a conventional chevron replacing the ambiguous plus sign. The scope indicators moved to the top in legible figures instead of grey chips indistinguishable from filters, and the “counters may be stale” notice only appears when the scope actually contains an active session. Explore moves to second position in the hub, right after Report.
​
2026-07-31
Exploratory sessions: a hub tab to find every session of a project, and reports worth sharing.Until now an exploratory session was only reachable from the work item it was run on — fine when you remember which story, useless when the question is what has actually been explored on this project? A new Explore tab in the hub lists every session of the project, grouped by work item, with filters on area path, iteration path, campaign tag, tester and period, plus a switch for archived sessions. The tab is strictly read-only: it reads and exports, it never writes.Older sessions leave the default view beyond a threshold — archived for display only. TestPulse never deletes a session; the switch brings them back and the real total is always shown.Reports were rebuilt on the same foundations as the rest of TestPulse: the session report now carries the cover page and layout of every other report instead of its own separate styling, and a new aggregated scope report covers a whole filtered scope — summary, sessions by area and by iteration, a section per work item, an appendix. An exploratory report deliberately shows no pass rate and no execution verdict: exploratory testing has neither, and displaying structural zeros would have been misleading. Its indicators are coverage and discoveries.Behind the scenes, session storage was rebuilt to hold a project’s full history without reading everything on every visit, and existing sessions are migrated without loss — nothing is deleted, and a session whose close had previously failed is flagged rather than silently reinvented. On the work item form, the Explore tab adopts the TestPulse identity, inherits Area and Iteration from the story, and restores a session reliably after a page reload.
​
2026-07-30
Repository Hygiene diagnostics.A test repository ages badly: cases get duplicated between teams that never spoke to each other, others are created and never written, some are planned and never executed — and nothing in Azure DevOps tells you. A third toggle, Hygiene, joins Tree view and Flat view and produces a strictly read-only diagnosis: TestPulse reports, it never repairs. No deletion, no merge, no automatic cleanup, not even on explicit request — the action wording is always “to review”, never an imperative verb. These are indicators to examine, never a verdict: you decide.Five findings are immediate and cost no extra Azure DevOps call, because they work on data the tab has already loaded: near-duplicate cases (title and steps strictly identical once normalized — a mere formatting difference does not create a duplicate), cases sharing a title but with different steps (often a legitimate variant, worth a quick check), empty shells (neither steps nor description), dead references (cases filed in the TestPulse tree but deleted on the Azure DevOps side) and empty folders. Three further findings require reading plans, suites and results: they live in a Plan analysis section behind their own button, with their cost stated before you start. The analysis never runs on its own.Each finding opens in a dialog that states its detection criterion in plain language — challenging a result does not require opening the documentation. Duplicates are grouped there (the decision is made group by group, not case by case), every case links out to Azure DevOps in a new tab, and “View in flat view” switches to a visible, reversible filter. When a finding could not be evaluated, it says so — never a zero that would look like a healthy repository. Everything exports to Excel: one summary sheet plus one sheet per finding, and the export always carries every row, including those the screen does not show. The result is deliberately ephemeral: coming back to the tab starts from “no analysis run”, never from a stale diagnosis.
​
2026-07-29
Repository tree: readability and remembered collapse state.The Repository tree was complete but austere: bare text, no way to collapse a branch, and depth that became unreadable past two levels. Every folder now carries a three-state icon — grey when collapsed, teal when expanded or selected — and a chevron separate from the icon, so you can collapse without risking a selection. Indentation guides one pixel wide tie each child visually to its parent, case counts move to a monospaced font, and every row shares the same height.More importantly, branches collapse, by mouse and by keyboard (right and left arrows), and the state is remembered per user: you find your tree exactly as you left it, without collapsing the same branches every time you open it. The tree opens where the action happens — selecting a folder expands its parents, creating a subfolder inside a collapsed folder expands it. And a collapsed folder remains a valid drop target: hovering it during a drag opens it after a moment. By default the tree shows collapsed, like a file explorer.“Unclassified” and “Not in any plan” are finally distinguishable from real folders — neutral icons, italic labels, a separator — and join the tree to form a single coherent keyboard navigation instead of three isolated islands. “Not in any plan” shows no count until a scan has run: the absence of a scan does not mean zero. The “Move to…” menu now shows each folder’s full path, so two folders with the same name can no longer be confused.
​
2026-07-28
Guided plan generation, live progress, and honest retry.Generating a test plan from a folder is now a guided flow. A step indicator shows where you are (three steps for a new plan, two for an existing target), and a Back button lets you revise earlier choices without losing what you already typed. The plan name is pre-filled from the folder, and your last Area/Iteration Path and “reproduce the tree” settings are remembered for next time. Before anything is written, a plain-language summary spells out exactly what will be created, alongside a colour-and-label breakdown of what is created, reused, or skipped. During the write, a live progress indicator (“Creating suite 2/4…”) replaces the old freeze on large folders. Afterwards, the result screen clearly separates full success from partial failure with real counts, gives you a direct link to the plan, and — if some writes failed — a Retry button that re-runs the flow and always goes back through the preview before writing again. No new Azure DevOps permissions; still read-only apart from the plan creation you confirm.
​
2026-07-27
A brand-new visual identity, unified across every tab.TestPulse gets an identity of its own: a teal palette, Public Sans and JetBrains Mono typography, and eight tabs that are finally visually consistent. The fonts are bundled into the extension — the interface renders identically even on an air-gapped on-premises instance, with no external font download. This is a purely visual refresh: behaviour, navigation, data and Azure DevOps calls are strictly unchanged. A dark theme is prepared under the hood but not yet enabled.
​
2026-07-27
Repository — generate an Azure DevOps test plan from a folder.Turn any Repository folder into real ADO plan and suites, the way Xray’s context actions do. Three destinations: a new plan (with Area and Iteration Path, optionally mirroring the folder tree into static suites), an existing plan, or an existing static suite — its suite tree loads on demand, and requirement-based suites are shown but not selectable since they populate by query. Nothing is written until you confirm a counted preview: plans and suites to create, suites reused by name, cases to add after de-duplication, duplicates skipped. The result is a snapshot, not a mirror — no later resync. This is the first Repository capability that writes to Azure DevOps, always explicit and previewed; it reuses the already-declared plan-creation permission, with no new scope.
​
2026-07-25
Repository, now usable at scale.
  • Auto-seed the folder tree from your Area Paths or your plan/suite hierarchy — additive and idempotent (existing folders reused by name, nothing renamed or moved), with a counted preview before any change.
  • Bulk operations: tick cases by row, “select all” bounded to the visible filtered results, then assign or remove a whole batch in a single atomic write with an exact report.
  • Readability: descendant-inclusive case counts per folder, a flat view listing every filed case with its full folder path, and the ADO-orphans node renamed “Not in any plan” to avoid confusion with “unfiled”.
  • Manual ordering: reorder cases within a folder by drag & drop or keyboard; sort by id, title or manual — a manual order is never overwritten silently.
​
2026-07-23
Repository — field fixes (cloud).A genuine WIQL failure now surfaces an error banner instead of a silent empty screen; the tree no longer looks like it vanished when the test-case universe read fails (the two reads are now independent); and WIT URL resolution falls back to an already-resolved base on the cloud organizations where it could otherwise fail with no recourse.
​
2026-07-23
Repository — reliability fixes + atomic storage.Fixes the empty tree on-premises, the re-scan error on cloud, the WIQL 403 / empty tab on cloud, and hidden read failures that now surface as an error banner. Storage moves to a single atomic document (one read, one write per change), and existing repositories are migrated automatically and without loss on first load.
​
2026-07-22
A new “Repository” tab.Organize and find your Azure DevOps test cases in a free, project-shared folder tree, Xray-style, without ever modifying ADO data — the Repository stores references, never copies. Create, rename, move and delete folders at any depth (native drag & drop), file a case with “Move to…” (keyboard equivalent throughout), and search by title, id or tag across the whole project. An “Unfiled” node is the set of cases not yet filed, always recomputed. Expand a case to see “Used in N location(s)” (plan › suite), and run an explicit orphan scan — never automatic — to surface cases that live in no plan. Read-only, no new permission, no new dependency.
​
2026-07-21
Exploratory sessions — reliable close + PDF report.Closing a session is now reliable — no more sessions stuck “active” after a restore, and Azure DevOps errors are shown clearly instead of a raw object. A finished session can be exported as a signed PDF report (charter, full timeline, created work items, embedded screenshots, tester signature on every page) in French or English; a second button exports all closed sessions of a story in a single PDF. Screenshots are embedded when possible and gracefully listed by name otherwise — the report never breaks.
​
2026-07-20
Work-item links open correctly on-premises.On the Test coverage and Explore tabs, external links (run, test case, bug, plan) no longer open a blank page on ADO Server 2022.1 — they now go through the host navigation service. The “Last run” column keeps a single link per row, and plan navigation stays at the Scope level, now suite-aware so it never lands on an empty plan page. No new scope, no write.
​
2026-07-18
Configuration-aware coverage & change detail on the work item.
  • The “Last run” now follows the story’s own configuration. When one test case covers several sibling stories that differ only by test configuration (Italy / Singapore / Korea…), the Test coverage tab no longer shows a sibling’s more recent run: it resolves the last execution from this story’s own requirement-based suite. The “Last run” links open the exact result, and each row can open the exact executed suite instead of a blank plan page. Scope options are labelled plan · configuration when a configuration is known. Stories without a requirement-based suite keep the previous behaviour.
  • “Modified after last run” now shows what changed. The badge gains a Show detail button: expanding it lists the business fields changed since that run — Acceptance criteria, Description, State, Priority, Iteration, Tags, Title — as before → after, with added wording highlighted on rich fields, a feeds depth analysis marker on Acceptance criteria / Description, and any attachments added or removed. The revision read is lazy and opt-in — nothing is fetched until you expand.
Read-only throughout.
​
2026-07-16
Exploratory sessions — a new “Explore” tab on the work item.Run an exploratory testing session from the user story itself: a pre-filled charter, timestamped notes, and Ctrl+V to paste a capture of any screen or application (desktop apps included). Each capture opens in an annotation editor — arrow, rectangle, text, highlighter and blur to mask sensitive data — and is attached to Azure DevOps only when you validate it. From the session, create a bug, task or test case with repro steps generated from your notes; ending the session archives it as a Task tagged exploratory-session, carrying the full report and every relation, natively queryable. Resilient by design: debounced autosave, automatic restore, non-destructive retry. Requires the new work-items write permission — an administrator must re-approve the extension after this update.
​
2026-07-08
Suite × configuration grid in exports: now opt-in.The grid shipped in v2.30.0 was rendered in PDF and Word exports with no way to turn it off. It is now a first-class export section, disabled by default: enable it under Settings → Report sections → Suite × configuration grid. The toggle is independent from the Results table section, and the grid still auto-hides when the plan declares no configurations — even when enabled. The Report tab, its badge and the summary alert are unchanged. Learn more.
​
2026-07-04
Insights pack. Four deterministic signals, each in its host screen — no new screen, no new permission.
  • Stale coverage (Requirement Drift) — requirements modified after the last run of their linked tests, with the plain-spoken counter “N Passed no longer prove anything”, the changed field, filter chips and a project option to ignore title-only changes. A “Modified after last run” badge on the work item tab, a Stale column in the PDF/Word traceability.
  • What to run today (Cockpit) — the remaining points ranked by a transparent weighted score, three fixed profiles (Strict / Standard / Onboarding) stored at project level, a per-row score breakdown and one-click execute links.
  • Suite × Configuration matrix (Report) — the full suites × configurations grid with assumed gaps, gap nudges that only appear when gaps exist, shared reversible not applicable markings, and the grid in PDF/Word exports.
  • Remaining effort (Cockpit) — tester-days from the median of observed durations (P25–P75 range, per-suite medians), working-days finish date, two simulation sliders, assumptions always displayed — an estimate, not a commitment.
​
2026-07-03
  • Coverage plan insights & execute links — with the Planning scan on, the Coverage Builder shows per requirement where its tests are planned (Plans column), expandable to each plan/suite with a Run in Azure DevOps link and a lazily-fetched n/m execution progress. No extra API call at table load.
  • Every application plan link now opens the execute view instead of the composition view.
  • Cockpit — readable & honest burndown — dated axis, legend and markers; the projection pauses after 14 days without execution; the progress panel always shows suites and configs; honest states replace any blank chart.
​
2026-07-02
  • Cockpit on-premises fixes — execution dates are now resolved on servers that don’t expose them through the newer API (with a read-only fallback), and a completed campaign shows its real finish date instead of an empty chart. Also improves the Last run column and freshness signals on-premises.
​
2026-07-02
  • Coverage Builder — under-counted coverage fixed — Tested By links are now resolved in both directions, so a story visibly linked to several test cases no longer shows as a false gap on Azure DevOps Server.
​
2026-07-02
  • Coverage Builder — Planning scan no longer loops on large repositories — the scan resolves planning per test case (bounded, deduplicated, with short timeouts) instead of enumerating every plan and suite of the collection. Same semantics, usable at enterprise scale.
​
2026-07-02
  • Link to this online documentation added to the extension footer and docs badge.
​
2026-07-02
  • Execution Cockpit — a new hub tab: a per-plan execution burndown in test points (actual from daily snapshots, rebased ideal, pace projection), an honestly tracked moving perimeter, behind-pace suites/configs, a local target when the plan has no end date, and a closing nudge for stalled campaigns. Read-only; snapshots live in Extension Data — nothing leaves your tenant.
​
2026-07-02
  • Test coverage tab — navigable — all five columns sort (persisted per work item), the Last run cell links to the run, and a scoped plan links straight to its execution view.
​
2026-07-01
  • Test coverage tab — the scope selector shows whenever the story is covered, and each test case ID is clickable.
​
2026-07-01
  • On-premises fix — results on the Test coverage tab resolved correctly on Azure DevOps Server (tests no longer all shown as Not run).
​
2026-07-01
  • Execution verdict banner on the Test coverage tab — Passed / Not OK / Not Run / Not covered, with strict precedence, recomputed instantly with the scope.
​
2026-07-01
  • Coverage scope selector on the Test coverage tab — frame the pass/fail on Latest (all plans) or a specific plan, remembered per work item, switched in memory with no new read.
​
Report generation and the five exports, Epic→US→TC→Bug traceability, the Quality Gate (A–E grade, GO/NO-GO verdict, profiles and risk-based weighting), the dashboard widget, Requirement Drift, the Coverage Builder, coverage depth, imports, notifications, scheduling and much more — see the full changelog on GitHub.