Module 1: Task 3

Problem solving: Table

Standard data Extreme data Abnormal data
Valid types: Integers, Max and min value- this Validation – check the
strings, Boolean is to check for the smallest data before its processed
and largest integer or
floating number points in a
programme. Example,
INT_MAX / INT_MIN
Correct format: Empty/ Zero values- this Error handling- “try-
formatted structures such is used to see how a catch” blocks if an
as YYYY-MM-DD system reacts to empty expectation arises from
arrays or values such as 0 the abnormal data
or null.
Expected range: this is Overflow and Logging- keeping track of
number data that is underflow- this is to the abnormal data and
acceptable or logical check how the program issues in the program
range, such as choosing a behaves when arithmetic
number between 0 and operations exceed the
100. overflow or underflow
value a data type can
hold.
No unexpected range: Extremely large inputs-
this is text data that does this is to see if a system
not have any special can handle load by
characters that may providing large datasets or
interfere with processing. inputs.
Extremely high or low
frequencies- these tests
how well the program can
perform under abnormal
speeds of input.

Abnormal data: This refers to data that doesn’t conform to the typical
patterns, values and formats. Handling abnormal data is important in
making sure there is stability of software. Abnormal data often leads to
things such as bugs and vulnerabilities in a programme.
Extreme data: This refers to inputs such as upper or lower limits. This is
often used when testing software and how it behaves under stressful
conditions. This can help identify a system failure.
Standard data: This is the data that performs in a predicted manner,
follows patterns and is within the boundaries of the accepted inputs and
processing.
Get tiled online retail furniture store test plan
Introduction
This test plan outlines the testing for an online furniture store. This
program includes features such as managing stock (new and existing),
running reports and additional functions such as search, filtering, user
management and transactions. The objective of this test plan is to ensure
that the program operates as expected, handling various functions
related to stock management, reporting and other operations. The test
also aims to identify any defects, validate functions and verify the
performance of the program under typical or abnormal conditions.

Scope
 new stock management
 existing stock
 report generation
 search and filter
 user management
 transaction processing

Testing approach
This testing approach will include manual testing for user workflow and
automated testing for tasks such as report generation.
 Unit testing: ensuring sections like adding new stock work correctly.
 Integration testing: ensuring that sections interact properly with one
another.
 System testing: ensuring the whole program works overall
 Regression testing: ensuring that new features don’t mess with
existing features.
 Performance testing: ensuring the speed and scalability of the
program works especially for report generation and large stock
upkeep.
 Usability testing: ensuring the program is easy for users to navigate
and understand.
Features to be tested
New stock management
 Add new stock: Validate fields such as product name, description,
price, quantity and category. Ensure stock is added properly. Flag
duplicated SKUs.
 Update stock information: Editing product details, ensure data
continues after editing.
 Stock images: functionality of image upload, verify image size and
format.
Existing stock management
 View existing stock: stock is to be displayed with all the relevant
details.
 Editing existing stock: verify price adjustments, quantity of stock is
to be updated once a sale has been made.
 Delete stock: make sure deleted items no longer appear in the
search results or reports.
 Inventory control: make sure low stock is identified after a certain
number of sales have been made.
Reporting
 Sales reports: generation of sales reports should be done according
to date, range, product, category and salesperson.
 Inventory reports: make sure the reports show any available stock
quantities and check for any low stock reports.
 Custom reports: these custom reports should include aspects such
as supplier, brand, rating and product.
Search and filtering
 Testing search by product name, SKU (stock keeping unit- usually
has 8 alphanumeric digits which are like the products own “ID”
number) and category.
 Ensure accurate results with misspelled words.
 Filtering: filtering stock by price, range, availability and category.
Ensure filtering works together when applied.
User management
  Adding new users: ensure that new users can be added with the
appropriate roles such as admin, sales, warehouse and customer.
 User permissions: verify that users who have different roles have
correct access to features for example sales can view stock, admin
can add or delete stock and customers can browse stock.
 Password management: testing password reset, change and
validation.
Transaction processing
 Testing complete sales workflow from adding items to cart and to
finalize a transaction.
 Verify successful payments and failed payments.
 Notifications: testing email and in-system notifications for low stock,
new stock and payment completions.
 Backup and restore: verify that the system can back up stock and
restore it without data loss.

Testing data
Testing data will include the following: stock records such as furniture
items with various prices, categories and stock quantities. User roles such
as admin, sales staff, warehouse and customers with a variety of different
permission levels. Transactions such as sales data and report testing.
Testing environment
 Hardware: Retail store setup (Laptop: AMD Ryzen 5 Asus)
 Operating system: Windows
 Browser: Firefox/ Opera GX
 Database: MySQL
Test execution
Testing schedule
Week 1
Day 1 Setup and functional testing: set up the test
environment (serves, databases and tools)
Day 2 Testing that data is populated
Day 3 Testing invalid and valid inputs for user registration
Day 4 Testing login (correct and incorrect credentials,
password recovery and reset)
Day 5 Verify product categories
Day 6 Testing the search and filter functionalities
Day 7 Testing large product inventories

Week 2
Day 1 Shopping cart: can customers add remove products
Day 2 Updating quantities in cart and ensure pricing
calculations have been done correctly (e.g., discount,
tax and shipping price)
Day 3 Checkout: billing and shipping address validation
Day 4 Different shipping options: local, provincial and
international
Day 5 Payment testing: Credit, debit or COD (cash on
delivery)
Day 6 Testing successful or failed payments
Day 7 Check for any security breaches or measures like
encryption

Week 3
Day 1 User interface and user experiences testing: ensure
that all visual elements work on different browsers and
devices.
Day 2 Check for accessibility and responsiveness
Day 3 Security testing: test for any vulnerabilities by using
MySQL
Day 4 Make sure data privacy is compliant
Day 5 Performance testing: test how the site handles multiple
users as load testing
Day 6 Stress testing
Day 7 Stress testing
 Week 4
Day 1 Integration testing: hipping provides integration (third-
party)
Day 2 Make sure that there is a smooth data exchange across
systems
Day 3 Provide access to select users for real-world testing
(UAT)
Day 4 Look for any issues and collect feedback
Day 5 Fix bugs found during testing
Day 6 Retest to make sure issues have been resolved and
don’t occur again
Day 7 Retest to make sure issues have been resolved and
don’t occur again

Week 5
Day 1 Regress testing: performing final tests of all features to
ensure nothing is out of order
Day 2 Regress testing: performing final tests of all features to
ensure nothing is out of order
Day 3 Validate database and server configuration (the pre-go
live tests)
Day 4 Validate database and server configuration (the pre-go
live tests)
Day 5 Testing back up and recovery
Day 6 Going live: run the system in production
Day 7 Monitor for any issues during the live environment. If
any issues occur the system needs to be shut down
and tested all over again.