Mobile App Proctoring Support: Development and Testing Plan (7 Sprints)
Effort in person-days | Team: 2 Developers + 1 QA | 7 sprints of 2 weeks (14 weeks) | Status: Draft for review |
| Plan on a page. 7 sprints of 2 weeks (14 weeks, about one quarter). Development 106 days + QA 56 days = 162 person-days; with contingency (Dev 15%, QA 10%) 184 person-days. Utilisation: developers 87%, QA 89%. To fit, about 8.5 dev days and 3 QA days of lower-priority work are deferred to the next phase (section 4). |
| Section | Dev (days) | QA (days) | Total (days) | Share | Covers |
|---|
| A. Analysis, Design and Planning | 8 | 3.5 | 11.5 | 7% | Analysis, contract, design, test strategy, environments |
| B. Mobile WebView Support (Criterion a) | 36 | 15 | 51 | 31% | Criterion a: assessments on mobile webview |
| C. Deep Linking (Criterion b) | 20 | 9.5 | 29.5 | 18% | Criterion b: deep links for Android and iOS |
| D. Non-Functional Requirements (NFR) | 18.5 | 12 | 30.5 | 19% | NFR: security, performance, reliability, compatibility |
| E. Integrated Testing and Release (QA led, spans all features) | 13.5 | 14.5 | 28 | 17% | End to end testing, regression, defects, UAT, release |
| F. Adhoc Support and Documentation (Criterion c) | 10 | 1.5 | 11.5 | 7% | Criterion c: adhoc support and documentation |
| Subtotal | 106 | 56 | 162 | 100% | |
| Contingency (Dev 15%, QA 10%) | 16 | 6 | 22 | | Legacy code unknowns and app team dependencies |
| Grand total | 122 | 62 | 184 | | |
Why 7 sprints. The earlier full-scope estimate (Dev 139.5, QA 77 with contingency) needs 8 sprints. Fitting a quarter means choosing the sprint count and the scope together:
| Option | Dev / QA capacity (days) | What fits | Assessment |
|---|
| 6 sprints (12 weeks) | 120 / 60 | About 105 dev and 53 QA days of work fit at 88% load. Needs roughly 17 dev and 9 QA days more scope deferred (for example reporting, in-app browser handling, observability) and thinner testing. | Not recommended: test depth and defect time are too thin for a proctored product |
| 7 sprints (14 weeks) | 140 / 70 | Planned scope in this document: 122 dev and 62 QA days with contingency. | Recommended. Slightly over a 13 week calendar quarter, so start 1 week early or accept Sprint 7 closing in the first week of next quarter |
| 8 sprints (16 weeks) | 160 / 80 | Full scope from the earlier estimate: 139.5 dev and 77 QA days with contingency, including deferred items. | Lowest scope risk, but QA runs near 96% load and the plan extends beyond the quarter |
| 2. Scope, Assumptions and Dependencies |
| In scope (this quarter) | Out of scope |
|---|
- Changes in our assessment application and backend to run inside the mobile webview
- Launch token, session, attempt and proctoring handshake APIs
- Deep link creation, validation, hosted verification files and fallbacks
- NFR changes listed in section D
- Testing of all of the above, including end to end with the app team build
- Adhoc support for the app team and documentation
| - Development or changes in the mobile webview shell (another team)
- Development or changes in the mobile app, including its proctoring logic (another team)
- App side deep link handling: intent filters, associated domains, entitlements
- Publishing the app to Play Store or App Store
- Changes to the desktop proctoring experience, apart from regression protection
- Items deferred to the next phase (section 4)
|
Assumptions
- Dev 1 mainly covers backend, security and integration. Dev 2 mainly covers web pages, deep link routing and compatibility. Days are person-days of focused work. Task effort includes unit tests.
- The app team agrees the launch contract by the end of Sprint 1 and provides a working test build (TestFlight and Android internal track) from the start of Sprint 2.
- Only the assessment-taking pages need mobile changes. Admin and reporting screens change only where B9 requires it.
- Real Android and iOS devices (at least 6 across OS versions) or a device farm are available to QA from Sprint 1.
- A domain we control is available for deep links, with HTTPS and the ability to host verification files at the root.
- Each sprint has 10 working days per person: capacity 20 dev days and 10 QA days. Leave and holidays are absorbed by the headroom in section 6.
- The NFR targets in section 5 are proposals; business confirms them by the end of Sprint 1.
- Each task is built and tested in the sprint shown in the Sprint column; QA tests items as soon as they are delivered.
| 3. Sprint Plan (7 sprints x 2 weeks) |
| Sprint | Weeks | Focus and milestone | Tasks | Dev planned / capacity | QA planned / capacity | Dev headroom | QA headroom |
|---|
| Sprint 1 | 1-2 | Foundation. Contract frozen, environments ready, launch token and link design done | A1, A2, A3, A4, A5, B1, C1, F1 | 15 / 20 | 5.6 / 10 | 5 | 4.4 |
| Sprint 2 | 3-4 | Core launch and handshake. First launch from the app test build into the webview; proctoring handshake working in dev | B2, B3, B4, C2, F1 | 17 / 20 | 7.1 / 10 | 3 | 2.9 |
| Sprint 3 | 5-6 | Events, deep link routing and automation. Deep link opens the app on both Android and iOS; API automation running in the pipeline | B6, B8, B10, C3, C4, C5, D5, E1, E4, F1 | 17.2 / 20 | 8.8 / 10 | 2.8 | 1.2 |
| Sprint 4 | 7-8 | Mobile pages, resume and security. A full assessment can be completed in the webview, including resume after interruption | B5, B7, C6, D1, E4, F1 | 18.1 / 20 | 7.9 / 10 | 1.9 | 2.1 |
| Sprint 5 | 9-10 | Links, reporting, reliability and compatibility. Feature complete; invitations carry deep links; device matrix executed | B9, C7, C8, D3, D4, E4, F1 | 16.4 / 20 | 9 / 10 | 3.6 | 1 |
| Sprint 6 | 11-12 | Performance, in-app browsers and E2E cycle 1. Load targets met; end to end and first regression on real devices; code freeze except defects | C9, D2, E2, E3, E4, F1, F2 | 11.3 / 20 | 9.7 / 10 | 8.7 | 0.3 |
| Sprint 7 | 13-14 | E2E cycle 2, UAT and release. Second regression, UAT sign-off, rollout and go-live | D6, D7, E2, E3, E4, E5, E6, F1, F2 | 11 / 20 | 7.6 / 10 | 9 | 2.4 |
| Total | 106 / 140 | 56 / 70 | 34 | 14 |
The headroom (34 dev days, 14 QA days) covers contingency (16 dev, 6 QA) plus leave, holidays and meetings. Sprints 6 and 7 deliberately carry less planned feature work so defects, UAT and rework can land there. Dev planned effort includes defect fixing (E4) and adhoc support (F1), spread across sprints.
| 4. Deferred to the Next Phase |
These items were in the earlier 17-week estimate. They are not part of this quarter’s plan. Deferring them is what lets the plan fit in 7 sprints with a realistic load.
| Deferred item | Reason | Dev (days) | QA (days) |
|---|
| Deep link click and open tracking (created, clicked, opened app, fell back to store) | Useful for support and reporting; not needed for launch | 1.5 | 0.5 |
| Accessibility and small screen usability checks (font scaling, zoom, contrast, tap targets) | Basic responsive fixes remain in B5; the formal accessibility pass moves out | 1.5 | 1 |
| Full reviewer and export enhancements for mobile attempts | B9 keeps data capture and basic view; exports and richer reports move out | 1.5 | 0.5 |
| Hypercare after go-live (first 2 weeks): monitoring, triage, hotfixes | Falls after the quarter; plan as support effort in the next phase | 4 | 1 |
| Total deferred | 8.5 | 3 |
What changed compared with the 17-week estimate
| Section | Earlier (Dev + QA) | Now (Dev + QA) | Change | Main reason |
|---|
| A. Analysis, Design and Planning | 12.5 | 11.5 | -1 | Test strategy and environment effort trimmed |
| B. Mobile WebView Support (Criterion a) | 56 | 51 | -5 | Reporting scope reduced; test effort trimmed on lower-risk items |
| C. Deep Linking (Criterion b) | 35 | 29.5 | -5.5 | Click tracking deferred; test effort trimmed |
| D. Non-Functional Requirements (NFR) | 40 | 30.5 | -9.5 | Accessibility deferred; scalability merged into performance; desktop compatibility moved into regression |
| E. Integrated Testing and Release (QA led, spans all features) | 30.5 | 28 | -2.5 | Defect fixing trimmed to about 7 percent; regression and UAT scoped tighter |
| F. Adhoc Support and Documentation (Criterion c) | 17.5 | 11.5 | -6 | Hypercare moved after the quarter |
| Subtotal (before contingency) | 191.5 | 162 | -29.5 | |
| Trade-off to be aware of. Part of the saving comes from thinner test effort on lower-risk items, not only from removed scope. Test depth on the high-risk areas (launch token, proctoring handshake, resume, deep links, security, end to end on devices) is kept. |
| 5. Detailed Estimates by Functionality |
Each table shows the task, owner, sprint, development effort, the matching QA activity and the QA effort. All figures are person-days. S1 to S7 are sprint numbers.
| A. Analysis, Design and Planning |
Understand what the current desktop assessment and proctoring flow assumes, agree the contract with the app team, and prepare the test approach and environments.
| ID | Task and scope | Owner | Sprint | Dev (days) | QA activity | QA (days) | Total (days) |
|---|
| A1 | Gap analysis of the current assessment flow for mobile webview: login, session, timers, question types, uploads, proctoring hooks and desktop-only assumptions | Dev 1 + Dev 2 | S1 | 2 | Review findings and identify test scenarios | 0.5 | 2.5 |
| A2 | Define the launch contract with the app team: launch URL and parameters, token format, mode flag, events and callbacks, error codes, versioning | Dev 1 | S1 | 3 | Review contract and derive contract tests | 0.5 | 3.5 |
| A3 | High level and low level design for launch, proctoring handshake and deep link service; design review with the app team | Dev 1 + Dev 2 | S1 | 2 | Not applicable | 0 | 2 |
| A4 | Test strategy, test plan and scenario matrix (functional, deep link, NFR, regression), traceable to requirements | QA | S1 | 0 | Prepare and review with team | 1.5 | 1.5 |
| A5 | Set up Dev, QA and UAT environments, test data, test candidates and assessments, emulators and real device pool, domain for deep links | Dev 2 + QA | S1 | 1 | Verify environments and arrange devices | 1 | 2 |
| Section total | 8 | | 3.5 | 11.5 |
| B. Mobile WebView Support (Criterion a) |
Changes in our assessment application so that a proctored assessment runs correctly inside the mobile webview. The webview shell and the mobile app are built by another team and are not in this estimate.
| ID | Task and scope | Owner | Sprint | Dev (days) | QA activity | QA (days) | Total (days) |
|---|
| B1 | Webview launch mode and secure launch token: accept a one-time, short-lived token from the app, validate it, create the candidate session without a second login, reject replays | Dev 1 | S1 | 4 | Valid, expired, reused and tampered token scenarios; API tests | 1.5 | 5.5 |
| B2 | Session and cookie handling inside the webview: SameSite and third-party cookie rules, storage fallback, session timeout, keep-alive when the app is in the background | Dev 1 | S2 | 3 | Session persistence, timeout and background/foreground tests on Android and iOS | 1 | 4 |
| B3 | Proctoring mode switch: when launched from the app, turn off browser based proctoring (camera, mic, screen, full-screen and tab-switch checks) so it does not clash with app proctoring; avoid duplicate permission prompts | Dev 2 | S2 | 4 | Browser proctoring off in app mode and still on for desktop; no extra prompts | 2 | 6 |
| B4 | Proctoring handshake APIs: receive start, pause, resume, violation and end events from the app; block assessment start until app proctoring is confirmed active; pause the assessment if proctoring drops | Dev 1 | S2 | 5 | State machine tests: start gating, drop, resume, duplicate and out-of-order events | 2 | 7 |
| B5 | Assessment pages fit for mobile webview: responsive layout, touch input, viewport and keyboard behaviour, orientation and timer display for every question type (MCQ, text, code, upload, video). Our assessment pages only | Dev 2 | S4 | 6 | Visual and functional pass for each question type and screen size | 2.5 | 8.5 |
| B6 | Events back to the app: completion, exit, timeout, error and session expiry callbacks (JS bridge or redirect scheme as agreed in the contract) | Dev 2 | S3 | 3 | Each event fires once with the right payload; contract tests | 1 | 4 |
| B7 | Resume and reconnect: network drop, app killed or relaunched; same attempt continues with answers and remaining time preserved; autosave | Dev 1 | S4 | 4 | Kill app, switch networks, airplane mode, low battery; check answers and timer | 2 | 6 |
| B8 | Attempt lock: only one active device per attempt; block a parallel desktop or second mobile session with a clear message | Dev 1 | S3 | 3 | Concurrent session tests, desktop versus mobile and two phones | 1 | 4 |
| B9 | Data model and basic reporting: record the source (mobile app), app proctoring events and violations against the attempt; show them in the existing reviewer view (export changes deferred) | Dev 1 | S5 | 2.5 | Data stored correctly; reviewer view shows mobile attempts | 1.5 | 4 |
| B10 | Feature flag and configuration per tenant and assessment to enable mobile app proctoring; safe default is off | Dev 2 | S3 | 1.5 | Flag on and off; tenant isolation | 0.5 | 2 |
| Section total | 36 | | 15 | 51 |
| C. Deep Linking (Criterion b) |
Create links that open the installed mobile app on Android and iOS. Our side covers link creation, validation, hosted verification files and fallbacks. The app side of link handling belongs to the app team.
| ID | Task and scope | Owner | Sprint | Dev (days) | QA activity | QA (days) | Total (days) |
|---|
| C1 | Deep link design: URL format, parameters, signing, expiry, Universal Links (iOS) and App Links (Android) domain, fallback rules; agree with the app team | Dev 2 | S1 | 2 | Review design; define test matrix (OS, browser, mail client) | 0.5 | 2.5 |
| C2 | Deep link generation service and API: create a signed, expiring link per candidate and assessment; regenerate and revoke | Dev 1 | S2 | 4 | API tests: create, expire, revoke, tamper, authorisation | 2 | 6 |
| C3 | Device detection and routing landing page: Android and iOS open the installed app; desktop shows the web flow or a clear message; unknown devices fall back safely | Dev 2 | S3 | 3 | Routing tests on Android, iOS, tablet and desktop | 1 | 4 |
| C4 | iOS Universal Links: host the apple-app-site-association file, configure paths, align app ID with the app team | Dev 2 | S3 | 1 | Link opens the app from Safari, Mail, Notes and Messages | 0.5 | 1.5 |
| C5 | Android App Links: host assetlinks.json, configure paths and certificate fingerprints, domain verification with the app team | Dev 2 | S3 | 1 | Link opens the app from Chrome, Gmail and SMS; verified link status | 0.5 | 1.5 |
| C6 | App not installed fallback: send the candidate to Play Store or App Store and keep the link usable after install so they land on their assessment | Dev 2 | S4 | 2 | Fresh install flow on both platforms; link still valid after install | 1 | 3 |
| C7 | Use the deep link in invitation emails, SMS and the candidate portal: template changes, desktop link versus mobile link | Dev 1 | S5 | 3 | Check rendered emails, SMS and portal for each channel and locale | 1 | 4 |
| C8 | Link validation when the app opens: verify token, expiry, reuse and candidate status; friendly error messages and a way to request a new link | Dev 1 | S5 | 3 | Expired, used, revoked, wrong candidate and already completed cases | 1 | 4 |
| C9 | In-app browser handling: links opened inside WhatsApp, Gmail, LinkedIn or Facebook browsers; add an ‘open in app or browser’ step | Dev 2 | S6 | 1 | Test across messaging and mail apps and several OS versions | 2 | 3 |
| Section total | 20 | | 9.5 | 29.5 |
| D. Non-Functional Requirements (NFR) |
Security, performance, reliability and other qualities needed for a proctored, high-stakes assessment on mobile. Proposed targets are in section 5 and need business agreement.
| ID | Task and scope | Owner | Sprint | Dev (days) | QA activity | QA (days) | Total (days) |
|---|
| D1 | Security hardening: signed links, token replay protection, rate limiting, brute force protection, CSP and headers for webview, secrets handling, threat review | Dev 1 | S4 | 4 | Security tests: token abuse, link forwarding, injection, OWASP checks | 2 | 6 |
| D2 | Performance and scalability: fast token exchange and link redirect, smaller page payloads, caching, autoscaling and indexes for the exam start spike | Dev 1 + Dev 2 | S6 | 4 | Load, stress and spike tests on launch, link service and autosave | 3 | 7 |
| D3 | Reliability on weak networks: retries, offline answer queue, idempotent submissions, server-side authoritative timer | Dev 1 | S5 | 3.5 | Throttled and flaky network tests; no lost or duplicated answers | 2 | 5.5 |
| D4 | Compatibility: supported Android WebView and iOS WKWebView versions, device and OS matrix, fixes for version specific issues | Dev 2 | S5 | 2 | Run the device and OS matrix (real devices plus emulators) | 3 | 5 |
| D5 | Observability: structured logs, correlation ID shared with the app, dashboards and alerts for launch failures and proctoring events | Dev 1 | S3 | 2.5 | Verify logs, traces and alerts fire as expected | 1 | 3.5 |
| D6 | Privacy and compliance: consent for camera and mic on mobile, retention of proctoring data per region, no personal data in logs | Dev 1 | S7 | 1.5 | Consent flow and data retention checks | 0.5 | 2 |
| D7 | Rollout and rollback: feature flag rollout plan, migration rollback, runbook, monitoring during release | Dev 1 | S7 | 1 | Rollback rehearsal in UAT | 0.5 | 1.5 |
| Section total | 18.5 | | 12 | 30.5 |
| E. Integrated Testing and Release (QA led, spans all features) |
Testing that cuts across features: automation, end to end testing with the app on real devices, regression (including the desktop flow), defect fixing, UAT and release readiness. Feature level test effort is already in sections A to D.
| ID | Task and scope | Owner | Sprint | Dev (days) | QA activity | QA (days) | Total (days) |
|---|
| E1 | Support API test automation for new endpoints (token, handshake, link service); provide test hooks and data | Dev 1 | S3 | 0.5 | Build and run the API automation suite in the pipeline | 3 | 3.5 |
| E2 | End to end integration with the app team build on real Android and iOS devices; fix integration defects | Dev 1 + Dev 2 | S6-S7 | 3 | Execute end to end scenarios: link, launch, app proctoring, assessment, submit | 4.5 | 7.5 |
| E3 | Regression cycles on desktop and mobile flows (two cycles plus a desktop smoke test with every build) | Dev 1 | S6-S7 | 0.5 | Run and report two regression cycles | 3 | 3.5 |
| E4 | Defect fixing across the project (about 7 percent of build effort) | Dev 1 + Dev 2 | S3-S7 | 7 | Retest fixes and verify closure | 2 | 9 |
| E5 | UAT support: environment, data, triage and fixes during UAT | Dev 1 + Dev 2 | S7 | 2 | Assist UAT users; triage defects | 1.5 | 3.5 |
| E6 | Release readiness: build verification, release notes, go or no-go input | Dev 1 | S7 | 0.5 | Test summary report and sign-off | 0.5 | 1 |
| Section total | 13.5 | | 14.5 | 28 |
| F. Adhoc Support and Documentation (Criterion c) |
Time reserved to support the app team whenever needed, and documentation. Adhoc support is a planned buffer so it does not eat into feature work. Post go-live hypercare sits outside this quarter (see section 4).
| ID | Task and scope | Owner | Sprint | Dev (days) | QA activity | QA (days) | Total (days) |
|---|
| F1 | Adhoc support for the app team: questions, debugging sessions, log analysis, test endpoints and environment issues (about 0.25 day per week per developer, reviewed every sprint) | Dev 1 + Dev 2 | S1-S7 | 7 | Reproduce and verify issues raised by the app team | 1 | 8 |
| F2 | Documentation: API specification, launch and deep link integration guide, runbook, known issues | Dev 1 + Dev 2 | S6-S7 | 3 | Review test documentation and the integration guide | 0.5 | 3.5 |
| Section total | 10 | | 1.5 | 11.5 |
| 6. NFR Targets (proposed, to be agreed) |
| Quality | Proposed target | Task |
|---|
| Launch token exchange | p95 < 500 ms | D2 |
| Deep link redirect | p95 < 300 ms | D2 |
| Assessment page load on 4G | p95 < 3 seconds | D2, B5 |
| Availability of launch and link services | 99.9% during exam windows | D2, D7 |
| Answer autosave | No more than 1 answer or 30 seconds of data lost after a network drop or app kill | D3, B7 |
| Peak concurrency | Assumed 2 times the current desktop peak; confirm number with business | D2 |
| Supported platforms | Latest 3 major Android and iOS versions; confirm with app team | D4 |
| Link validity | Short expiry, one-time use for launch tokens; expiry value to be confirmed | D1, C8 |
| Security | No critical or high findings open at release | D1 |
| Desktop regression | Zero new defects in the desktop flow | E3 |
| 7. NFR Issues to Be Addressed |
Known problems that commonly appear when assessments run inside a mobile webview. Each one is mapped to a task above.
| Issue | Why it matters | Proposed handling | Task | Severity |
|---|
| Session lost in webview | Third-party and SameSite cookie rules in WKWebView and Android WebView can drop the session mid-assessment. | Token based session, storage fallback, keep-alive | B2 | High |
| Camera and mic conflict | The app already holds the camera for proctoring; the web page asking again can fail or show a second prompt. | Turn off browser proctoring in app mode | B3 | High |
| App goes to background | Phone call, notification or app switch can suspend the webview; timers drift and answers may be lost. | Server-side authoritative timer, autosave, resume | B7, D3 | High |
| Link shared with someone else | A forwarded link could let another person start the candidate’s attempt. | Signed one-time token, bound to the candidate, attempt lock | D1, C8, B8 | High |
| Token replay and brute force | Reused or guessed tokens could start a session. | Short expiry, single use, rate limiting | D1 | High |
| Exam start spike | Everyone opens the link at the same time and overloads launch and link services. | Load and spike test, autoscaling, caching | D2 | High |
| Universal and App Links do not open the app | Links typed in the address bar, opened from the same domain, or with an unverified domain open in the browser instead. | Correct verification files, landing page fallback | C3, C4, C5 | Medium |
| In-app browsers capture the link | WhatsApp, Gmail and social apps open links in their own browser, so the app never opens. | ‘Open in app or browser’ step | C9 | Medium |
| App not installed or outdated | Candidate lands on the web with no way to be proctored. | Store fallback and clear error message | C6, C8 | Medium |
| Weak mobile network | Slow or dropping data connections break uploads and submissions. | Retries, idempotent submit, smaller payloads | D2, D3 | Medium |
| Webview version fragmentation | Old Android System WebView and iOS versions behave differently. | Agreed support matrix and device testing | D4 | Medium |
| Device clock differences | Wrong device time can distort timers and expiry checks. | Use server time everywhere | D3 | Medium |
| Privacy and consent on mobile | Camera and mic data and retention rules vary by region. | Consent flow, retention settings, no personal data in logs | D6 | Medium |
| Support is hard without shared logs | Issues between the app and our backend cannot be traced. | Shared correlation ID and dashboards | D5, F1 | Medium |
| Desktop regression | Shared code changes could break the working desktop flow. | Feature flag, desktop smoke test per build, regression cycles | B10, D7, E3 | Medium |
| Small screens and accessibility | Zoom, large fonts and small tap targets make questions hard to answer. | Basic responsive fixes now; formal accessibility pass deferred | B5, deferred | Low |
| Role | People | Capacity over 14 weeks | Planned with contingency | Utilisation | Note |
|---|
| Developers | 2 | 140 days | 122 days | 87% | Remaining 18 days cover leave, holidays and meetings |
| QA | 1 | 70 days | 62 days | 89% | High for one person. A single QA is the main bottleneck (risk R3) |
| Test type | What is covered | Who | Where in estimate |
|---|
| Functional | Each task in sections B and C, including negative cases | QA, in the same sprint as development | B, C |
| API and contract | Token, handshake, link service and events; contract tests against the agreed launch contract | QA with Dev support | B1, B4, B6, C2, E1 |
| Deep link matrix | Android and iOS, installed and not installed, browser, mail, SMS and messaging apps | QA | C3 to C9 |
| End to end on real devices | Link, launch, app proctoring, assessment, submit, with the app team build | QA with Dev and app team | E2 |
| Security | Token abuse, link forwarding, injection, headers, rate limits | QA with Dev 1 | D1 |
| Performance and load | Launch, link and autosave under peak load; exam start spike | QA with Dev 1 and Dev 2 | D2 |
| Compatibility | Device and OS matrix, WebView versions, screen sizes | QA | D4 |
| Regression | Desktop and mobile flows: two full cycles plus a desktop smoke test with every build | QA | E3 |
| UAT | Business users on UAT with mobile devices | Business, QA support | E5 |
Entry criteria. Contract frozen, environment and test data ready, build deployed with release notes.
Exit criteria. No open critical or high defects, all planned scenarios executed with at least 95% passing, NFR targets met or formally accepted, regression clean, UAT signed off. |
| 10. Risks and Mitigations |
| ID | Risk | Impact | Mitigation |
|---|
| R1 | App team changes the launch contract late, causing rework in B and C | High | Freeze the contract by the end of Sprint 1, version it, review changes in sprint planning |
| R2 | Legacy assessment pages need more rework than B5 estimates | High | Use A1 findings to re-estimate at the end of Sprint 1; Dev contingency of 15% held; defer lower-priority items first |
| R3 | Single QA is a bottleneck or absent for some days | High | Developers write unit and API tests and run smoke tests; consider part-time QA support for Sprints 6 and 7 |
| R4 | Plan has little slack: 7 sprints is slightly over a 13 week calendar quarter and scope was already trimmed | High | Start 1 week before quarter start, or accept Sprint 7 closing in the first week of the next quarter; if risks hit, defer C9 and B9 next |
| R5 | Real device or device farm access is late | Medium | Raise in week 1; start with emulators and use the farm for the matrix in Sprint 5 |
| R6 | App team’s deep link setup (entitlements, certificate fingerprints) arrives late, blocking C4 and C5 testing | Medium | Agree dates in Sprint 1; test the hosted files independently first |
| R7 | Proctoring event meaning is unclear (what counts as a violation or pause) | Medium | Document in the contract and review with product in Sprint 1 |
| R8 | App builds depend on store review cycles | Medium | Use TestFlight and Android internal tracks for test builds |
| R9 | NFR numbers are not agreed by business | Medium | Use the proposed targets in section 6; confirm by the end of Sprint 1 |
- Are the deferred items in section 4 acceptable for this quarter?
- What is the agreed way to start the webview: token in URL, POST, or a JS bridge? (affects B1, B6)
- Which events must the app send to us, and what must we do when proctoring drops mid-assessment? (affects B4)
- Should the same candidate be allowed to continue on desktop after starting on mobile? (affects B8)
- Which Android and iOS versions and which devices must be supported? (affects D4)
- What is the expected peak number of concurrent mobile candidates? (affects D2)
- Which domain will host the deep links and verification files, and who manages DNS and certificates? (affects C1, C4, C5)
- Where do proctoring recordings and violation data live, and for how long are they kept per region? (affects B9, D6)
How to use in Confluence: open this file in a browser, select all, copy, and paste into a Confluence page in edit mode. Colours and tables are kept; if a colour is lost, reapply it with the table cell background option.