Digital Form — Testcase Report

testcases

C-sections

critical risk

high risk

planned auto

preconditions

Sections — what each C-group tests

Each C-section is a capability area from the TSD. Product shows whether it runs on web (CP), mobile, or API.

Section	Capability	Product	Testcases
C1	Edit Existing Form	web	6
C2	Save Scope	web	9
C3	Mobile & History Impact	mobile	5
C4	Duplicate Form	web	5
C5	Compound Modification	mobile web	6
C6	Availability Modification	mobile web	8
C7	Assignment Modification	mobile web	7
C8	Copy From Previous	mobile	7
C9	Export Snapshot	web	4
C10	Activity Log	web	4

Coverage by C-section

C10

Distribution

Priority P0 / P1 / P2 / P3: 10 / 41 / 9 / 1
Risk critical / high / med / low: 10 / 40 / 10 / 1
Coverage POS / NEG / EDGE: 42 / 11 / 8
Automation planned: 61
Flows · Suites: 3 · 2

Precondition composition

Foundational data fragments (left) flow into state fragments (right), which testcases reference. Counts are direct testcase usage. The data world — channel, form template, visitation — is seeded before any login or navigation.

PRE-DF-form-exists

10 testcases

→

PRE-DF-compound-exists

5 testcases · needs 1

PRE-DF-cp-editing-form

23 testcases · needs 1

PRE-DF-mobile-assigned

10 testcases · needs 1

→

PRE-DF-submitted-report-exists

13 testcases · needs 1

Precondition	Composes	Used by	Source
PRE-DF-compound-exists A compound used by one or more forms exists	PRE-DF-form-exists	5	md
PRE-DF-cp-editing-form CP user is editing an existing form with all steps prefilled	PRE-DF-form-exists	23	md
PRE-DF-form-exists A saved digital form exists in the CP Form List	—	10	md
PRE-DF-mobile-assigned Employee has the form assigned and can start a visitation	PRE-DF-form-exists	10	md
PRE-DF-submitted-report-exists At least one submitted report exists for the form and channel	PRE-DF-mobile-assigned	13	md

Flows — journeys

FLOW-DFMOD-compound-modify-propagate

Compound modify, impact confirm, and runtime safety journey

active

PRE-DF-compound-exists

1. DFMOD-C5-POS-001 2. DFMOD-C5-POS-002 3. DFMOD-C5-POS-003 4. DFMOD-C5-POS-005 5. DFMOD-C5-POS-006

FLOW-DFMOD-copy-from-previous

Copy from previous submitted report journey

active

PRE-DF-submitted-report-exists

1. DFMOD-C8-POS-002 2. DFMOD-C8-POS-003 3. DFMOD-C8-POS-007

FLOW-DFMOD-edit-save-versioning

Edit form, scoped save, and versioning journey

active

PRE-DF-cp-editing-form

1. DFMOD-C1-POS-001 2. DFMOD-C1-POS-006 3. DFMOD-C2-POS-001 4. DFMOD-C2-POS-003 5. DFMOD-C2-POS-007 6. DFMOD-C2-POS-009

Suites — run sets

pk141-regression-staging

PK141 Digital Form Modification full regression (staging)

active

61 testcases · env staging

DFMOD-C1-EDGE-005 DFMOD-C1-NEG-002 DFMOD-C1-POS-001 DFMOD-C1-POS-003 DFMOD-C1-POS-004 DFMOD-C1-POS-006 DFMOD-C10-POS-001 DFMOD-C10-POS-002 DFMOD-C10-POS-003 DFMOD-C10-POS-004 DFMOD-C2-EDGE-002 DFMOD-C2-EDGE-004

pk141-smoke-staging

PK141 Digital Form Modification smoke (P0 critical paths, staging)

active

10 testcases · env staging

DFMOD-C2-POS-001 DFMOD-C2-POS-003 DFMOD-C3-POS-001 DFMOD-C3-POS-002 DFMOD-C3-POS-004 DFMOD-C5-POS-003 DFMOD-C5-POS-005 DFMOD-C6-POS-008 DFMOD-C7-POS-005 DFMOD-C8-NEG-004

Testcases

61 / 61 shown

ID	Scn	Product	Title	Pri	Risk	Status	Auto	Preconditions	Src
▸C1 Edit Existing Form web
▸DFMOD-C1-NEG-002	C1.1	web	Partial config load failure shows fallback state and redirects safely Verify graceful handling when part of the form configuration (e.g. Step 2) fails to load on edit.	P2	medium	draft	planned	PRE-DF-form-exists	md
Objective Verify graceful handling when part of the form configuration (e.g. Step 2) fails to load on edit. Preconditions See PRE-DF-form-exists And Step 2 data is forced to partially fail to load Steps When the user opens Edit and the config cannot fully load Expected Result Then the system shows a fallback state with a toast explaining the reason And the user is redirected back to the Form List And no partial/corrupt saved-state is presented as valid Source Traceability TSD: PK141 Section: C1 - Edit Existing Form Scenario: C1.1 - Access edit form and preload saved configuration (edge case) Acceptance Criteria: PRD C.1 Scenario 1-4 Evidence Required Screen recording of fallback + toast + redirect. Notes / Gaps Testing Concern TC-03 (Medium): final error copy for partially-loaded edit page is not finalized.
▸DFMOD-C1-POS-001	C1.1	web	Editing a form preloads all previously saved configuration across Step 1–5 Verify opening Edit on an existing form routes into the Step 1–5 flow with all saved configuration prefilled.	P1	high	draft	planned	PRE-DF-form-exists	md
Objective Verify opening Edit on an existing form routes into the Step 1–5 flow with all saved configuration prefilled. Preconditions See PRE-DF-form-exists And the CP user is on the Form List page Steps When the user clicks the Edit action on a form Expected Result Then the user is routed to the edit flow with Step 1 through Step 5 And all previously saved configuration is prefilled across Step 1, Step 2, Step 3, Step 4, and Step 5 And no saved-state field is empty without a valid reason Source Traceability TSD: PK141 Section: C1 - Edit Existing Form, Edited State, and Unsaved Changes Protection Scenario: C1.1 - Access edit form and preload saved configuration Acceptance Criteria: PRD C.1 Scenario 1-4 Evidence Required Screen recording of the edit flow showing prefilled steps. Notes / Gaps Partial-load failure handling is covered by DFMOD-C1-NEG-002.
▸DFMOD-C1-POS-003	C1.2	web	Edited state stays active even after a value is reverted to its original Verify the form remains in an "edited" state and Save stays enabled even after a changed value is reverted to its original.	P1	high	draft	planned	PRE-DF-cp-editing-form	md
Objective Verify the form remains in an "edited" state and Save stays enabled even after a changed value is reverted to its original. Preconditions See PRE-DF-cp-editing-form Steps Change a field, then change it back to its original value Navigate to another step Expected Result Then the system still treats the form as edited And the Save button stays enabled on steps that allow save Source Traceability TSD: PK141 Section: C1 - Edited State Scenario: C1.2 - Edited state stays active after revert Acceptance Criteria: PRD C.1 Scenario 7-10 Evidence Required Screen recording of revert + Save still enabled. Notes / Gaps A structural-field revert before save must still be distinguished from a no-change final state at version evaluation (see DFMOD-C2-EDGE-004).
▸DFMOD-C1-EDGE-005	C1.3	web	Session interruption or crash does not persist unsaved changes Verify a crash/interruption mid-edit leaves no unsaved state persisted.	P2	medium	draft	planned	PRE-DF-cp-editing-form	md
Objective Verify a crash/interruption mid-edit leaves no unsaved state persisted. Preconditions See PRE-DF-cp-editing-form And the user has unsaved edits in session Steps When the session is interrupted or the app crashes before Save Expected Result Then the unsaved state is not persisted to backend And re-opening the form returns to the last saved state Source Traceability TSD: PK141 Section: C1 - Unsaved Changes Scenario: C1.3 - Temporary state in session, no auto-save (edge case) Acceptance Criteria: PRD C.4 Scenario 1-6 Evidence Required Backend inspection after interruption; re-open shows last saved state. Notes / Gaps No gap.
▸DFMOD-C1-POS-004	C1.3	web	Temporary edits persist in session but are not auto-saved to backend Verify edits are retained across step navigation within the session but never persisted before a valid Save.	P1	high	draft	planned	PRE-DF-cp-editing-form	md
Objective Verify edits are retained across step navigation within the session but never persisted before a valid Save. Preconditions See PRE-DF-cp-editing-form Steps Change data in Step 1, Step 2, or Step 3 Navigate with Next / Previous Expected Result Then changes remain visible on the next/previous step within the same session And nothing is persisted to backend before a valid Save is triggered And a structural change in Step 2 is reflected in preview without causing persistence Source Traceability TSD: PK141 Section: C1 - Unsaved Changes Scenario: C1.3 - Temporary state in session, no auto-save Acceptance Criteria: PRD C.4 Scenario 1-6 Evidence Required Screen recording of session retention + backend showing no writes pre-Save. Notes / Gaps Crash/interruption handling is covered by DFMOD-C1-EDGE-005.
▸DFMOD-C1-POS-006	C1.4	web	Unsaved changes protection appears on in-app navigation and browser exit Verify the unsaved-changes confirmation appears for both in-app navigation and browser exit, with Cancel and Leave behaving correctly.	P1	high	draft	planned	PRE-DF-cp-editing-form	md
Objective Verify the unsaved-changes confirmation appears for both in-app navigation and browser exit, with Cancel and Leave behaving correctly. Preconditions See PRE-DF-cp-editing-form And the user has unsaved changes Steps Attempt to leave via breadcrumb, internal navigation, browser refresh, close tab, or browser back Choose Cancel; in a separate run, choose Leave Expected Result Then the system shows a confirmation that changes will be lost And Cancel keeps the user editing And Leave discards all unsaved changes And after discard, re-opening returns to the last saved state (not partial) Source Traceability TSD: PK141 Section: C1 - Unsaved Changes Protection Scenario: C1.4 - Unsaved changes protection on navigation and browser exit Acceptance Criteria: PRD C.2 Scenario 1-6, C.3 Scenario 1-4 Evidence Required Screen recording of confirmation across exit paths; Cancel and Leave outcomes. Notes / Gaps Rapid navigation while the modal shows must not corrupt data (Testing Concern TC-11, Medium).
▸C2 Save Scope web
▸DFMOD-C2-EDGE-002	C2.1	web	Invalid or unsaved step handling during scoped save Verify scoped-save behavior when a step is partially edited/invalid or not yet committed.	P1	high	draft	planned	PRE-DF-cp-editing-form	md
Objective Verify scoped-save behavior when a step is partially edited/invalid or not yet committed. Preconditions See PRE-DF-cp-editing-form Steps Partially edit Step 2 (not yet valid), then Save from Step 1 Leave Step 2 uncommitted at Step 4, then Save at Step 5 Expected Result Then saving from Step 1 with an invalid Step 2 edit discards that Step 2 change And saving at Step 5 commits the previously uncommitted Step 2 change as a fallback Source Traceability TSD: PK141 Section: C2 - Save Scope Scenario: C2.1 - Save scope (edge cases) Acceptance Criteria: PRD C.5 Scenario 1-4 Evidence Required Backend diff for each path. Notes / Gaps Testing Concern TC-01 (High): the mixed-edit save contract across steps must be confirmed in implementation.
▸DFMOD-C2-POS-001	C2.1	web	Save scope follows the Save button location, not where edits were made Verify which steps are committed depends on the Save button used, not where edits occurred.	P0	critical	draft	planned	PRE-DF-cp-editing-form	md
Objective Verify which steps are committed depends on the Save button used, not where edits occurred. Preconditions See PRE-DF-cp-editing-form And the user has changed data across several steps Steps Click Save in Step 1 In a separate run, click Save in Step 4 In a separate run, click Save in Step 5 Expected Result Then Save in Step 1 persists only Step 1 data; Step 2 and Step 3 changes are not persisted And Save in Step 4 commits Step 1, Step 2, and Step 3 changes And Save in Step 5 commits all changes from Step 1 to Step 5 Source Traceability TSD: PK141 Section: C2 - Save Scope Scenario: C2.1 - Save scope follows Save button location Acceptance Criteria: PRD C.5 Scenario 1-4, C.6 Scenario 1-5, C.7 Scenario 0-5 Evidence Required Backend diff per Save location. Notes / Gaps Mixed/invalid-step behavior is covered by DFMOD-C2-EDGE-002. Testing Concern TC-01 (High): Step 4 vs Step 5 save contract for mixed edits not fully finalized.
▸DFMOD-C2-EDGE-004	C2.2	web	Reverted structural change creates no version; mixed changes increment once Verify version evaluation for reverted structural edits and mixed structural + non-structural saves.	P1	high	draft	planned	PRE-DF-cp-editing-form	md
Objective Verify version evaluation for reverted structural edits and mixed structural + non-structural saves. Preconditions See PRE-DF-cp-editing-form Steps Make a structural change in Step 2, revert it to the original, then save In a separate run, make mixed structural + non-structural changes, then save once Expected Result Then a reverted-to-original structural change creates no new version And mixed structural + non-structural changes still increment by exactly one version Source Traceability TSD: PK141 Section: C2 - Versioning Scenario: C2.2 - Versioning (edge cases) Acceptance Criteria: PRD C.8-C.13 Evidence Required Version value before/after each path. Notes / Gaps No gap.
▸DFMOD-C2-POS-003	C2.2	web	Step 1 changes keep version; structural Step 2/3 changes create one new version Verify versioning rules: non-structural Step 1 edits do not bump the version; structural Step 2/3 edits create exactly one new version per save.	P0	critical	draft	planned	PRE-DF-cp-editing-form	md
Objective Verify versioning rules: non-structural Step 1 edits do not bump the version; structural Step 2/3 edits create exactly one new version per save. Preconditions See PRE-DF-cp-editing-form Steps Change only basic info / modification & approval / availability / target in Step 1, then save Change Form Builder / training material / logic jump in Step 2 or Step 3, then save via Step 4 or Step 5 Expected Result Then the Form Version stays the same after the Step 1-only save And the system creates exactly one new version for the structural save action Source Traceability TSD: PK141 Section: C2 - Versioning Scenario: C2.2 - Step 1 no version, structural Step 2/3 creates version Acceptance Criteria: PRD C.8 Scenario 3-6, C.9 Scenario 1-6, C.10/11/13 Evidence Required Version value before/after each save. Notes / Gaps Revert-before-save and mixed changes are covered by DFMOD-C2-EDGE-004.
▸DFMOD-C2-NEG-006	C2.3	web	Invalid training material input blocks save with a validation error Verify invalid training material input is blocked at save.	P2	medium	draft	planned	PRE-DF-cp-editing-form	md
Objective Verify invalid training material input is blocked at save. Preconditions See PRE-DF-cp-editing-form And the user enters invalid training material (e.g. malformed video URL) Steps Attempt to save Expected Result Then save is blocked with a validation error Source Traceability TSD: PK141 Section: C2 - Form Builder Scenario: C2.3 - Training material (edge case) Acceptance Criteria: PRD C.9 Scenario 1-6 Evidence Required Screenshot of validation error on save. Notes / Gaps No gap.
▸DFMOD-C2-POS-005	C2.3	web	Training material changes are treated as structural and bump the version Verify training material edits follow Form Builder save rules, are treated as structural in preview/runtime, and bump the version.	P1	high	draft	planned	PRE-DF-cp-editing-form	md
Objective Verify training material edits follow Form Builder save rules, are treated as structural in preview/runtime, and bump the version. Preconditions See PRE-DF-cp-editing-form Steps Change training title, attachment, video URL, or description in Step 2 Save via a valid save path Expected Result Then the change follows Form Builder save rules And preview / mobile runtime treat it as a relevant structural change And the form version increments per structural-change rules Source Traceability TSD: PK141 Section: C2 - Form Builder Scenario: C2.3 - Training material is part of form structure Acceptance Criteria: PRD C.9 Scenario 1-6 Evidence Required Version change + preview reflecting training change. Notes / Gaps Enable-then-disable before save → no version increment (assert in regression). Testing Concern TC-02 (High): final version-upgrade behavior for training material pending PM/Dev. Invalid training input handling is covered by DFMOD-C2-NEG-006.
▸DFMOD-C2-NEG-008	C2.4	web	Deleting a referenced page/question is prevented from creating invalid logic Verify the system prevents an invalid logic configuration when a referenced page or question is deleted.	P1	high	draft	planned	PRE-DF-cp-editing-form	md
Objective Verify the system prevents an invalid logic configuration when a referenced page or question is deleted. Preconditions See PRE-DF-cp-editing-form And a logic jump references a specific page/question Steps Delete the referenced page or question Expected Result Then the system prevents the resulting invalid logic configuration (block or force fix) Source Traceability TSD: PK141 Section: C2 - Logic Jump & Preview Scenario: C2.4 - Logic/Preview (edge case) Acceptance Criteria: PRD C.11, C.12 Evidence Required Screenshot of the prevention/validation on referenced-target deletion. Notes / Gaps No gap.
▸DFMOD-C2-POS-007	C2.4	web	Logic Jump and Preview reflect latest session state without persisting Verify Preview shows the latest structure and logic (including unsaved changes) without persisting data.	P1	high	draft	planned	PRE-DF-cp-editing-form	md
Objective Verify Preview shows the latest structure and logic (including unsaved changes) without persisting data. Preconditions See PRE-DF-cp-editing-form Steps Change structure in Step 2 or logic in Step 3 Open Step 4 Preview Expected Result Then preview shows the latest structure and logic flow including unsaved changes And preview does not cause data persistence And re-opening preview after incremental changes always reflects the latest state Source Traceability TSD: PK141 Section: C2 - Logic Jump & Preview Scenario: C2.4 - Logic Jump and Preview sync with latest session state Acceptance Criteria: PRD C.10 Scenario 5, C.11, C.12 Evidence Required Preview reflecting unsaved changes; backend showing no writes. Notes / Gaps Deleted referenced page/question handling is covered by DFMOD-C2-NEG-008.
▸DFMOD-C2-POS-009	C2.5	web	Question ID is new for added questions and stable for edited ones Verify Question ID assignment on add, duplicate, and edit.	P1	high	draft	planned	PRE-DF-cp-editing-form	md
Objective Verify Question ID assignment on add, duplicate, and edit. Preconditions See PRE-DF-cp-editing-form Steps Add a new question manually or via duplicate question/page, then save Edit only the config (title, mandatory, options, input type) of an existing question, then save Expected Result Then a new question receives a new Question ID And an existing question that only had its config changed keeps its old Question ID And duplicating a page carrying multiple new questions gives each cloned question a new ID Source Traceability TSD: PK141 Section: C2 - Question ID Scenario: C2.5 - Question ID behavior on add, duplicate, edit Acceptance Criteria: PRD C.13 Scenario 12-13 Evidence Required Question ID inspection before/after add vs edit. Notes / Gaps No gap.
▸C3 Mobile & History Impact mobile
▸DFMOD-C3-POS-001	C3.1	mobile	New visitation always uses the latest assigned form version Verify a newly started visitation receives the latest assigned form version after a modification.	P0	critical	draft	planned	PRE-DF-mobile-assigned	md
Objective Verify a newly started visitation receives the latest assigned form version after a modification. Preconditions See PRE-DF-mobile-assigned And the form was modified before the employee starts a new visit Steps When the employee opens the form on a newly started visitation Expected Result Then the employee receives the latest assigned version And assignment name, training material, structure, and logic reflect the latest saved state Source Traceability TSD: PK141 Section: C3 - Mobile & History Impact Scenario: C3.1 - New visitation uses latest assigned version Acceptance Criteria: PRD M.1 Scenario 1, M.2 Scenario 1-4 Evidence Required Version + structure rendered on the new visit. Notes / Gaps Ongoing-visit snapshot behavior is covered by DFMOD-C3-POS-002.
▸DFMOD-C3-EDGE-003	C3.2	mobile	Extreme structure change (deleted page/question) keeps ongoing visit safe Verify an ongoing visit survives extreme structure changes (whole page/question deleted) without crashing or losing input.	P1	high	draft	planned	PRE-DF-mobile-assigned	md
Objective Verify an ongoing visit survives extreme structure changes (whole page/question deleted) without crashing or losing input. Preconditions See PRE-DF-mobile-assigned And the employee is on a specific page of an in-progress visit Steps When the admin deletes a whole page/question and saves while the visit is ongoing Expected Result Then the ongoing visit remains safe on its old snapshot And the UI does not crash and does not lose entered input Source Traceability TSD: PK141 Section: C3 - Mobile & History Impact Scenario: C3.2 - Ongoing visitation (edge case) Acceptance Criteria: PRD M.1 Scenario 2-4 Evidence Required Screen recording of ongoing visit during an extreme portal-side deletion. Notes / Gaps No gap.
▸DFMOD-C3-POS-002	C3.2	mobile	Ongoing visitation keeps its old snapshot without sudden change Verify an in-progress visitation continues on its original version when the form is modified mid-way.	P0	critical	draft	planned	PRE-DF-mobile-assigned	md
Objective Verify an in-progress visitation continues on its original version when the form is modified mid-way. Preconditions See PRE-DF-mobile-assigned And the employee has started and is filling the form Steps When the admin changes structure, logic, training material, or assignment name in the portal Expected Result Then the ongoing visitation keeps using the old version And validation and navigation flow do not change mid-process And the form does not reload to the new structure Source Traceability TSD: PK141 Section: C3 - Mobile & History Impact Scenario: C3.2 - Ongoing visitation keeps old snapshot Acceptance Criteria: PRD M.1 Scenario 2-4, M.2 Scenario 3-6 Evidence Required Ongoing visit unchanged after a mid-visit portal save. Notes / Gaps Extreme structure-change safety is covered by DFMOD-C3-EDGE-003.
▸DFMOD-C3-POS-004	C3.3	mobile	Historical reports reflect the form version at submission time Verify historical and task reports stay bound to the version used at submission, even after later modification.	P0	critical	draft	planned	PRE-DF-submitted-report-exists	md
Objective Verify historical and task reports stay bound to the version used at submission, even after later modification. Preconditions See PRE-DF-submitted-report-exists Steps When the admin modifies the form after submission Open list history and detail history Expected Result Then history list and detail show assignment name, form ID, structure, and answers per the submission version And historical access is valid from all entry points named in the PRD And later database/label updates do not mutate historical answers Source Traceability TSD: PK141 Section: C3 - History Impact Scenario: C3.3 - Historical reports reflect submission version Acceptance Criteria: PRD M.3 Scenario 1-5 Evidence Required History payload before/after a post-submission modification. Notes / Gaps Cross-entry-point consistency is covered by DFMOD-C3-POS-005.
▸DFMOD-C3-POS-005	C3.4	mobile	All history entry points show consistent context for the same report Verify every history entry point renders the same submission-version context for one report.	P1	high	draft	planned	PRE-DF-submitted-report-exists	md
Objective Verify every history entry point renders the same submission-version context for one report. Preconditions See PRE-DF-submitted-report-exists Steps Open the same submitted task report detail from Riwayat, Detail Kunjungan, Activity list section, and Task Detail Expected Result Then every entry point shows assignment name, form ID, structure, and answers based on the same submission version And there is no mismatch between surfaces for the same report Source Traceability TSD: PK141 Section: C3 - History Impact Scenario: C3.4 - All entry points show consistent context Acceptance Criteria: PRD M.3 Scenario 3-5 Evidence Required Side-by-side detail from each entry point. Notes / Gaps PJP vs non-PJP and current-vs-yesterday date filters must not change the historical payload.
▸C4 Duplicate Form web
▸DFMOD-C4-POS-001	C4.1	web	Duplicate opens the setup flow prefilled from the source form Verify duplicating a form opens the setup flow from Step 1 prefilled with the source's latest saved configuration.	P1	high	draft	planned	PRE-DF-form-exists	md
Objective Verify duplicating a form opens the setup flow from Step 1 prefilled with the source's latest saved configuration. Preconditions See PRE-DF-form-exists And the source form contains training material, logic jump, assignment, target, and availability Steps Choose the duplicate action on an existing form Expected Result Then the user is routed to the form setup flow starting at Step 1 And all steps are prefilled from the source form's latest saved configuration And the duplicated form can be reviewed in preview before save And a temporary availability source results in an empty period state per PRD Source Traceability TSD: PK141 Section: C4 - Duplicate Form Scenario: C4.1 - Duplicate opens prefilled setup Acceptance Criteria: PRD C.14 Scenario 1-7 Evidence Required Screen recording of duplicate → prefilled setup + preview. Notes / Gaps No gap.
▸DFMOD-C4-POS-002	C4.2	web	Duplicated form becomes a new independent entity (new ID, Version 1) Verify a saved duplicated form is fully independent of the original.	P1	high	draft	planned	PRE-DF-form-exists	md
Objective Verify a saved duplicated form is fully independent of the original. Preconditions See PRE-DF-form-exists And a duplicated form has been opened and modified Steps Save the duplicated form Expected Result Then the duplicated form has a new Form ID And it starts at Version 1 And changes to it do not affect the original form And the redirect after save opens the edit page of the new form (not the original) Source Traceability TSD: PK141 Section: C4 - Duplicate Form Scenario: C4.2 - Duplicated form is a new independent entity Acceptance Criteria: PRD C.15 Scenario 1-7 Evidence Required Form ID + version of duplicate; original unchanged. Notes / Gaps Default name carries a "(copy)" indicator (asserted in DFMOD-C4-POS-003).
▸DFMOD-C4-POS-003	C4.3	web	Duplicated form follows duplicate-specific naming, availability, and editable rules Verify duplicate-specific rules for default naming, availability, and editable configuration.	P2	medium	draft	planned	PRE-DF-form-exists	md
Objective Verify duplicate-specific rules for default naming, availability, and editable configuration. Preconditions See PRE-DF-form-exists And the source is duplicated from the list page Steps Open the duplicated form in the setup flow Expected Result Then the default name contains a copy indicator (e.g. "Stok harian (copy)") And editable configuration follows duplicate-specific rules And if the source availability was temporary, the duplicated period is an empty state per PRD And non-editable modification & approval config follows the documented default behavior Source Traceability TSD: PK141 Section: C4 - Duplicate Form Scenario: C4.3 - Naming, availability, editable rules Acceptance Criteria: PRD C.14 Scenario 4-7 Evidence Required Screenshot of default name + empty temporary period. Notes / Gaps No gap.
▸DFMOD-C4-NEG-005	C4.4	web	Validation failure on a duplicate never mutates the original form Verify a failed validation while saving a duplicate leaves the original form untouched.	P1	high	draft	planned	PRE-DF-form-exists	md
Objective Verify a failed validation while saving a duplicate leaves the original form untouched. Preconditions See PRE-DF-form-exists And a duplicated form has an invalid step Steps Attempt to save the duplicate with a validation failure on one step Expected Result Then save is blocked on the invalid step And the original form is not changed in any way Source Traceability TSD: PK141 Section: C4 - Duplicate Form Scenario: C4.4 - Validation/save (edge case) Acceptance Criteria: PRD C.15 Scenario 3-7 Evidence Required Original form state unchanged after duplicate validation failure. Notes / Gaps No gap.
▸DFMOD-C4-POS-004	C4.4	web	Duplicated form follows the same validation and save behavior as new creation Verify a duplicated form runs the same validation/save rules as creating a new form.	P1	medium	draft	planned	PRE-DF-form-exists	md
Objective Verify a duplicated form runs the same validation/save rules as creating a new form. Preconditions See PRE-DF-form-exists And a duplicated form is prefilled from the source Steps Change some configuration, then save In a separate run, save an untouched duplicate Expected Result Then the same validation rules as new-form creation run And save succeeds only when all steps are valid And the result is a new entity that does not change the source form And an untouched duplicate still saves as a valid new entity Source Traceability TSD: PK141 Section: C4 - Duplicate Form Scenario: C4.4 - Same validation and save behavior Acceptance Criteria: PRD C.15 Scenario 3-7 Evidence Required Validation parity vs new-form flow; new entity created. Notes / Gaps Validation-failure isolation from the original is covered by DFMOD-C4-NEG-005.
▸C5 Compound Modification mobile web
▸DFMOD-C5-POS-001	C5.1	web	CP user modifies compound config with form-builder-consistent behavior Verify compound editing behaves consistently with the form builder and warns on impactful changes.	P1	high	draft	planned	PRE-DF-compound-exists	md
Objective Verify compound editing behaves consistently with the form builder and warns on impactful changes. Preconditions See PRE-DF-compound-exists And the user opens the compound edit page from the list Steps Change general config, item source, info detail, question list, question config, or options Expected Result Then all interactions behave consistently with the form builder And validation rules stay enforced And a warning appears when a source change or input-type change impacts the structure Source Traceability TSD: PK141 Section: C5 - Compound Modification Scenario: C5.1 - Modify compound config consistently Acceptance Criteria: PRD C.16 Scenario 1-6, C.17 Scenario 1-7 Evidence Required Screen recording of compound edit + impact warning. Notes / Gaps Editing an option on a compound used by many forms must keep impact awareness visible.
▸DFMOD-C5-POS-002	C5.2	web	Compound version increments only on a meaningful change, ID stays Verify compound versioning bumps only on meaningful change while the Compound ID is stable.	P1	high	draft	planned	PRE-DF-compound-exists	md
Objective Verify compound versioning bumps only on meaningful change while the Compound ID is stable. Preconditions See PRE-DF-compound-exists Steps Save the compound without any change In a separate run, make a meaningful change (item config, guideline, question structure/config), then save In a separate run, change then revert to original, then save Expected Result Then a no-change save does not bump the version And a meaningful change bumps the compound version while the Compound ID stays the same And a change reverted to original does not bump the version And adding a new question creates a new Question ID Source Traceability TSD: PK141 Section: C5 - Compound Modification Scenario: C5.2 - Compound versioning on meaningful change Acceptance Criteria: PRD C.18 Scenario 1-8 Evidence Required Compound version + ID before/after each path. Notes / Gaps No gap.
▸DFMOD-C5-NEG-004	C5.3	web	Cancelling the compound impact confirmation propagates nothing Verify cancelling the impact confirmation makes no changes to affected forms.	P1	high	draft	planned	PRE-DF-compound-exists	md
Objective Verify cancelling the impact confirmation makes no changes to affected forms. Preconditions See PRE-DF-compound-exists And the impact confirmation modal is shown for an impactful change Steps Choose Cancel Expected Result Then there is no propagation to affected forms And the compound change is not committed Source Traceability TSD: PK141 Section: C5 - Compound Propagation Scenario: C5.3 - Impact confirmation (cancel) Acceptance Criteria: PRD C.20 Scenario 1-6 Evidence Required Affected forms unchanged after cancel. Notes / Gaps No gap.
▸DFMOD-C5-POS-003	C5.3	web	Saving an impactful compound shows impact modal and confirm propagates Verify an impactful compound save shows scope and, on confirm, propagates versions to affected forms.	P0	critical	draft	planned	PRE-DF-compound-exists	md
Objective Verify an impactful compound save shows scope and, on confirm, propagates versions to affected forms. Preconditions See PRE-DF-compound-exists And the compound is used by one or more forms Steps Save an impactful change Choose Confirm Expected Result Then an impact confirmation modal appears showing the scope / count of affected forms And the user must explicitly choose Confirm or Cancel And on Confirm, the related version is propagated automatically to the affected forms Source Traceability TSD: PK141 Section: C5 - Compound Propagation Scenario: C5.3 - Save modified compound shows impact + confirmation Acceptance Criteria: PRD C.20 Scenario 1-6 Evidence Required Impact modal with affected count; propagation after confirm. Notes / Gaps Cancel path is covered by DFMOD-C5-NEG-004.
▸DFMOD-C5-POS-005	C5.4	mobile	Updated compound applies to new visitation only, not ongoing visits Verify a saved compound update reaches new visits but ongoing visits keep their snapshot.	P0	critical	draft	planned	PRE-DF-mobile-assigned	md
Objective Verify a saved compound update reaches new visits but ongoing visits keep their snapshot. Preconditions See PRE-DF-mobile-assigned And the compound was modified and saved Steps Start a new visitation Continue an ongoing visitation that started before the change Expected Result Then the new visitation uses the latest compound structure And the ongoing visit keeps the old snapshot for structure, order, validation, and submission And a deleted question does not suddenly disappear from the ongoing visit; a newly added question appears only in new visits Source Traceability TSD: PK141 Section: C5 - Runtime Safety Scenario: C5.4 - Updated compound for new visitation only Acceptance Criteria: PRD C.21 Scenario 1-5, M.4 Scenario 1-5, M.5 Scenario 1-5 Evidence Required New vs ongoing visit rendering after a compound update. Notes / Gaps No gap.
▸DFMOD-C5-POS-006	C5.5	mobile	Historical compound data stays audit-able after modification Verify submitted reports keep their old compound structure and answers after the compound changes.	P1	high	draft	planned	PRE-DF-submitted-report-exists	md
Objective Verify submitted reports keep their old compound structure and answers after the compound changes. Preconditions See PRE-DF-submitted-report-exists And the report was submitted with an older compound structure Steps Modify the compound afterwards Re-open the old submitted report Expected Result Then the submitted report still shows the old structure and answers And historical data does not change due to system-data updates or a new compound version And system-linked option values in the historical answer remain original Source Traceability TSD: PK141 Section: C5 - Runtime Safety Scenario: C5.5 - Historical compound data audit-able Acceptance Criteria: PRD M.6 Scenario 1-5 Evidence Required Historical report stable across repeated opens after a compound change. Notes / Gaps No gap.
▸C6 Availability Modification mobile web
▸DFMOD-C6-NEG-002	C6.1	web	Availability save blocked when end date is before current or period invalid Verify invalid availability periods are blocked at save.	P1	high	draft	planned	PRE-DF-cp-editing-form	md
Objective Verify invalid availability periods are blocked at save. Preconditions See PRE-DF-cp-editing-form Steps Set an end date before the current date, or otherwise an invalid period, then attempt to save Expected Result Then the system blocks the save with a validation message Source Traceability TSD: PK141 Section: C6 - Availability Modification Scenario: C6.1 - Availability validation Acceptance Criteria: PRD C.22 Scenario 1-5 Evidence Required Screenshot of blocked save with invalid period. Notes / Gaps Testing Concern TC-05 (High): exact rollover behavior at 23:59 → 00:00 (device date boundary) pending confirmation.
▸DFMOD-C6-POS-001	C6.1	web	Availability changes are accepted with latest config as source of truth Verify valid availability changes (permanent/temporary, extend/shorten) take effect with the latest saved config winning.	P1	high	draft	planned	PRE-DF-cp-editing-form	md
Objective Verify valid availability changes (permanent/temporary, extend/shorten) take effect with the latest saved config winning. Preconditions See PRE-DF-cp-editing-form Steps Switch permanent↔temporary, extend, or shorten the period, then save Adjust only the end date without changing the start date Expected Result Then the latest saved configuration becomes the source of truth And multiple sequential changes leave only the latest saved state in effect And adjusting the end date preserves the start date Source Traceability TSD: PK141 Section: C6 - Availability Modification Scenario: C6.1 - Availability change with valid logic Acceptance Criteria: PRD C.22 Scenario 1-5, C.23 Scenario 1-4 Evidence Required Saved availability config across sequential edits. Notes / Gaps Invalid-period blocking is covered by DFMOD-C6-NEG-002.
▸DFMOD-C6-EDGE-004	C6.2	mobile	Extending availability after expiry makes the form reappear for future visits Verify a previously expired availability that is extended makes the form available again for future visits.	P2	medium	draft	planned	PRE-DF-mobile-assigned	md
Objective Verify a previously expired availability that is extended makes the form available again for future visits. Preconditions See PRE-DF-mobile-assigned And the form's availability had expired Steps Extend the availability period Start a future visit Expected Result Then the form reappears and is available for future visits Source Traceability TSD: PK141 Section: C6 - Availability Modification Scenario: C6.2 - Availability (edge case) Acceptance Criteria: PRD M.7 Scenario 1-6 Evidence Required Form availability before/after extension. Notes / Gaps No gap.
▸DFMOD-C6-POS-003	C6.2	mobile	New visitation follows the latest availability rule Verify a new visit honors the latest availability window.	P1	high	draft	planned	PRE-DF-mobile-assigned	md
Objective Verify a new visit honors the latest availability window. Preconditions See PRE-DF-mobile-assigned And the availability configuration has changed Steps Start a new visit and check form visibility/accessibility against the period Expected Result Then the form is visible/accessible only within the availability period And a permanent form is always visible And the form is blocked before the start date or after the end date Source Traceability TSD: PK141 Section: C6 - Availability Modification Scenario: C6.2 - New visitation follows latest availability Acceptance Criteria: PRD M.7 Scenario 1-6 Evidence Required Visibility/blocking across boundary dates. Notes / Gaps Re-extension after expiry is covered by DFMOD-C6-EDGE-004. Day boundary follows device date (Testing Concern TC-05, High).
▸DFMOD-C6-POS-005	C6.3	mobile	Ongoing visit and history are unaffected by availability change Verify an availability change does not block an ongoing visit or historical reports.	P1	high	draft	planned	PRE-DF-mobile-assigned	md
Objective Verify an availability change does not block an ongoing visit or historical reports. Preconditions See PRE-DF-mobile-assigned And the employee started a visit while the form was valid Steps Change availability so the form becomes unavailable for new visits (including mid-fill) Open a historical report Expected Result Then the ongoing visit can still be accessed and submitted (even if the form goes unavailable mid-fill) And historical reports open without being checked against the availability rule Source Traceability TSD: PK141 Section: C6 - Availability Modification Scenario: C6.3 - Ongoing/history unaffected by availability change Acceptance Criteria: PRD M.8 Scenario 1-4, M.9 Scenario 1-4 Evidence Required Ongoing submit + history open after the form becomes unavailable. Notes / Gaps No gap.
▸DFMOD-C6-NEG-007	C6.4	web	Target rejects zero, negative, or invalid numeric values when enabled Verify invalid target values are rejected when target is enabled.	P1	high	draft	planned	PRE-DF-cp-editing-form	md
Objective Verify invalid target values are rejected when target is enabled. Preconditions See PRE-DF-cp-editing-form And target is enabled Steps Enter zero, a negative number, or a non-numeric value, then attempt to save Expected Result Then the system rejects the input and blocks save (a target value is required when enabled) Source Traceability TSD: PK141 Section: C6 - Target Modification Scenario: C6.4 - Target validation Acceptance Criteria: PRD C.24 Scenario 1-4 Evidence Required Screenshot of rejection for each invalid value. Notes / Gaps No gap.
▸DFMOD-C6-POS-006	C6.4	web	Target configuration validates and applies latest rule to new visits only Verify target config enable/disable/value saves correctly and the latest rule applies only to new visits.	P1	high	draft	planned	PRE-DF-cp-editing-form	md
Objective Verify target config enable/disable/value saves correctly and the latest rule applies only to new visits. Preconditions See PRE-DF-cp-editing-form Steps Enable target with a valid value, then save Disable target, then save Expected Result Then a target value is required when enabled And the latest target rule applies only to new visitation And with target disabled, submission is free without a minimum requirement And with target enabled, progress is shown clearly (e.g. 2/5) Source Traceability TSD: PK141 Section: C6 - Target Modification Scenario: C6.4 - Target configuration validated, latest rule for new visit Acceptance Criteria: PRD C.24 Scenario 1-4, C.25 Scenario 1-4, M.10 Scenario 1-5 Evidence Required Saved target config + new-visit behavior. Notes / Gaps Invalid target input rejection is covered by DFMOD-C6-NEG-007.
▸DFMOD-C6-POS-008	C6.5	mobile	Ongoing visit keeps its target snapshot and completion integrity Verify a mid-visit target change does not recalculate progress or regress completion of an ongoing visit.	P0	critical	draft	planned	PRE-DF-mobile-assigned	md
Objective Verify a mid-visit target change does not recalculate progress or regress completion of an ongoing visit. Preconditions See PRE-DF-mobile-assigned And the employee started a visit with a known target (or no target) Steps Raise, lower, disable, or enable the target mid-process Expected Result Then the ongoing visit's progress is not recalculated And a completed status does not regress And an incomplete visit does not auto-complete just because the target was lowered And a free-mode visit that becomes enabled in the backend is not restricted mid-visit Source Traceability TSD: PK141 Section: C6 - Target Modification Scenario: C6.5 - Ongoing visit keeps target snapshot Acceptance Criteria: PRD M.11 Scenario 1-4, M.12 Scenario 1-3, M.13 Scenario 1-4 Evidence Required Ongoing progress/completion before/after a mid-visit target change. Notes / Gaps No gap.
▸C7 Assignment Modification mobile web
▸DFMOD-C7-POS-001	C7.1	web	Assignment activation status affects future distribution only Verify changing assignment activation status only affects future distribution and preserves config.	P1	high	draft	planned	PRE-DF-cp-editing-form	md
Objective Verify changing assignment activation status only affects future distribution and preserves config. Preconditions See PRE-DF-cp-editing-form And assignment can be active or inactive Steps Change the status and confirm save Expected Result Then distribution to new visits follows the latest status And deactivation does not delete the configuration And ongoing visits do not change And save shows a confirmation modal before applying (with affected employee count when available) Source Traceability TSD: PK141 Section: C7 - Assignment Modification Scenario: C7.1 - Activation status affects future distribution Acceptance Criteria: PRD C.26 Scenario 1-3, C.33 Scenario 1-5 Evidence Required Distribution + config state before/after a status change. Notes / Gaps Testing Concern TC-04 (High): source-of-truth for the impacted employee count needs confirmation.
▸DFMOD-C7-NEG-003	C7.2	web	Specific assignment without a selected entity blocks save Verify save is blocked when a specific assignment has no entity selected.	P1	high	draft	planned	PRE-DF-cp-editing-form	md
Objective Verify save is blocked when a specific assignment has no entity selected. Preconditions See PRE-DF-cp-editing-form And assignment type is specific with no entity selected Steps Attempt to save Expected Result Then save is blocked until a valid entity is selected Source Traceability TSD: PK141 Section: C7 - Assignment Modification Scenario: C7.2 - Scope/type validation Acceptance Criteria: PRD C.28 Scenario 1-5 Evidence Required Screenshot of blocked save with no entity selected. Notes / Gaps No gap.
▸DFMOD-C7-POS-002	C7.2	web	Switching assignment scope/type resets dependent selections safely Verify changing assignment scope (channel/employee) or type (all/specific) resets dependent selections and requires valid reconfiguration.	P1	high	draft	planned	PRE-DF-cp-editing-form	md
Objective Verify changing assignment scope (channel/employee) or type (all/specific) resets dependent selections and requires valid reconfiguration. Preconditions See PRE-DF-cp-editing-form Steps Change the scope or type Expected Result Then previous dependent selections are reset And the user must complete a valid reconfiguration before save And changing all→specific does not leave the previous all-inclusive logic behind Source Traceability TSD: PK141 Section: C7 - Assignment Modification Scenario: C7.2 - Switching scope/type resets dependents Acceptance Criteria: PRD C.27 Scenario 1-3, C.28 Scenario 1-5, C.29 Scenario 1-5 Evidence Required Dependent selections reset on scope/type change. Notes / Gaps Specific-without-entity blocking is covered by DFMOD-C7-NEG-003.
▸DFMOD-C7-NEG-004	C7.3	web	Working-group filter stays valid and resilient to source-data deletion Verify WG/level/node filters surface clear empty/invalid states and reset invalid selections safely.	P1	high	draft	planned	PRE-DF-cp-editing-form	md
Objective Verify WG/level/node filters surface clear empty/invalid states and reset invalid selections safely. Preconditions See PRE-DF-cp-editing-form And assignment uses a WG/level/node filter Steps Make the hierarchy incomplete, have no WG, or delete selected data from the source Re-open Step 5 without modifying anything Expected Result Then the system shows a clear empty/invalid state And invalid selections are reset safely (partial deletion keeps valid selections, removes only invalid) And save is blocked if a required field becomes empty And re-opening Step 5 still detects the invalid state without user modification Source Traceability TSD: PK141 Section: C7 - Assignment Modification Scenario: C7.3 - Working-group filter resilient to deletion Acceptance Criteria: PRD C.30 Scenario 1-5, C.31 Scenario 0-5 Evidence Required Empty/invalid state + safe reset after source deletion. Notes / Gaps Testing Concern TC-09 (High): timing/transactional behavior when selected channel/WG data changes in the background needs confirmation.
▸DFMOD-C7-EDGE-006	C7.4	web	Channel status change before final save triggers revalidation Verify the system revalidates when channel status changes just before final save.	P2	medium	draft	planned	PRE-DF-cp-editing-form	md
Objective Verify the system revalidates when channel status changes just before final save. Preconditions See PRE-DF-cp-editing-form And a selected channel's status changes before the final Step 5 save Steps Attempt the final save after the channel status changed Expected Result Then the system revalidates against the new channel status before committing Source Traceability TSD: PK141 Section: C7 - Assignment Modification Scenario: C7.4 - Save at Step 5 (edge case) Acceptance Criteria: PRD C.32 Scenario 1-5 Evidence Required Revalidation triggered on channel-status change. Notes / Gaps Testing Concern TC-09 (High): background data-change timing/transactional behavior.
▸DFMOD-C7-POS-005	C7.4	web	Save at Step 5 validates, confirms, and commits all steps as one transaction Verify a Step 5 save validates all required config, confirms, and commits Step 1–5 atomically.	P0	critical	draft	planned	PRE-DF-cp-editing-form	md
Objective Verify a Step 5 save validates all required config, confirms, and commits Step 1–5 atomically. Preconditions See PRE-DF-cp-editing-form And the user changed data across Step 1 to Step 5 Steps Click Save in Step 5 Expected Result Then the system validates all required config And shows a confirmation modal before commit And after confirm, all valid changes from Step 1 to Step 5 are saved as one transaction Source Traceability TSD: PK141 Section: C7 - Assignment Modification Scenario: C7.4 - Save at Step 5 validate/confirm/commit Acceptance Criteria: PRD C.32 Scenario 1-5 Evidence Required Single-transaction commit across steps after confirm. Notes / Gaps Channel-status change before final save → revalidate (DFMOD-C7-EDGE-006). Exit without save discards all cross-step changes.
▸DFMOD-C7-POS-007	C7.5	mobile	Employee sees the form per the latest assignment on future visits Verify assignment changes reach future visits while ongoing visits and history are preserved.	P1	high	draft	planned	PRE-DF-mobile-assigned	md
Objective Verify assignment changes reach future visits while ongoing visits and history are preserved. Preconditions See PRE-DF-mobile-assigned And the assignment is changed so an employee is added or removed Steps Create a future visitation for included and excluded employees Expected Result Then included employees see the form And excluded employees do not see the form And earlier ongoing visits do not change And a removed employee can still finish an already-active ongoing visit and access historical reports Source Traceability TSD: PK141 Section: C7 - Distribution Impact Scenario: C7.5 - Employee sees form per latest assignment Acceptance Criteria: PRD M.14 Scenario 1-4, M.15 Scenario 1-2 Evidence Required Visibility per employee on future visits; ongoing/history preserved. Notes / Gaps No gap.
▸C8 Copy From Previous mobile
▸DFMOD-C8-NEG-001	C8.1	mobile	No previous submission shows error and allows manual input Verify the copy feature fails gracefully when there is no previous submission.	P2	medium	draft	planned	PRE-DF-mobile-assigned	md
Objective Verify the copy feature fails gracefully when there is no previous submission. Preconditions See PRE-DF-mobile-assigned And there is no previous submitted report on the selected channel Steps Tap "Salin Jawaban Sebelumnya" Expected Result Then the system shows an error explaining there is no previous data And the employee stays on the form page And no data is prefilled And normal manual input continues after dismissing the error Source Traceability TSD: PK141 Section: C8 - Copy From Previous Scenario: C8.1 - No previous submission Acceptance Criteria: PRD M.16 Scenario 1-2 Evidence Required Screenshot of error + form remains usable. Notes / Gaps Testing Concern TC-06 (Medium): behavior when the source report is on another channel needs confirmation.
▸DFMOD-C8-POS-002	C8.2	mobile	Copy always uses the latest submission with a confirmation modal Verify copy auto-selects the latest valid submission on the selected channel and confirms before applying.	P1	high	draft	planned	PRE-DF-submitted-report-exists	md
Objective Verify copy auto-selects the latest valid submission on the selected channel and confirms before applying. Preconditions See PRE-DF-submitted-report-exists And one or more valid previous submissions exist on the selected channel Steps Initiate the copy action Expected Result Then the system shows a confirmation modal And the selected source is the latest submitted report And the user does not need to choose the source manually And the modal shows enough source submission info to confirm Source Traceability TSD: PK141 Section: C8 - Copy From Previous Scenario: C8.2 - Copy takes latest submission Acceptance Criteria: PRD M.17 Scenario 1-3 Evidence Required Confirmation modal showing the latest source. Notes / Gaps No gap.
▸DFMOD-C8-POS-003	C8.3	mobile	Copied data is editable and the form can be completed normally Verify successfully copied data prefills only applicable fields and remains fully editable.	P1	high	draft	planned	PRE-DF-submitted-report-exists	md
Objective Verify successfully copied data prefills only applicable fields and remains fully editable. Preconditions See PRE-DF-submitted-report-exists And a copy has been confirmed and applied Steps Review the prefilled form and edit a copied field Expected Result Then all applicable fields contain copied data (incompatible fields are not filled) And the employee can edit any copied field And the employee can complete the form normally And an edited copied field becomes the source for the final submission Source Traceability TSD: PK141 Section: C8 - Copy From Previous Scenario: C8.3 - Copied data editable Acceptance Criteria: PRD M.17 Scenario 4-6 Evidence Required Prefilled + editable form leading to submit. Notes / Gaps No gap.
▸DFMOD-C8-NEG-004	C8.4	mobile	Version mismatch hard-blocks copy with no partial prefill Verify copy is fully blocked when the current form version differs from the previous submission's version.	P0	critical	draft	planned	PRE-DF-submitted-report-exists	md
Objective Verify copy is fully blocked when the current form version differs from the previous submission's version. Preconditions See PRE-DF-submitted-report-exists And the current form version differs from the previous submission's version Steps Tap "Salin Jawaban Sebelumnya" Expected Result Then the system blocks the copy action entirely (mismatch detected before any field is filled) And a message explains the form has been updated And the employee can continue manually with no partial copy Source Traceability TSD: PK141 Section: C8 - Copy From Previous Scenario: C8.4 - Version mismatch hard-block Acceptance Criteria: PRD M.18 Scenario 1-3 Evidence Required Blocked copy + message; no field filled. Notes / Gaps No gap.
▸DFMOD-C8-EDGE-005	C8.5	mobile	Copy failure leaves no partial prefill and allows retry or manual Verify a system failure during copy produces no partial prefill and a safe recovery.	P1	high	draft	planned	PRE-DF-submitted-report-exists	md
Objective Verify a system failure during copy produces no partial prefill and a safe recovery. Preconditions See PRE-DF-submitted-report-exists And the copy process is forced to fail during retrieve or apply Steps Initiate copy; the process fails Retry, or continue manual input Expected Result Then the system shows an error And no field is partially filled (form returns to its original state) And the employee can retry or continue manual input (a second failure is still safe) Source Traceability TSD: PK141 Section: C8 - Copy From Previous Scenario: C8.5 - System failure during copy Acceptance Criteria: PRD M.19 Scenario 1-3 Evidence Required No partial prefill after failure; safe retry. Notes / Gaps No gap.
▸DFMOD-C8-EDGE-006	C8.6	mobile	Copied deleted item/option is shown for awareness but fails on next/submit Verify copied data referencing a deleted compound item/option is shown for awareness but fails validation on next/submit.	P1	high	draft	planned	PRE-DF-submitted-report-exists	md
Objective Verify copied data referencing a deleted compound item/option is shown for awareness but fails validation on next/submit. Preconditions See PRE-DF-submitted-report-exists And copied data references a deleted compound item or deleted option Steps Render the form with copied data Tap Next or Submit Expected Result Then the previous value is still shown for awareness And opening info detail for a deleted item errors gracefully And validation fails on the invalid data, redirecting to the first invalid field with a highlighted error And after correcting the invalid answer, the error clears and the flow can continue Source Traceability TSD: PK141 Section: C8 - Copy From Previous Scenario: C8.6 - Deleted item/option awareness then fail Acceptance Criteria: PRD M.20 Scenario 1-6 Evidence Required Awareness render + validation failure + redirect to first invalid field. Notes / Gaps Invalid copied option must not be silently removed without user awareness.
▸DFMOD-C8-POS-007	C8.7	mobile	Copy usage is tracked accurately across multiple copies and draft resume Verify copy-usage tracking is accurate across multiple copies and draft-resume.	P1	high	draft	planned	PRE-DF-submitted-report-exists	md
Objective Verify copy-usage tracking is accurate across multiple copies and draft-resume. Preconditions See PRE-DF-submitted-report-exists And the employee uses copy at least once before submit Steps Copy (possibly multiple times, different sources), then submit; also exercise draft-resume Expected Result Then the submission is flagged as using copy-from-previous And the last confirmed source report is recorded as the source And multiple copies in one submission lifecycle count as a single usage And draft-resume preserves the usage flag And a failed/mismatched/no-data copy does NOT flag the submission as using copy Source Traceability TSD: PK141 Section: C8 - Copy From Previous Scenario: C8.7 - Copy usage tracking Acceptance Criteria: PRD M.21 Scenario 1-8 Evidence Required Submission copy flag + recorded source across the scenarios. Notes / Gaps Testing Concern TC-10 (Medium): whether the copy event is counted at submit only or also at draft save needs confirmation.
▸C9 Export Snapshot web
▸DFMOD-C9-POS-001	C9.1	web	Export preserves the snapshot version and answer values at submission Verify export keeps each submission bound to its submission-time form version and answers.	P1	high	draft	planned	PRE-DF-submitted-report-exists	md
Objective Verify export keeps each submission bound to its submission-time form version and answers. Preconditions See PRE-DF-submitted-report-exists And there are multiple submissions across several form versions Steps Export the report as a CP user after a later modification Expected Result Then each submission stays bound to the form version at submission And historical submissions do not change after a later modification And answer values reflect the values at submit, not the latest system state And system-based option answer values are not recalculated Source Traceability TSD: PK141 Section: C9 - Export Snapshot Scenario: C9.1 - Export preserves snapshot version Acceptance Criteria: PRD C.34 Scenario 1-4, C.35 Scenario 1-4 Evidence Required Exported rows bound to submission version. Notes / Gaps Testing Concern TC-12 (High): export metadata vs answer-snapshot behavior must be clearly distinguished in implementation and UAT. TC-07 (Medium): export scope in release verification pending PM.
▸DFMOD-C9-POS-002	C9.2	web	Dynamic metadata and answer snapshot are distinguished consistently in export Verify dynamic metadata may follow the latest system state while answers stay snapshotted.	P1	high	draft	planned	PRE-DF-submitted-report-exists	md
Objective Verify dynamic metadata may follow the latest system state while answers stay snapshotted. Preconditions See PRE-DF-submitted-report-exists And underlying system data (e.g. employee name) changes after submission Steps Export a report that contains metadata and answer sections Expected Result Then metadata defined as dynamic may follow the latest system state And stored answer values still follow the snapshot at submit And system-linked option values are not recalculated from the latest system data And mixed consistency within one export row is predictable and documented Source Traceability TSD: PK141 Section: C9 - Export Snapshot Scenario: C9.2 - Dynamic metadata vs answer snapshot Acceptance Criteria: PRD C.35 Scenario 1-4 Evidence Required Export row showing dynamic metadata vs frozen answers. Notes / Gaps Testing Concern TC-12 (High): metadata vs answer-snapshot distinction must be explicit.
▸DFMOD-C9-POS-003	C9.3	web	Export schema evolution is append-only and backward compatible Verify exporting across versions keeps existing columns and adds new structure append-only.	P1	high	draft	planned	PRE-DF-submitted-report-exists	md
Objective Verify exporting across versions keeps existing columns and adds new structure append-only. Preconditions See PRE-DF-submitted-report-exists And the form structure changed from one version to the next Steps Export combined submissions across versions, including non-compound↔compound and single↔subfield transitions Expected Result Then existing columns are preserved And new structure is added append-only And incompatible structure yields empty values while preserving old data And Question IDs stay consistent per the evolution rule Source Traceability TSD: PK141 Section: C9 - Version Integrity Scenario: C9.3 - Export schema evolution append-only Acceptance Criteria: PRD C.36 Scenario 1-8 Evidence Required Combined-version export preserving old columns + append-only new ones. Notes / Gaps Question-ID continuity + empty-value handling detailed in DFMOD-C9-POS-004.
▸DFMOD-C9-POS-004	C9.4	web	Question ID continuity and empty-value handling stay stable across versions Verify export keeps a consistent Question ID mapping and uses empty values (never overwrite) for incompatible rows.	P1	high	draft	planned	PRE-DF-submitted-report-exists	md
Objective Verify export keeps a consistent Question ID mapping and uses empty values (never overwrite) for incompatible rows. Preconditions See PRE-DF-submitted-report-exists And one question's structure changed across versions Steps Export combining old and new rows Expected Result Then a consistent Question ID mapping is preserved per the evolution rule And rows incompatible with the latest structure produce empty values, not overwriting old data And all versions remain analyzable in one export without losing historical meaning And single→subfield→single and compound→non-compound do not corrupt old columns Source Traceability TSD: PK141 Section: C9 - Version Integrity Scenario: C9.4 - Question ID consistency and empty-value handling Acceptance Criteria: PRD C.36 Scenario 6-8 Evidence Required Export with stable Question IDs + empty (not overwritten) incompatible cells. Notes / Gaps No gap.
▸C10 Activity Log web
▸DFMOD-C10-POS-001	C10.1	web	Compound activity log shows timeline, before-after, and immutable snapshots Verify the compound activity log timeline, snapshots, and before→after change display.	P2	medium	draft	planned	PRE-DF-compound-exists	md
Objective Verify the compound activity log timeline, snapshots, and before→after change display. Preconditions See PRE-DF-compound-exists And the user opens the activity log from the compound detail page Steps Load the activity log page Expected Result Then the timeline shows latest-first with actor, action type, and timestamp And create/edit events store a configuration snapshot at the time of the action And edit events show only changed fields in a before → after format And a nested compound change references the parent compound Source Traceability TSD: PK141 Section: C10 - Activity Log Scenario: C10.1 - Compound activity log timeline Acceptance Criteria: PRD C.37 Scenario 1-13 Evidence Required Screenshot of timeline + before/after diff. Notes / Gaps Large config sections need a "see more" affordance. Testing Concern TC-08 (Medium): final UI/"see more" behavior pending design.
▸DFMOD-C10-POS-002	C10.2	web	Form template activity log covers all impacted configuration layers Verify the form template activity log captures snapshots and field-level deltas across all change types.	P2	medium	draft	planned	PRE-DF-form-exists	md
Objective Verify the form template activity log captures snapshots and field-level deltas across all change types. Preconditions See PRE-DF-form-exists And the user opens the activity log from the form template detail page Steps Review entries for create, edit, version change, duplication, compound-related change, assignment change, and availability/target change Expected Result Then the system shows snapshots and relevant field-level deltas And question config is grouped by page And complex data (DB/filter config) is visible or expandable And deleted values appear as N/A And a duplicated form has its own activity entry Source Traceability TSD: PK141 Section: C10 - Activity Log Scenario: C10.2 - Form template activity log all layers Acceptance Criteria: PRD C.38 Scenario 1-16 Evidence Required Activity entries across each change type with grouped/expandable detail. Notes / Gaps Testing Concern TC-08 (Medium): final UI/"see more" behavior pending design.
▸DFMOD-C10-POS-003	C10.3	web	Activity log is read-only and snapshots stay immutable after later changes Verify existing activity log entries never change and the log is read-only.	P1	high	draft	planned	PRE-DF-form-exists	md
Objective Verify existing activity log entries never change and the log is read-only. Preconditions See PRE-DF-form-exists And an activity log entry exists for a compound or form Steps Make a further change after that activity Reload the activity log Expected Result Then old entries do not change And the log stays read-only (not editable from any UI) And an empty state shows clearly when there is no activity And reloading after a new edit leaves old entries identical Source Traceability TSD: PK141 Section: C10 - Activity Log Scenario: C10.3 - Activity log read-only and immutable Acceptance Criteria: PRD C.37 Scenario 9,12,13; C.38 Scenario 16-18 Evidence Required Old entry identical after a later change; no edit affordance. Notes / Gaps No gap.
▸DFMOD-C10-POS-004	C10.4	web	Activity log empty state and long-content handling stay usable Verify the activity log empty state and long/complex content remain usable and read-only.	P3	low	draft	planned	PRE-DF-form-exists	md
Objective Verify the activity log empty state and long/complex content remain usable and read-only. Preconditions See PRE-DF-form-exists And the activity log is empty in one case and has very long/complex config in another Steps Open the activity log detail page in each case Expected Result Then an informative empty state shows when there is no activity And a see-more / expanded view is available for long content (large DB/filter config not truncated without an expand option) And all detail stays read-only and represents the snapshot at activity time And empty states are consistent between compound log and form log Source Traceability TSD: PK141 Section: C10 - Activity Log Scenario: C10.4 - Empty state and long-content handling Acceptance Criteria: PRD C.37 Scenario 6,12,13; C.38 Scenario 15,17,18 Evidence Required Empty state + expandable long content, both read-only. Notes / Gaps Testing Concern TC-08 (Medium): final "see more" behavior pending design.

Sections — what each C-group tests

Coverage by C-section

Distribution

Precondition composition

Flows — journeys

Suites — run sets

Testcases

Objective

Preconditions

Steps

Expected Result

Source Traceability

Evidence Required

Notes / Gaps

Objective

Preconditions

Steps

Expected Result

Source Traceability

Evidence Required

Notes / Gaps

Objective

Preconditions

Steps

Expected Result

Source Traceability

Evidence Required

Notes / Gaps

Objective

Preconditions

Steps

Expected Result

Source Traceability

Evidence Required

Notes / Gaps

Objective

Preconditions

Steps

Expected Result

Source Traceability

Evidence Required

Notes / Gaps

Objective

Preconditions

Steps

Expected Result

Source Traceability

Evidence Required

Notes / Gaps

Objective

Preconditions

Steps

Expected Result

Source Traceability

Evidence Required

Notes / Gaps

Objective

Preconditions

Steps

Expected Result

Source Traceability

Evidence Required

Notes / Gaps

Objective

Preconditions

Steps

Expected Result

Source Traceability

Evidence Required

Notes / Gaps

Objective

Preconditions

Steps

Expected Result

Source Traceability

Evidence Required

Notes / Gaps

Objective

Preconditions

Steps