BACHELOR OF COMPUTER APPLICATIONS (BCA)
Software Testing
ASSIGNMENT – 1
Documentation of Software Testing Life Cycle
(STLC)
for a Food Delivery Application
Submitted By:
Tanushree G.
Register Number:
U03CJ23S0109
Semester:
VI Semester
Subject:
Software Testing
Submitted To:
Prof. Samudyata D.S
College Name:
Dayananda Sagar College Of Arts, Science, Commerce
Introduction to Software Testing Life
Cycle (STLC)
STLC begins with understanding system requirements and
identifying testable components. Based on these
requirements, a detailed test plan is prepared, followed by
designing and developing test cases. After setting up the
testing environment, test cases are executed to identify
defects or inconsistencies in the system. Any detected
defects are documented and tracked until they are resolved.
Finally, testing activities are concluded with a test closure
report summarizing overall testing outcomes.
In modern applications such as food delivery platforms,
testing plays a crucial role because users depend on real-
time services like restaurant search, online payment, and
order tracking. Any failure in these modules may lead to
financial loss or poor user experience. Therefore, applying
STLC ensures that the application performs reliably,
securely, and efficiently across different devices and usage
scenarios.
This document presents a detailed implementation of the
Software Testing Life Cycle (STLC) for a Food Delivery
Application, covering all testing phases including
requirement analysis, test planning, test case development,
environment setup, test execution, defect reporting, and test
closure.
Requirement Analysis Report
Objective
The objective of the Requirement Analysis phase is to
understand the system features and identify the functionalities
that need to be tested. This phase helps testers analyze
requirements and determine testable components of the
application.
Overview of Selected System
The selected system is a Food Delivery Application that allows
users to search restaurants, order food online, make payments,
track deliveries, and provide feedback. The application
connects customers, restaurants, and delivery personnel
through an online platform. Proper testing is required to
ensure accurate order processing, secure payments, and
smooth user experience.
Functional Requirements
• The system must support the following functionalities:
• Users should be able to register and log in using valid
credentials.
• Users can search restaurants based on location and
cuisine.
• Users can add, update, or remove food items from the
cart.
• The system should calculate total price automatically.
• Users must be able to complete payments using online
payment methods.
• Order status should be displayed and updated in real
time.
• Users should be able to submit ratings and feedback after
delivery.
Non-Functional Requirements
• Performance
Application should respond quickly and handle multiple
users simultaneously.
• Security
User data and payment information must be protected.
Unauthorized access should be prevented.
• Usability
Interface should be simple and easy to navigate.
• Reliability
Orders must be processed without data loss or system
failure.
• Compatibility
Application should work across different browsers and
devices.
Identification of Testable Requirements
• The following requirements are identified for testing:
• Login validation using valid and invalid inputs.
• Restaurant search accuracy.
• Cart operations and price calculation.
• Payment success and failure scenarios.
• Order tracking updates.
• Feedback submission validation.
• Performance and security verification.
Test Planning Document
Objective
The objective of the Test Planning phase is to plan the overall
testing strategy, define testing goals, allocate resources, and
establish guidelines for executing testing activities effectively.
Scope of Testing
• The testing process will focus on verifying the major
modules of the Food Delivery Application, including:
• User login and authentication
• Restaurant search functionality
• Add to cart operations
• Payment processing
• Order tracking system
• Feedback submission
• Testing will ensure that all functionalities work correctly
and meet performance and security requirements.
Testing Objectives
• To verify that all application features function as
expected.
• To identify defects before system deployment.
• To ensure secure and reliable payment processing.
• To validate system performance during normal and peak
usage.
• To improve overall user experience and system stability.
Types of Testing
• Unit Testing
Individual modules such as login, cart, and payment are
tested independently.
• Integration Testing
• Interaction between modules (e.g., cart to payment,
payment to order tracking) is verified.
• System Testing
• The complete application is tested as a whole to validate
end-to-end functionality
Resources Required
• Human Resources
• Test Engineer / Tester
• Hardware Requirements
• Computer or laptop with internet access
Software Requirements
• Operating System: Windows 10 or above`
• Browser: Google Chrome / Microsoft Edge
• Database: MySQL or MongoDB
• Testing Tools: Browser Developer Tools (manual testing)
Entry Criteria
• Application build is completed and deployed.
• Requirements documentation is available.
• Test environment is ready.
Exit Criteria
• All planned test cases are executed.
• Critical defects are resolved.
Test Cases Document
Objective
The objective of the Test Case Development phase is to design
detailed test cases based on system requirements to verify that
each module of the Food Delivery Application functions
correctly under different conditions.
Test Scenarios
1. The following test scenarios are identified for the Food
Delivery Application:
2. Verify user login functionality.
3. Validate restaurant search results.
4. Verify adding food items to cart.
5. Validate cart quantity and price calculation.
6. Verify successful payment processing.
7. Validate failed payment handling.
8. Verify order tracking updates.
9. Validate feedback submission.
[Link] system behavior with invalid inputs.
11. Verify boundary conditions such as minimum and
maximum item quantity.
Test Data Preparation
Test data is prepared to validate different system behaviors:
• Valid user credentials
• Invalid login details
• Available and unavailable restaurants
• Different food item quantities
• Valid and invalid payment details
• Minimum and maximum input values
Test DESCRIPTION INPUT EXPECTED ACTUAL STATUS
Case RESULT RESULT
ID
TC01 Login with valid Valid email & User logged in As Expected Pass
credentials password successfully
TC02 Login with invalid Valid email + Error message As Expected Pass
password wrong displayed
password
TC03 Login with empty Blank input Validation As Expected Pass
fields message shown
TC04 Search restaurant by Restaurant Matching As Expected Pass
name keyword restaurants
displayed
TC05 Search unavailable Invalid No results found As Expected Pass
restaurant keyword message
TC06 Add item to cart Select food Item added As Expected Pass
item successfully
TC07 Increase item Quantity = 2 Total price As Expected Pass
quantity updated correctly
TC08 Remove item from Remove Item removed As Expected Pass
cart selected item from cart
TC09 Boundary test – Quantity = 1 Order accepted As Expected Pass
minimum quantity
TC10 Boundary test – Quantity = 10 System accepts As Expected Pass
maximum quantity items limit
TC11 Successful payment Valid payment Payment As Expected Pass
details completed
successfully
TC12 Payment failure Invalid card Payment failure As Expected Pass
details message
TC13 Cancel payment Cancel Order not placed As Expected Pass
midway transaction
TC14 Order tracking status Place order Status updates As Expected Pass
update displayed
TC15 Feedback submission Valid rating & Feedback As Expected Pass
comment submitted
TC16 Empty feedback Blank Validation As Expected Pass
submission feedback message shown
TC17 Invalid payment Wrong card Error displayed As Expected Pass
format number format
TC18 High user load Multiple orders System responds As Expected Pass
simulation normally
TC19 Session timeout Idle user User logged out As Expected Pass
check session automatically
TC20 Logout functionality Click logout User redirected to As Expected Pass
login page
Environment Setup Description
Objective
The objective of the Test Environment Setup phase is to
prepare the necessary hardware and software configuration
required to perform testing activities efficiently
Operating System
Windows 10 or higher is used as the operating system for
executing and testing the Food Delivery Application.
Browser
• Google Chrome
• Microsoft Edge
• These browsers are used to verify application
compatibility and user interface functionality.
Database
MongoDB / MySQL database is used to store user information,
restaurant details, orders, and payment records required for
testing.
Software Tools
• Web Browser Developer Tools (for inspection and
debugging)
• Visual Studio Code (for application execution)
• [Link] environment (for backend testing)
• Internet connection for accessing the application
Test Execution Report
Objective
The objective of the Test Execution phase is to execute the
prepared test cases and record the results to verify whether
the Food Delivery Application functions as expected.
Test Execution Activities
During this phase, the designed test cases were executed in the
prepared test environment. The following activities were
performed:
• Test cases were executed based on predefined inputs.
• Results were compared with expected outcomes.
• Each test case was marked as Pass or Fail.
• Defects identified during testing were documented for
further analysis.
• Screenshots were captured where necessary for
reference.
Test Execution Summary
• Total Test Cases Executed: 20
• Test Cases Passed: 18
• Test Cases Failed: 2
• Defects Identified: 2
Defect Report
Objective
The objective of the Defect Reporting phase is to identify,
document, and track defects found during test execution to
ensure the application functions correctly after fixing the
issues.
Defect Report Table
Bug ID Module Description Severity Status
Payment Payment successful but confirmation message not
BUG01 High Open
Module displayed
BUG02 Order Tracking Order status not updating in real time High Open
System allows login with incorrect password after
BUG03 Login Module High Open
multiple attempts
Total price not updated when item quantity
BUG04 Add to Cart Medium Fixed
changes
Feedback
BUG05 Empty feedback submitted without validation Low Fixed
Module
Severity Classification
• High: Affects core functionality or payment/security
operations.
• Medium: Affects functionality but has workaround.
• Low: Minor UI or validation issues.
Test Summary Report
Objective
The objective of the Test Closure phase is to finalize all testing
activities, evaluate testing outcomes, and prepare a summary
report of the overall testing process.
Test Summary
• Total Test Cases Executed: 20
• Total Test Cases Passed: 18
• Total Test Cases Failed: 2
• Total Defects Found: 5
• High Severity Defects: 3
• Medium Severity Defects: 1
• Low Severity Defects: 1
Lessons Learned
Proper requirement analysis helps in designing effective test
cases.
Early identification of defects reduces system risks.
Payment and authentication modules require strict testing due
to security concerns.
Performance testing is important for applications handling
real-time orders.
Overall Conclusion
The Software Testing Life Cycle (STLC) was successfully applied to the
Food Delivery Application to evaluate system functionality,
performance, and reliability. Most test cases passed successfully, and
identified defects were documented for correction. The testing process
ensured that the application meets functional and non-functional
requirements and provides a reliable user experience. After resolving
the reported defects, the system is considered ready for deployment.