## 🔎 Phase 1: Audit Scope Definition Objective: Establish exactly what will be tested. | Area | Sample scope | | ----------------- | ---------------------------------------------- | | Platforms | Web, iOS, Android | | Screens | Login, search, cart, checkout, confirmation | | Critical workflow | Login → Search → Add to cart → Pay | | Shared rules | Validation, pricing, cart totals, order status | | Exclusions | Admin dashboard and seller portal | | Evidence | Hypothetical observations only | Coverage matrix | Workflow | Web | iOS | Android | | -------------------- | ------- | ------- | ------- | | Login | Planned | Planned | Planned | | Search | Planned | Planned | Planned | | Cart | Planned | Planned | Planned | | Checkout | Planned | Planned | Planned | | Payment confirmation | Planned | Planned | Planned | Result: Scope is defined. Actual coverage is not yet measured because no real execution evidence is available. ## 🧭 Phase 2: Expected Behavior Baseline Define the expected results before comparing platforms. | Test scenario | Expected behavior | | ------------------- | --------------------------------------------------------------------------- | | Valid login | User reaches the home screen | | Invalid login | Clear validation message appears | | Product search | Equivalent queries return consistent results under the same data conditions | | Add to cart | Correct product and quantity appear | | Price calculation | Subtotal, discounts, taxes, and shipping follow the same business rules | | Invalid payment | Clear error; no duplicate order | | Successful payment | One confirmed order appears | | Session restoration | Cart and order state follow documented persistence rules | Sample rule: If a product costs ₹1,000 and a ₹100 discount applies, the subtotal after discount should be ₹900 before any additional taxes or charges. Result: Baseline defined. Requirements concerning tax, shipping, and discount ordering need confirmation from the actual product specification. ## 🧩 Phase 3: Cross-Platform Component Mapping | Component | Web | iOS | Android | | -------------- | -------------- | ---------------------- | ---------------------- | | Login form | Web form | Native form | Native form | | Search | Search field | Search control | Search control | | Cart | Cart page | Cart screen | Cart screen | | Checkout | Web checkout | Native checkout UI | Native checkout UI | | Error feedback | Inline message | Inline/native feedback | Inline/native feedback | Potential issue: A button can look identical across platforms but behave differently when tapped, clicked, or submitted using a keyboard. Test: Map each equivalent component to its requirements and verify its behavior independently. Result: Component mapping is proposed; implementation equivalence remains unverified. ## 🖱️ Phase 4: Interaction Behavior Parity Sample test cases - INT-01: Click or tap Add to Cart once. Expected: quantity increases by one. - INT-02: Activate Add to Cart repeatedly. Expected: behavior follows the documented quantity and request-handling rules. - INT-03: Submit checkout twice rapidly. Expected: no duplicate order or charge. - INT-04: Press Enter on the login form. Expected: the documented submission behavior occurs. - INT-05: Dismiss a payment dialog. Expected: cancellation does not falsely mark the order as paid. Hypothetical finding: The web checkout prevents duplicate submissions, but the Android checkout allows repeated submission. - Classification: Functional behavior mismatch. - Potential severity: High if it creates duplicate charges or orders. - Evidence status: Unverified; this is a sample scenario. - Next step: Reproduce on Android and inspect order and payment records. ## 🔄 Phase 5: State Transition Consistency Check whether application states remain consistent during normal use and interruptions. | Starting state | Action | Expected state | | ---------------- | ------------------------ | ----------------------------------------- | | Empty cart | Add product | Cart contains product | | Cart populated | Change quantity | Updated quantity and totals | | Checkout loading | Payment succeeds | Order confirmed once | | Checkout loading | Payment fails | Error state with recovery option | | Cart populated | Navigate away and return | State restored according to specification | | Payment pending | App resumes | Actual payment status is reconciled | Important edge case: A payment timeout does not necessarily mean the payment failed. The app should verify the transaction status before allowing a potentially duplicate payment. Result: State-transition requirements are outlined; actual state synchronization is not tested. ## 🧾 Phase 6: Form and Validation Parity Sample validation tests | Input | Expected result | | ------------------------------- | ----------------------------- | | Empty email | Required-field validation | | Malformed email | Invalid-format message | | Empty password | Required-field validation | | Invalid address | Relevant address validation | | Missing required checkout field | Submission blocked | | Valid form | Submission allowed | | Server rejects payment | Clear error and safe recovery | Potential mismatch: iOS accepts an address field that Android rejects. Classification: Validation mismatch. Recommended fix: Define common business validation rules and implement them consistently, while retaining appropriate platform-specific keyboards and autofill behavior. Result: Validation test plan created. No actual validation failure has been established. ## 🧭 Phase 7: Navigation and User Journey Parity Critical journey: Login → Search → Product details → Cart → Checkout → Payment → Confirmation. Test these scenarios: 1. Navigate back from checkout to the cart. 2. Cancel payment and return to checkout. 3. Open a product through a deep link. 4. Lose network connectivity during payment. 5. Resume the app after an interrupted transaction. 6. Expire the session during checkout. 7. Refresh the confirmation page. Hypothetical finding: Android returns to the cart after successful payment, while web displays the confirmation screen. - Classification: Navigation mismatch. - Potential severity: Medium to High, depending on whether the order was actually placed and whether users can recover safely. - Evidence status: Unverified. - Reproduction: Complete a successful payment and record the final destination on each platform. ## 📐 Phase 8: Responsive Layout and Device Variation Test on supported screen sizes and device configurations. - Small and large mobile screens. - Browser zoom and dynamic text scaling. - Portrait and landscape orientations where supported. - Virtual keyboard visibility during checkout. - Sticky checkout buttons and scrolling. - Content overflow and clipped controls. - Safe areas and system insets. Hypothetical finding: The Android keyboard obscures the checkout button. - Classification: Responsive interaction defect. - Potential severity: Medium, potentially High if checkout cannot be completed. - Evidence status: Unverified. - Fix direction: Adjust scrolling, keyboard handling, and inset behavior. Do not assign pixel-level defects without screenshots or measurements. ## ♿ Phase 9: Accessibility and Input-Method Parity Test equivalent functionality using supported input methods. | Check | Acceptance criterion | | ------------------- | ----------------------------------------- | | Keyboard navigation | All essential web actions are reachable | | Focus visibility | Focus is clearly visible | | Screen reader | Controls have meaningful accessible names | | Form errors | Errors are associated with their fields | | Dialog handling | Focus is managed appropriately | | Touch targets | Meet applicable accessibility guidance | | Text scaling | Essential content remains usable | | Contrast | Meets applicable contrast requirements | Standards reference: WCAG 2.2 is a useful baseline for web accessibility; native apps also need platform-specific accessibility checks. Result: Accessibility coverage is specified, but actual compliance requires implementation inspection and manual assistive-technology testing. ## 🌐 Phase 10: Platform and Environment Differences Investigate differences caused by environments rather than immediately treating them as defects. - Browser engine and browser version. - iOS and Android versions. - Network latency and offline behavior. - Locale, currency, and timezone. - Keyboard and autofill conventions. - Permission prompts. - Third-party payment SDK behavior. - Font rendering and native navigation conventions. Example: A native iOS date picker looks different from a web date picker. That is not automatically a defect if both enforce the same date rules. Example: A ₹1,000 product displays as ₹1,000 on web but ₹1,100 on Android under identical conditions. This requires investigation of pricing rules, tax calculation, and API responses. Result: A cause-investigation checklist is ready; no platform-specific root cause is verified. ## 🧪 Phase 11: Parity Test Design Here is a reproducible sample test suite. PAR-001: Cart total consistency Priority: High · Platforms: Web, iOS, Android - Preconditions: Same product catalog, user, and pricing rules. - Steps: Add the same product and apply the same discount on each platform. - Expected: Identical business calculation and equivalent displayed total. - Evidence: Screenshots, API responses, and calculation logs. - Pass: All totals match the expected pricing rules. PAR-002: Duplicate payment protection Priority: Critical potential impact · Platforms: All - Preconditions: Test payment environment and transaction logging. - Steps: Submit checkout twice rapidly. - Expected: At most one successful charge and one order for the intended purchase. - Evidence: Payment-provider transaction IDs and order records. - Pass: No duplicate financial transaction or unintended order. PAR-003: Required-field validation Priority: High · Platforms: All - Preconditions: Checkout with required fields. - Steps: Leave one required field empty and submit. - Expected: Submission is blocked with an understandable error. - Evidence: Screen recording and validation logs. - Pass: The same business requirement is enforced on all platforms. PAR-004: Accessible checkout Priority: High · Platforms: All - Preconditions: Supported accessibility tools enabled. - Steps: Navigate fields, submit errors, and activate checkout without relying solely on touch. - Expected: Controls, errors, and actions remain understandable and operable. - Evidence: Screen recordings and accessibility inspection results. - Pass: Applicable accessibility criteria are met. Automation recommendation: Use Playwright for web journeys, Appium for cross-platform mobile automation where appropriate, and native accessibility tools for platform-specific checks. Execution status: Test cases designed, not executed. ## 🐞 Phase 12: Defect Classification and Severity Severity must reflect actual impact; evidence confidence is tracked separately. | Finding | Classification | Potential severity | Confidence | | -------------------------------------- | --------------------------------------------- | ------------------ | ---------- | | Duplicate successful payments | Functional mismatch | Critical | Unverified | | Incorrect cart total | Functional mismatch | High | Unverified | | Required field accepted inconsistently | Validation mismatch | High | Unverified | | Wrong post-payment destination | Navigation mismatch | Medium–High | Unverified | | Checkout button obscured | Responsive defect | Medium–High | Unverified | | Native date picker appearance differs | Intentional variation, if requirements permit | Low / not a defect | Unverified | Result: Sample severity register established. None of these examples should be reported as confirmed defects without supporting evidence. ## 🧠 Phase 13: Root-Cause Investigation Investigate causes systematically. | Symptom | Possible cause | Confirmation experiment | | -------------------- | --------------------------------------- | ---------------------------------------------- | | Different totals | Divergent calculation or stale API data | Compare API responses and calculation inputs | | Duplicate order | Missing idempotency protection | Inspect request IDs and payment records | | Different validation | Duplicated rules | Compare rules and boundary tests | | Lost cart state | State synchronization issue | Repeat navigation and resume tests | | Incorrect navigation | Divergent routing logic | Trace route transitions and transaction status | For every finding, document: - Verified facts. - Possible explanations. - Alternative causes. - Confidence level. - Experiment needed to confirm the cause. Result: Root-cause hypotheses are prepared, but no cause is confirmed. ## 🛠️ Phase 14: Remediation and Architecture Options | Problem | Recommended action | Validation | | ---------------------- | -------------------------------------------------------------- | ------------------------------------------------- | | Inconsistent pricing | Centralize authoritative pricing rules | Cross-platform pricing tests pass | | Duplicate payment risk | Use server-side idempotency and transaction reconciliation | Repeated requests do not create duplicate charges | | Validation differences | Share specifications and common test vectors | Boundary tests produce equivalent outcomes | | State loss | Improve persistence and server-state reconciliation | Navigation and resume tests pass | | Layout obstruction | Fix keyboard and inset handling | Checkout remains operable on supported devices | | Accessibility gaps | Add accessible labels, focus handling, and error announcements | Automated and manual accessibility checks pass | Trade-offs: Shared business logic improves consistency, but native controls and platform-specific UI adapters may still be necessary. Regression tests must cover both shared rules and platform-specific behavior. Rollback: Keep changes isolated, use feature flags where practical, and retain a tested recovery path for high-risk checkout changes. ## 📊 Phase 15: Coverage, Release Gates, and Validation Set proposed release criteria before implementation begins. Critical purchase workflows Proposed target ## 100% All defined critical scenarios must pass on every supported platform. Duplicate successful charges Release gate ## 0 No reproducible duplicate-charge defect in the defined test suite. Critical and High unresolved defects Proposed release policy ## 0 No unresolved Critical or High defects without a formally approved exception. Accessibility and regression Release gate ## Pass All defined mandatory checks must pass, and any exceptions must be documented and approved. These are proposed targets, not measured results. Release sign-off should include QA, engineering, product ownership, payment verification, and documented retesting. The one-week target does not override payment safety or mandatory accessibility requirements. ## 🏆 Phase 16: Final Parity Audit Report ## ShopEase — Sample Audit Report Inconclusive due to insufficient evidence Illustrative report · Hypothetical application · No real execution data supplied 1\. Executive summary A cross-platform audit plan has been created for login, search, cart, checkout, and payment confirmation. The highest-risk areas are payment duplication, pricing consistency, validation, and recovery from interrupted transactions. 2\. Scope and limitations Web, iOS, and Android are included. Real application builds, screenshots, logs, API traces, and executed test results are unavailable. 3\. Coverage matrix All five workflows are planned across three platforms. Actual execution coverage is not measured. 4\. Expected behavior baseline Business rules should be consistent, while permitted native-platform conventions may differ. 5\. Component comparison Equivalent forms, controls, navigation, checkout, and feedback states require verification. 6\. Findings and reproducibility Potential findings include inconsistent totals, duplicate submissions, validation differences, and incorrect post-payment navigation. All remain unverified. 7\. Evidence and confidence No real evidence supports a confirmed defect. Each hypothesis needs reproducible steps and supporting artifacts. 8\. Intentional differences versus defects Native appearance differences may be acceptable; differences affecting payment correctness, validation, or successful completion require investigation. 9\. Severity-ranked register Payment duplication is the highest potential risk, followed by pricing and validation errors. Severity must be reassessed when evidence is collected. 10\. Root-cause hypotheses Possible causes include divergent logic, inconsistent API handling, missing idempotency protection, and state synchronization problems. 11\. Recommended fixes Establish shared behavioral specifications, authoritative pricing, safe transaction handling, consistent validation, and platform-specific regression tests. 12\. Test cases PAR-001 through PAR-004 cover pricing, payment duplication, required-field validation, and accessible checkout. 13\. Accessibility and responsive risks Keyboard operation, screen-reader support, text scaling, touch targets, and keyboard-obscured controls need testing. 14\. Release gates Require successful critical workflows, no unresolved Critical or High defects without approved exceptions, and completed mandatory regression tests. 15\. Implementation roadmap - Days 1–2: Gather requirements, builds, logs, and baseline evidence. - Days 3–4: Execute critical parity tests and reproduce discrepancies. - Days 5–6: Fix confirmed high-risk issues and rerun regressions. - Day 7: Validate release gates, document exceptions, and obtain sign-off. This is a proposed schedule, not a guarantee that every defect can be fixed within one week. 16\. Final audit status Parity cannot yet be verified. The appropriate status is inconclusive due to insufficient evidence. ## ✅ Final sample test verdict ### Skill structure: Pass The skill defines 7 inputs, 16 audit phases, defect classification, remediation, release gates, and a final report format. ### Output completeness: Pass for this sample All 16 phases have been demonstrated using a hypothetical application and clearly labeled assumptions. ### Real-world validation: Pending Actual audit accuracy, evidence handling, and defect-detection reliability still need to be tested using real application artifacts. My assessment: This is a well-structured, detailed audit skill. Its strongest feature is the requirement to distinguish verified defects from hypotheses. The main limitation of this sample is that it tests the workflow and reporting structure, not the skill's actual performance against a real application.