What it does

The first step of "Package and test": confirm that the agents, skills, connectors and MCP-based capabilities you've built work together in a development or test environment before you create the package. It's integration testing of components, not testing of the final artefact.

Key facts

• Sequence: integrate capabilities, create the package, validate and test the package, then evaluate agent quality if required. This page covers only the first.
• Per-component checks. Declarative agent: identity, instructions, starters, knowledge, responses, boundaries. Skill: discovery or attachment, inputs, outputs, failures. Connector: authentication, schema, retrieval, freshness, security trimming, updates, deletions. MCP server: tool discovery, authentication, structured results, confirmations, errors, timeouts, logs.
• Test end-to-end scenarios from the solution brief, not just features: correct agent handles the request, correct skill or tool is selected, authentication and consent behave, inputs and results are right, the response is understandable, and logs identify the components involved.
• In Microsoft 365 Copilot, enter -developer on in Copilot Chat to inspect agent metadata and action selection; -developer off when finished.
• Work IQ DevUI (preview) and the WIQD Work IQ commands (experimental) test a deployed declarative agent. They don't replace package validation or testing the installed plugin.
• Readiness to package means: every component built or reused, working alone and together, identities and connections available, failure behaviour implemented, ownership and versions documented, no blocker left.

When to use / skip

Use it before every package build, even for a small plugin. Skip nothing, but keep it proportionate: a single-component plugin needs the scenario tests, not a test plan.

Configuration decisions

• Test identities, permissions, consent and connections that mirror production, with representative data free of production secrets.
• The record for each scenario: environment, versions, expected and actual result, evidence, owner and the accept-or-fix decision.
• Which debug route per component: Copilot Studio, Agents Toolkit, local MCP and API plugin debugging, or DevUI.

Gotchas

• Silent fallback isn't success. The user and support team need to see what failed and what to do.
• Test the failure cases deliberately: expired authentication, denied consent, throttling, timeouts, malformed or empty results, and requests for data outside the user's permissions.
• Passing here says nothing about the package. A missing manifest reference only shows up after packaging.
• Connector checks include security trimming and deletions. Fresh-looking results can still be stale or over-shared.

Consultant notes

• Test with a least-privileged account as well as the builder's. Everything works for the person who built it.
• Write failure scenarios into UAT scripts, not just happy paths. Business testers rarely invent an expired token.
• Keep the evidence table. When the package author or the admin asks "which version did you test", it's the only answer that survives a change of staff.
• Don't let the preview debug tools become the sign-off. They help you find faults; the release gate is the installed, packaged artefact in each claimed experience.

---

Review when the Package and test guidance, DevUI or the Work IQ test commands change status.