Scribd
Upload
21 views5 pages

SRS - Draft

Uploaded by

imtihanrahman
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
21 views5 pages

SRS - Draft

Uploaded by

imtihanrahman
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 5

Software Requirements Specification (SRS) for:

Visual Testing Automation


1. Introduction

1.1 Purpose
The purpose of this document is to describe the software requirements for the ‘Visual
testing Automation’ project. This document is intended for the development team, project
managers, and other stakeholders involved in the project.

1.2 Scope
Visual Testing Automation is an automation tool that allows software testers to help
automate the UI testing to significantly reduce the QA time. It will include features such as
full-page visual testing, partial page visual testing, parallel execution, cross browser testing,
creating own acceptance criteria for passing/failing tests and other necessary
functionalities.

1.3 Definitions, Acronyms, and Abbreviations


- SRS: Software Requirements Specification
- UI: User Interface

- QA: Quality Assurance

- URL: Universal Resource Locator

- WDIO: WebdriverIO

1.4 References
- IEEE Standard for Software Requirements Specifications (IEEE 830-1998)
- Project Proposal Document

1.5 Overview
This SRS document provides a detailed description of the functional and non-functional
requirements for the Visual Testing project. It also includes an overview of the system
architecture, user interface, constraints, and acceptance criteria.

2. Overall Description

2.1 Product Perspective


Visual Testing Automation is a standalone web application specifically for software testers
to automate their testing process. The main application will run on NodeJS (Node.js® is a
JavaScript runtime built on Chrome's V8 JavaScript engine.) which will ask for the URL you
want to test and a base image to compare the page with.

The application will have the ability to process the inputs and pass commands to an
automated test script written in WDIO (browser and mobile automation test framework for
Node.js). Based on the command, the test script will run the test and return the report back
to the main app.

The script will integrate with third-party tools/frameworks such as BrowserStack or Sauce
Labs and certain image comparison tools to run the test.

2.2 Product Features


- Homepage: A form for entering the test URL and the base image. Testers can enter the URL
that they want to test in an input field as text input, can upload an image and then submit.
- Report page: A page shown after test execution which will display the detailed test report.
Essentially it will display 2 images side by side. 1 will be the base image and the other one is
the screenshot of the testing page containing colored markings of the pixels that do not
match with the base image.

- Region Exemption: Allows user to specify regions of a page that is included in the test to
ignore during comparison, which can be used for dynamically generated contents which are
not part of the test.

- Threshold/Match Setting: Enable users to set tolerance level for pixel differences, with
options ranging from Exact, High, Medium to Low according to necessity.

- Customize Reports: Allow users to customize the test report through specified metrics or
additional notes.

- User Management Page: A page where admins can manage user accounts, roles,
permissions and access levels.

-TBD

2.3 User Classes and Characteristics


- Guest Users: Can only access a landing page. This application will only be accessible to
registered users.
- Registered Users: Can access the homepage, submit the form and run the test.
- Admin Users: Can perform regular operations like other users, and handle user accounts.

2.4 Operating Environment


Visual Testing Automation will operate on web browsers such as Google Chrome, Mozilla
Firefox, and Safari. It will be hosted on a Linux server with NodeJS.
2.5 Design and Implementation Constraints
- The system must be developed using the MERN stack (MongoDB, Express.js, React.js,
Node.js).
- The system must comply with PCI DSS (Payment Card Industry Data Security Standard) for
handling payment information.

2.6 User Documentation


User documentation will include a user manual and a help section within the application.

2.7 Assumptions and Dependencies


- Users have a stable internet connection.
- The payment gateway integration depends on third-party services, which must be
functional for the application to process payments.

3. System Features

3.1 User Registration and Login


**Description:** The system shall allow users to register by providing their name, email
address, and password. Users can log in using their email and password.

**Functional Requirements:**
- FR1: The system shall validate the email format during registration.
- FR2: The system shall hash passwords before storing them in the database.

3.2 Book Search


**Description:** Users can search for books by title, author, genre, or ISBN.

**Functional Requirements:**
- FR1: The system shall allow users to enter search criteria in a search bar.
- FR2: The system shall display search results based on relevance.

3.3 Shopping Cart


**Description:** Users can add books to a shopping cart and proceed to checkout.

**Functional Requirements:**
- FR1: The system shall allow users to add or remove books from the shopping cart.
- FR2: The system shall calculate the total price, including taxes.

3.4 Payment Processing


**Description:** The system shall process payments using a third-party payment gateway.

**Functional Requirements:**
- FR1: The system shall integrate with PayPal and Stripe for payment processing.
- FR2: The system shall notify users of successful or failed transactions.
3.5 Order Management
**Description:** Users can view their order history and track the status of their orders.

**Functional Requirements:**
- FR1: The system shall display a list of past orders in the user's account.
- FR2: The system shall update the order status as it moves through processing, shipping,
and delivery.

4. Non-Functional Requirements

4.1 Performance Requirements


- The system shall handle up to 10,000 concurrent users without significant performance
degradation.
- Search results shall be displayed within 2 seconds.

4.2 Security Requirements


- The system shall use HTTPS for all communication between the client and server.
- User passwords shall be stored using a salted hash.

4.3 Usability Requirements


- The system shall have a responsive design to support various devices (desktop, tablet,
mobile).
- The UI shall be intuitive and user-friendly, requiring minimal training.

4.4 Reliability and Availability


- The system shall have an uptime of 99.9% to ensure availability to users.
- Data backups shall be performed daily to prevent data loss.

4.5 Scalability
The system shall be scalable to support future growth in user base and catalog size.

5. System Architecture

5.1 Overview
The Visual Testing will follow a client-server architecture with a RESTful API. The front-end
will be developed using React.js, and the back-end will use Node.js with Express.js.
MongoDB will be used as the database.

5.2 Data Flow


Data will flow from the client-side (browser) to the server-side (Node.js) via HTTP requests.
The server will interact with the MongoDB database to retrieve or store data and return the
results to the client.
5.3 External Interfaces
- **Payment Gateway API:** Integration with PayPal and Stripe for payment processing.
- **Email Service API:** Integration with an email service to send order confirmations.

6. User Interface

6.1 Design Requirements


The UI will follow modern design principles with a focus on simplicity and usability. The
primary color scheme will be blue and white.

You might also like