CartSure Requirement Analysis Phase

Business Scenario

Today is the 4th day of our project journey.

We are in the Requirement Analysis Phase for CartSure, a real-time eCommerce web application.

Our focus is on analyzing client requirements and critical features like registration, product search, cart, checkout, and payment.

This phase builds the foundation for an effective Testing Strategy & STLC Setup.

Pre-Lab Preparation

Topic : Testing Techniques

  •  Black Box vs White Box
  •  Equivalence Partitioning
  •  Boundary Value Analysis
  •  Decision Table & State Transition
git pull origin branchName

Git Pull

Task 1: Review functional requirements

  • Users must be able to register with email, password, and personal details.

  • Users must be able to login with valid credentials.

  • The system must display an error message for invalid credentials.

  • Users should be able to reset passwords via email.

  • The system should maintain a session until logout.

  • Users should be able to logout successfully.

Product Browsing Module

b

 Login / Registration Module [Refer images above]

a

 Login / Registration Module [Refer images above]

a

  • Users should be able to search products by name, category, or keyword.

  • Users should be able to filter products by price, brand, rating, or category.

  • Users should be able to sort products (e.g., price low to high, popularity).

  • Product detail page should display image, price, description, stock availability, reviews.

  • System should handle no results found gracefully.

  • Users should be able to add products to the cart.

  • Users should be able to remove products from the cart.

  • Users should be able to update product quantity in the cart.

  • The cart should display subtotal, taxes, shipping charges, and total amount.

  • Carts should retain items until checkout or user logout.

Users should be able to proceed to checkout from the cart.

Checkout & Payment Module

d

Shopping Cart Module

c

  • Users must be able to enter a shipping address.

  • Users should be able to select a payment method (Credit/Debit Card, Wallet, UPI, etc.).

Entry Criteria: Test plan approved

Exit Criteria: Test cases and test data ready

d

Test Environment Setup

Example for CartSure:

  • Setup QA server with CartSure app installed

  • Database seeded with products and test users

  • Browsers: Chrome, Firefox

  • Devices: Desktop and Mobile

Test Case IDModuleScenarioTest Data Expected Result
TC_001LoginValid LoginUsername: User1,
Password: Pass123
User logged in successfully
TC_002LoginInvalid LoginUsername: User1,
Password: Wrong123
Error Message Displayed
TC_003CartAdd to CartProduct: iPhone 14Item added to cart

Entry Criteria: Test cases ready
Exit Criteria: Environment ready

d

Test Execution

Example for CartSure:

  • Execute TC_001 → Login successful → Pass

  • Execute TC_002 → Error message appears → Pass

  • Execute TC_007 → Item added to cart → Pass

  • If a bug occurs (e.g., product price not updating in cart), log in Jira

Entry Criteria: Stable build available
Exit Criteria: All test cases executed; defects logged & retested

Test Closure

e

Example for CartSure:

  • Prepare Test Summary Report:

    • Total test cases: 50

    • Passed: 47

    • Failed: 3

  • Lessons learned: Checkout module needs additional performance testing

Sign-off: Stakeholders approve testing completion

Entry Criteria: Test execution completed
Exit Criteria: Testing closure report ready and signed off

Task 2: Define Entry & Exit Criteria

Entry Criteria

  • Requirements approved

  • Test plan ready

Exit Criteria

  • All test cases executed

  • Critical defects fixed

  • Test summary report completed

  • Stakeholder approval received

  • Test environment available

  • Test data prepared

Task 3:Identify Testing Types

Testing TypeCartSure Example
FunctionalCheck login, add to cart, checkout work correctly
IntegrationAdd to cart --> Proceed to checkout --> Validate price & item
RegressionAfter bug fix in login, retest other login scenerios
UATBusiness user tests product browsing & checkout flow
Performace100 users browse & checkout simultaneously
SecurityCheck user password encryption & secure payment

Objective

  • Ensure CartSure application meets functional, integration, performance, and security requirements.

  • Identify and resolve defects early to deliver a high-quality product.

Create testing strategy outline

Scope

In-Scope:

  • Login module

  • Product Browsing module

  • Cart module

  • Checkout module

  • Integration and end-to-end workflows

Out-of-Scope:

  • Internal systems of third-party payment gateways

  • Non-critical cosmetic UI issues

 Testing Approach

  • Manual Testing: Validate functional workflows and UI/UX.

  • Regression Testing: Re-run tests after bug fixes.

  • Automation Testing (optional): For repeated regression test scenarios.

  • Performance Testing: Verify system under load (optional).

  • Security Testing: Ensure secure login, payment, and data protection.

Components of test Strategy Document :

Output

  • Testing strategy document

​Test Strategy Template

These are the most common sections:-

1. Objective

State the objectives of this document at a high-level

2. Scope

State the scope of the testing strategy, what will the testing concentrate around, at high-level; leave details for the Testing Scope.

3. Test Deliverables 

State the testing activities and what documents result from these activities; for example a testing activity is Test Planning and the document resulting is the Master Test Plan or Test Plan

4. Testing Schedule

Give the timelines around which the project is planned and where testing fits in this schedule. I find that a diagram has a high-impact on the user (a Georgia rule of thumb is that I use color and diagrams to break the boredom of the text). Describe the diagram in words.

5. Test Scope

The Project Charter or Master Test Plan usually state all the items in scope, just copy and paste from these documents. Add anything that's missing or has changed from the last review. Then state any items that are Out of Scope.

6. Risk Analysis

State all the risk that you envision, the higher the risk the higher the test priority. When you start testing you will want to start with the high-priority items, then test medium-priority and if time permits test low-priority functionality.