Mobile Proctoring Simple Estimate
What we are doing. Candidates take proctored assessments on desktop today. A mobile app (built by another team) will open the assessment in a mobile webview and proctor the candidate. Our part is to give candidates a link that opens the app, support the app team when they need us, make it safe and reliable, and test it.
| Mobile App Proctoring: Simple Estimate Deep linking, adhoc support, NFR and testing | 2 Developers + 1 QA | 6 sprints of 2 weeks (one quarter) | Effort in days |
| 1. Summary |
| The answer in one line: about 91 days of work (52.5 Dev + 38.5 QA). Adding a safety margin gives 103 days (60.5 Dev + 42.5 QA). This fits comfortably inside 6 sprints (one quarter). |
| Area | Dev days | QA days | Total days |
|---|---|---|---|
| 1. Planning and Setup | 4 | 3.5 | 7.5 |
| 2. Deep Linking | 18 | 9 | 27 |
| 3. Adhoc Support for the App Team | 8 | 1.5 | 9.5 |
| 4. Non-Functional Requirements (NFR) | 13 | 11 | 24 |
| 5. Testing and Release | 9.5 | 13.5 | 23 |
| Work total | 52.5 | 38.5 | 91 |
| Safety margin (Dev 15%, QA 10%) | 8 | 4 | 12 |
| Grand total | 60.5 | 42.5 | 103 |
| 2. How to Read the Estimate |
- Every task has a size: S = up to 1.5 days, M = 2 to 3 days, L = 4 days or more.
- Each task shows Dev days (building) and QA days (testing that task). Both are in working days for one person.
- A safety margin is added at the end for surprises: 15% for Dev, 10% for QA.
- Sprint shows when the task is done. S1 means Sprint 1.
| 3. Estimates by Area |
| 1. Planning and Setup |
Get everyone aligned before building.
| ID | Task | Size | Dev days | QA days | Total days | Sprint |
|---|---|---|---|---|---|---|
| P1 | Agree with the app team how the link looks and what the app does when it opens | M | 3 | 0.5 | 3.5 | S1 |
| P2 | Set up test environments, a domain for links, test data and test devices | S | 1 | 1 | 2 | S1 |
| P3 | Write the test plan and test cases | – | 0 | 2 | 2 | S1 |
| Total | 4 | 3.5 | 7.5 | |||
| 2. Deep Linking |
Links that open the app on Android and iPhone.
| ID | Task | Size | Dev days | QA days | Total days | Sprint |
|---|---|---|---|---|---|---|
| D1 | Create the link: a safe, expiring link for each candidate and assessment | L | 4 | 2 | 6 | S1 |
| D2 | Detect Android, iPhone or computer and send the candidate to the right place | M | 3 | 1 | 4 | S2 |
| D3 | iPhone setup (Universal Links): host the file that lets iOS open the app | S | 1 | 0.5 | 1.5 | S2 |
| D4 | Android setup (App Links): host the file that lets Android open the app | S | 1 | 0.5 | 1.5 | S2 |
| D5 | If the app is not installed, send the candidate to the Play Store or App Store | M | 2 | 1 | 3 | S3 |
| D6 | Check the link when the app opens: expired, already used, wrong candidate | M | 3 | 1 | 4 | S2 |
| D7 | Put the link into invitation emails, SMS and the candidate portal | M | 3 | 1 | 4 | S3 |
| D8 | Handle links opened inside WhatsApp, Gmail and similar apps | S | 1 | 2 | 3 | S3 |
| Total | 18 | 9 | 27 | |||
| 3. Adhoc Support for the App Team |
Time kept aside to help the app team whenever they need it.
| ID | Task | Size | Dev days | QA days | Total days | Sprint |
|---|---|---|---|---|---|---|
| S1 | Answer questions, join debugging calls, check logs, fix environment problems (about 1 day every 2 weeks per developer) | L | 6 | 1 | 7 | S1-S6 |
| S2 | Write the integration guide and API documentation | M | 2 | 0.5 | 2.5 | S6 |
| Total | 8 | 1.5 | 9.5 | |||
| 4. Non-Functional Requirements (NFR) |
Making the links safe, fast and reliable.
| ID | Task | Size | Dev days | QA days | Total days | Sprint |
|---|---|---|---|---|---|---|
| N1 | Security: links cannot be guessed, reused or shared; limit repeated attempts | M | 3 | 2 | 5 | S2 |
| N2 | Speed and load: fast link opening, many candidates opening links at the same time | M | 3 | 3 | 6 | S4 |
| N3 | Reliability: retries and clear messages when the network is poor | M | 2 | 1 | 3 | S4 |
| N4 | Compatibility: different Android and iOS versions, phones and mail apps | S | 1 | 3 | 4 | S4 |
| N5 | Logging and monitoring: record link events and failures, set up alerts | M | 2 | 1 | 3 | S3 |
| N6 | Privacy: no personal data in links or logs | S | 1 | 0.5 | 1.5 | S3 |
| N7 | Safe release: on/off switch (feature flag) and a way to roll back | S | 1 | 0.5 | 1.5 | S4 |
| Total | 13 | 11 | 24 | |||
| 5. Testing and Release |
Testing across everything, with the app team, and getting released.
| ID | Task | Size | Dev days | QA days | Total days | Sprint |
|---|---|---|---|---|---|---|
| T1 | Automated tests for the link APIs | S | 0.5 | 3 | 3.5 | S3 |
| T2 | End to end test with the app team on real Android and iPhone devices | M | 2 | 4 | 6 | S5 |
| T3 | Regression testing, two rounds, to make sure nothing existing broke | – | 0 | 2.5 | 2.5 | S5-S6 |
| T4 | Fix defects found during testing (about 10% of build effort) | L | 5 | 2 | 7 | S3-S6 |
| T5 | Support user acceptance testing (UAT) | S | 1.5 | 1.5 | 3 | S6 |
| T6 | Release readiness: final checks and go or no-go | S | 0.5 | 0.5 | 1 | S6 |
| Total | 9.5 | 13.5 | 23 | |||
| 4. Sprint Plan (6 sprints x 2 weeks) |
| Sprint | Weeks | What happens | Tasks | Dev days | QA days |
|---|---|---|---|---|---|
| Sprint 1 | 1-2 | Planning and first link. Agree link design with the app team, set up environments, test plan, link creation | P1, P2, P3, D1 | 9 | 5.7 |
| Sprint 2 | 3-4 | Core deep linking. Routing, iPhone and Android setup, link checks, security | D2, D3, D4, D6, N1 | 12 | 5.2 |
| Sprint 3 | 5-6 | Fallbacks and invitations. Store fallback, links in emails and SMS, WhatsApp and Gmail handling, logging, API tests | D5, D7, D8, N5, N6, T1, T4 | 11 | 8.9 |
| Sprint 4 | 7-8 | Speed, reliability and compatibility. Load testing, poor network handling, device and OS testing, safe release switch | N2, N3, N4, N7, T4 | 9.5 | 8.3 |
| Sprint 5 | 9-10 | Test with the app team. End to end on real devices with the app team build, first regression round | T2, T3, T4 | 5 | 6.2 |
| Sprint 6 | 11-12 | UAT and release. Second regression round, UAT, documentation, go or no-go | S2, T3, T4, T5, T6 | 6 | 4.3 |
| Total | 52.5 | 38.5 | |||
Adhoc support (S1) is spread evenly across all 6 sprints and is included in the Dev and QA days above.
| 5. Do We Have Enough People? |
| Role | Available in 6 sprints | Needed (with safety margin) | Used | Meaning |
|---|---|---|---|---|
| 2 Developers | 120 days | 60.5 days | 50% | Plenty of room. Spare time absorbs extra adhoc requests, leave and holidays. |
| 1 QA | 60 days | 42.5 days | 71% | Comfortable. Busiest in Sprints 3 to 5. |
The work itself is about 4 sprints of effort. Six sprints leaves space for waiting on the app team, adhoc support and fixes. If the app team’s build arrives late, the end to end testing in Sprint 5 is what moves.
| 6. Not Included in This Estimate |
| Not included |
|---|
| Mobile webview work (done by another team) |
| Mobile app development and its proctoring logic (done by another team) |
| Any changes inside our assessment application to make it run in the webview (for example launch token, mobile page fixes, resume after interruption, handshake with the app) |
| App side deep link handling, and publishing the app to the stores |
| Support after go-live (hypercare) |
| Please confirm. If our assessment application also needs changes so that it runs properly inside the webview, that is extra work and is not counted here. My earlier detailed estimate put it at roughly 36 dev days and 15 QA days. It should be agreed with the app team before this plan is final. |
| 7. NFR Issues to Watch |
| Issue | What can go wrong | Task | Severity |
|---|---|---|---|
| Link opens in the browser instead of the app | Links typed in the address bar or with a wrong setup open the website, not the app | D2, D3, D4 | High |
| Links opened inside WhatsApp, Gmail or social apps | These apps open links in their own browser and the app never starts | D8 | Medium |
| Link shared with someone else | Another person could start the candidate’s assessment | D1, D6, N1 | High |
| Everyone opens the link at the same time | Exam start causes a rush and slows the service | N2 | High |
| Poor mobile network | The link or page fails to load, or the candidate sees an unclear error | N3 | Medium |
| Different phones and Android/iOS versions | Behaviour differs between devices and mail apps | N4 | Medium |
| App not installed or out of date | The candidate reaches the web with no way to be proctored | D5, D6 | Medium |
| Hard to find problems between the app and our system | Without shared logs, issues take a long time to trace | N5, S1 | Medium |
| 8. Main Risks and Questions |
| Risk or question | What we do |
|---|---|
| App team build or deep link setup (certificates, app ID) arrives late | Agree dates in Sprint 1; test our hosted files on their own first |
| Link design changes late | Freeze the design with the app team by the end of Sprint 1 |
| Only one QA | Developers write unit tests and smoke tests; keep QA busy on automation early |
| Is webview support in our assessment app really out of scope? | Confirm with the app team and product (see section 6) |
| Which Android and iOS versions must work, and how many candidates open links at once? | Agree numbers in Sprint 1; they decide the test matrix and load tests |
How to use in Confluence: open this file in a browser, select all, copy, and paste into a Confluence page in edit mode.