NORTH AMERICAN UNIVERSITY

MASTER’S PROJECT WORK

Capstone Project Thesis

Development of a Test Automation Framework and Testing

Shein.com website

Authors: Supervisor:

Rabia Kurkcu & Ayse Nur Yuksel Dr. Abdulkerim Oncu

A thesis submitted in fulfillment of the

requirements for the degree of Master of Computer

Science in the North American University

August 4, 2023
 Declaration of Authorship

We, Rabia Kurkcu & Ayse Nur Yuksel declare that this thesis titled, “Development of a
Test Automation Framework and Testing Shein.com Website” and the work presented in it is our
own. We confirm that:

This work was done wholly or mainly while in candidature for a research degree at this
University.

Where any part of this thesis has been submitted for a degree or any other qualification at
this University or any other institution, this has been clearly stated.

Where We have quoted from the work of others, the source is always given. Except for
such quotations, this thesis is entirely our own work.

We have acknowledged all main sources of help.

Where the thesis is based on work done by us. We have made clear exactly what was
done by others and what we have contributed by ourselves.

Signed: Rabia Kurkcu & Ayse Nur Yuksel

Date: 08/04/2023
 NORTH AMERICAN UNIVERSITY

Abstract

Master of Computer Science Computer Science

Department of North American University

Development of a Test Automation Framework and Testing

Shein.com Website

By Rabia Kurkcu & Ayse Nur Yuksel

The goal of this study is to comprehend, apply, and improve the idea of testing an e-
commerce website while also raising product quality, which is a crucial component of software
testing. It explains automation testing and uses it to demonstrate how it can be used to accurately
grasp user requirements. There are countless websites, each serving a different function and
class.

It is vital to outline the significance of software testing and inspect the different variations
of methods and techniques to make an effective testing process.

This research paper aims to cover these topics and generate a proper conclusion from the
specified source.

Keywords: e-commerce website,

Selenium WebDriver, Maven, Cucumber, TestNG, Jenkins Report, Functional Testing

 Acknowledgement

We would like to express our heartfelt gratitude, appreciation and thanks to the following
individuals.

To Dr. Abdulkerim Oncu for being our thesis adviser his guidance and encouragement to
finish the study was so valuable. Without his valuable comments and suggestions this work
would not have been possible.

To Dr. Ihsan Said who provided encouraging and constructive feedback and valuable
comments and suggestions when developing this study.

Also, we would like to thank all our teachers who shared their valuable insights when we
needed it. It was a blessing to have such supportive classmates. We are grateful for the
opportunity to improve our skills and knowledge in such a collaborated environment here at
North American University.

We appreciate the opportunity that you provided us.

 Table of Contents

Declaration of Authorship..................................................................................................2

Abstract.............................................................................................................................3

Acknowledgement.............................................................................................................4

List of Figures....................................................................................................................8

Introduction.....................................................................................................................10

CHAPTER 1.......................................................................................................................11

Software Testing..............................................................................................................11

1.1 Software Testing...................................................................................................................11

1.2 Purpose of testing.................................................................................................................12

1.3 Testing Techniques …………………………………………………………………………………………………………13

1.3.1 Integration Testing..................................................................................................................... 13

1.3.2 System Testing........................................................................................................................... 14

1.3.3 Unit Testing............................................................................................................................... 14

1.4 Limitations of Testing................................................................................................................... 14

CHAPTER 2.......................................................................................................................16

Software Development Life Cycle.....................................................................................16

2.1 Software Development Life Cycle Models.............................................................................17

2.1.1 Waterfall Model........................................................................................................................ 17

2.1.2 Iterative Model.......................................................................................................................... 18

2.1.3 V Shaped Model........................................................................................................................ 19

 2.1.4 Spiral Model.............................................................................................................................. 19

2.1.5 Agile Model............................................................................................................................... 20

CHAPTER 3.......................................................................................................................24

3.1 What is Software Testing Life Cycle......................................................................................24

Requirement Analysis........................................................................................................................ 24

Test Planning..................................................................................................................................... 25

Test Case Designing and Development................................................................................................ 25

Test Environment Setup..................................................................................................................... 26

Test Execution.................................................................................................................................... 26

Test Closure....................................................................................................................................... 27

CHAPTER 4.......................................................................................................................29

Manual Testing................................................................................................................29

4.1 Performing Manual Tests......................................................................................................29

4.1 .1 Boundaries of manual testing.................................................................................................... 30

4.2 Automation Testing..............................................................................................................30

4.2.1 Automation Testing Benefits...................................................................................................... 31

4.2.2 Automation Testing Boundaries................................................................................................. 31

CHAPTER 5.......................................................................................................................33

Automation Testing.........................................................................................................33

5.1 Maven..................................................................................................................................33

5.1.1 Apache Maven........................................................................................................................... 33

5.2 TestNG..................................................................................................................................34
 5.3 Selenium...............................................................................................................................34

5.3.1 Selenium Webdriver.................................................................................................................. 35

5.4 Test Driven Development.....................................................................................................35

5.5 Selenium Cheat Sheet...........................................................................................................36

5.6 Framework Design................................................................................................................43

5.6.1 Page Object Model.................................................................................................................... 43

5.6.2 POM.xml................................................................................................................................... 44

5.6.3 Test Suite XML........................................................................................................................... 45

5.6.4 Tags in TestNG........................................................................................................................... 45

5.6.5 Dependencies............................................................................................................................ 46

5.6.6 Utilities...................................................................................................................................... 46

5.6.7 Target Folder............................................................................................................................. 47

5.6.8 Reports...................................................................................................................................... 48

5.6.9 TestNG HTML Report................................................................................................................. 49

5.6.10 TestNG logs.txt Report............................................................................................................. 49

5.6.11 Screenshot Method................................................................................................................. 50

5.6.12 Performed Testing Types.......................................................................................................... 50

Conclusion.......................................................................................................................53

References.......................................................................................................................55
 List of Figures
Figure 1 Waterfall Model....................................................................................................................16

Figure 2 Iterative Model......................................................................................................................16

Figure 3 V shaped model....................................................................................................................17

Figure 4 Spiral Model..........................................................................................................................18

Figure 5 Agile Model...........................................................................................................................19

Figure 6 STLC.......................................................................................................................................26

Figure 7 Selenium Suite.......................................................................................................................32

Figure 8 Selenium WebDriver Architecture Diagram..........................................................................33

Figure 9 TDD Cycle..............................................................................................................................34

Figure 10 Framework Structure..........................................................................................................41

Figure 11 Page Class............................................................................................................................42

Figure 12 Maven pom.xml File............................................................................................................42

Figure 13 Smoke Test Suit...................................................................................................................43

Figure 14 Parallel Test Suit..................................................................................................................43

Figure 15 Regression Test Suit............................................................................................................43

Figure 16 Config Reader......................................................................................................................44

Figure 17 Driver Class..........................................................................................................................45

Figure 18 Logs Class............................................................................................................................45

Figure 19 Target Folder/Reports.........................................................................................................46

Figure 20 Test Base Report Folder......................................................................................................47

Figure 21 HTML Report.......................................................................................................................47

Figure 22 Log.txt.................................................................................................................................48

Figure 23 ScreenShot Method.............................................................................................................48

Figure 24 Parallel Test Suite................................................................................................................49

Figure 25 Regression Test ResultSmoke Testing.................................................................................49

Figure 26 Smoke Test Result...............................................................................................................50

 Introduction

Software testing is the procedure that aims to examine a software program's functionality.
Before the software is deployed and released, the process verifies that there are no faults or gaps,
and that the application's result fulfills the desired expectations. Software testing reduces the
number of bugs in the software, raising its quality. As part of the testing process, test findings are
documented and presented to developers so they can make changes to the system to achieve the
desired outcomes. To ensure the quality of a software product, testing is a difficult procedure that
comes with difficulties.

There are a variety of different testing techniques that can be used in the testing process
to help testers achieve their goals, including functional testing, non-functional testing, unit
testing, system testing, acceptance testing, integration testing, etc. Different testing
methodologies concentrate on various objectives.

To find bugs or other problems with the software, manually testing the site called manual
testing. When testing an application, the tester assumes the position of an end user and examines
how well it adheres to the system's requirements. Manual testing's efficacy in the process of
ensuring the quality of software is, however, in doubt. It is important to talk about the positive
effects of automated testing libraries like Selenium because they can affect the software's quality
attribute.
 CHAPTER 1

Software Testing

This chapter's goal is to examine the real value of testing in the creation of complex
software systems and to analyze various testing methods. This paper will contain a suggested
strategy for software quality assurance because it is recommended that every organization set up
a strong management system to handle the quality assurance of software.

1.1 Software Testing

The majority of those who work in the software development industry have endured or
participated in software testing in some capacity. What exactly is testing software, what counts
as testing, and what does not are all defined differently. Every organization should follow a
single, widely recognized definition of software testing. Software testing is the process of
ensuring that a program or software system performs as it is intended to, according to (Hetzel,
1984). In contrast, software testing is described by Myers (1979) as running a program or system
to spot flaws. Both reflect a component of software testing, but instead of considering all of
them, these definitions concentrate on a single objective. Hetzel's definition focuses on making
sure the system performs as planned, however a system may seem to be in use but still include
defects that will not please clients. Myers, however, concentrates on ensuring that the system is
bug-free without considering the functional requirements of the system; if one is bug-free but
does not meet the client's needs, the system has not been adequately validated. Verifying that the
right system is being constructed is the process of validation. While both are critical to
understanding testing, they are also rapidly coming to be seen as too limited and limiting to be
accepted as a definition of testing. It is not the best practice to simply validate the system
correctly because that will only partially satisfy clients. There are numerous other ways to
evaluate a system besides running it and making sure it functions. There are additional aspects
that should be considered while trying to produce rate and palatable definition of software
testing. What critically important software quality criteria do users observe first? Functionality,
system dependability, usability, effectiveness, maintainability, portability, interoperability,
understandability, and the product's visual appeal were shown to be the software quality factors
that have the most impact on users (Jagannath and Nigussu, 2018). Each of those elements might
thereafter be categorized as a respectable human software quality factor (HSQF). Fulfilling each
HSQF requirement would be advantageous because the firm will earn most of its revenue from
its consumers. Thus, a definition of software quality assurance (SQA) can be determined from
this. Software quality assurance is "A systemic, planned set of actions necessary to provide
adequate confidence that the software development process or the maintenance process of a
software system product conforms to established functional technical requirements of keeping
the schedule and operating within the budgetary constraints," according to (Galin, 2004). By
concentrating on achieving the system's functional requirements and developing a strategy to
address the product's overall quality, (Galin, 2004) incorporates the proposed definitions by
(Myers,1979) and (Hetzel,1984). According to the authors, this is a far more comprehensive way
of thinking about software testing, and it better captures its purpose. SQA should not stricted
with the programming phase. The enlarged definition must encompass both the development and
maintenance phases of software. So, to ensure that the product fulfills the HSQF and an
acceptable level of software quality, the authors would like to define software testing as the
procedure.

1.2 Purpose of testing

When a software team tries to create a functioning application, testing takes up at least
half of their time. The success rate of a product's release is increased via software testing, which
is not an easy task. The purpose of testing must be clearly understood to know what an
organization is attempting to accomplish when determining if its product is ready for release to
carry out testing on software products effectively. Testing should aim to prevent bugs, according
to (Beizer, 2003). The two appear to agree with each other's concept of software testing (Myers,
1979). Testing and test design, according to (Beizer, 2003), "should be able to identify symptoms
caused by bugs, but they do not prevent bugs." Testing should attempt to identify odd behaviors
in the way the system functions that are brought on by these problems rather than concentrating
on the faults themselves. Better test design than testing itself helps to prevent errors. A bug is a
mistake or flaw in a system's operation that affects the system's operation. Software testing is
essential to counteract human error, which will inevitably occur. Some errors are less costly than
others, but some are harmful and may lead to economic loss. However, there is a claim that
software testing should concentrate more attention on boosting the user's confidence that the
system will function properly in all conditions rather than only concentrating on detecting
defects in the system. The author thinks this is a more important objective to pursue during
software testing because customer confidence when using the product has a bigger impact on its
success than simply reducing the number of faults it contains. Due to this, the author thinks that
software testing's goal should be to verify the product meets the users' acceptance criteria while
lowering the number of problems in the software.

1.3 Testing Techniques

This section will detail the different testing techniques performed in assuring quality of a
software product.

1.3.1 Integration Testing

According to Hetzel (1984), it makes little sense to functionally test a group of programs
until they interact effectively. Integration testing's goals are to verify the system's behavior after
modules have been integrated together rather than to worry about requirements. Prior to
combining and testing small system components, they are evaluated individually. To see that
system components, behave the same way when integrated with other components, this is done.
The top-down and bottom-up techniques for integration testing are both widely used. Low level
system modules should be tested first, then higher level modules, to ensure seamless integration.
Instead of evaluating top modules first before testing them with lower-level modules, the top-
down approach tests top modules last. An approach to integration testing is suggested by (Hetzel,
1984) as follows:

1. Choose a small collection of modules that each support a single piece of essential
functionality and are simple enough to test individually.

2. Connect and test the module group.

3. Put the group under stress.

4. The next collection of modules should then be integrated.

As it highlights system flaws and enables engineers to identify which system

components are problematic, integration testing is a crucial test method in quality assurance.
 1.3.2 System Testing

When integration testing is completed, system test execution typically starts. It is

advisable to add it after the system's capabilities have been verified and enough fixes have been
made for known issues. System tests evaluate both functional and non-functional aspects of the
system, such as maintainability, security, and requirement specifications (Karuturi and Gowda,
2017). This is a black box testing technique where the tester simply needs to be aware of the
desired behavior rather than the internal workings of the system implementation. System testing
is typically the stage where the choice to release the software is most strongly influenced.

1.3.3 Unit Testing

Functional testing is testing done to increase a product's conformity to the given user
criteria. The predicted output of a task while utilizing a software component is compared with
the actual output in a functional testing technique known as unit testing. Unit testing is carried
out at the absolute lowest level or most granular level, according to (Karuturi and Gowda, 2017).
Continuous testing and revision are done in this manner. Unit testing is a subset of white box
testing, one of the testing types represented in Figure 1 where the tester is fully aware of the
internal implementation specifics and code structure. Organizations frequently utilize Junit as a
framework for unit testing. Since Java is a well-known programming language and unit testing
framework, various software development environments can use Junit. There are additional unit
testing frameworks, though, including Nunit, TestNG, Embunit, etc.

1.4 Limitations of Testing

Although software testing is quite effective in creating a software product that everyone
will accept, there are several difficulties and restrictions that exist. (Professionalqa.com, 2018)
asserts that none of the following results can be attained with software testing:

Testing cannot guarantee that a software product is error-free.

• Testing merely seeks to reduce errors as much as possible; yet, having software that is
completely bug-free is almost unachievable.
 • Software testing cannot forecast or estimate how well a product will work in various
scenarios.

• To be as effective as possible, testing requires extensive planning.

 CHAPTER 2

Software Development Life Cycle

In today's generation, software development is one of the most potent, essential, and
necessary fields. Every organization, industry, small business, institute, etc. needs software to
operate their system and lessen the manual or conventional job that was once unsafe and prone to
blunders. The core principles of SDLC center on minimizing risk and failure while maximizing
product quality. The SDLC was developed specifically to make development work in a step-by-
step fashion. The software development life cycle (SDLC) outlines the framework with many
activities and tasks to be completed during the software development process.

A software system's development, modification, maintenance, and replacement are all

covered in detail by the SDLC.

The Software Development Life Cycle Model is a diagram that outlines the general process
of software development, with each phase outlining how it is carried out. There are numerous
sorts of models, including the agile model, the V-shaped model, the evolutionary prototyping
model, the spiral model, and the waterfall model.

To ensure a project's success, it may be necessary to select the appropriate SDLC model
based on the problems and needs of the project.

Every model has benefits and drawbacks. It depends on how our projects are going, and we
must use the model in accordance with the specifications.

The focus of the software development life cycle is:

 Recognizing the issue.

 Decide a plan for a solution. i.e.
 Coding the planed solution
 Test the actual program
 Maintain the product
 Since the first computers and their operators, back in the days, there has been a "software
developer" profession.

Since the creation of the computer, software development procedures and processes have
changed over time. With this advancement, new software development techniques have emerged
from worldwide private and public software development activities.

These approaches differ, but they all aim to create software as affordably, effectively, and
efficiently as possible.

2.1 Software Development Life Cycle Models

2.1.1 Waterfall Model

The Waterfall model is a linear and sequential approach to software development. It consists
of distinct phases such as requirements gathering, design, implementation, testing, deployment,
and maintenance. Each phase is completed before moving on to the next, and it is difficult to go
back to a previous phase once completed.

The Waterfall model in SDLC (Software Development Life Cycle) is the first model
introduced to represent the development of software in divergent phases.

The waterfall method prevents the process from returning to a previous phase and allowing
adjustments to it. Small projects typically adopt the waterfall approach since there is minimal
room for adjustments after a stage is complete. In a waterfall model, issues cannot be resolved
until the maintenance stage. Phases such as requirement analysis, system design,
implementation, testing, deployment, and maintenance are included in the waterfall model's
phases.

1. Requirement Analysis: Gathering and evaluating the project's requirements is the first
phase in the Waterfall methodology. This entails knowing the project's scope, locating the
stakeholders, and compiling data on the target audience.

2. System Design: The second stage is to design the software. This entails developing a
software architecture, determining the system's constituent parts, and specifying how these parts
communicate with one another.
 3. Implementation: After the design is finished, the implementation phase starts. This entails
creating the software's code, putting its components together, and testing it.

4. Testing: The software is tested in the next stage. Unit, integration, system, and
acceptability testing are all included in this.

5. Deployment: After testing is complete, the software is deployed in a production

environment.

Figure 1 Waterfall Model

2.1.2 Iterative Model

The waterfall model's flaw is fixed by the iterative model, which uses an iterative. Iterative
models acquire needs during each step, as opposed to waterfall models where they were only
needed once. The project is broken up into smaller parts so that the outcome can be applied in
the following stage. The client's feedback is gathered following each increment and used to
determine the next step to be planned and modified. Every phase produces the latest version of
the software, which is then created again until the entire system is ready.

Figure 2 Iterative Model

 2.1.3 V Shaped Model

The waterfall concept is expanded upon in the V-shaped model. The V-shaped model
illustrates the connections between each stage of development and its corresponding testing
stage. The phrase "verification and validation model" is another name for it. This is so because
there is a validation phase that goes along with every verification phase. Any software's primary
feature is to be evaluated for performance. It must undergo numerous tests. As a result, testing is
the focus of the V-shaped model. Validation guarantees that all the development was done
correctly, whereas verification concentrates on it. There is a lot of testing done in this process,
which is extremely dynamic. The 'tester's life cycle' is another name for these actions.

Figure 3 V shaped model

2.1.4 Spiral Model

One of the most significant models for the Software Development Life Cycle (SDLC) that
combines the waterfall and iterative methods for risk management is the spiral model. Barry
Boehm initially mentioned the spiral model in his work from 1986. Every phase in this paradigm
begins with a design objective and concludes with the client reviewing the development. Large
projects that involve risk and cost with every change are used in this strategy. As indicated in the
below diagram, the spiral model contains four distinct phases, including planning, risk analysis,
engineering, and evaluation.
 Figure 4 Spiral Model

2.1.5 Agile Model

Agile design approaches such Scrum and Kanban prioritize iterative and incremental
development. Sprints, which are short iterations of the development process that last 1-4 weeks,
are used. Agile places a strong emphasis on communication, adaptability, and cooperation. It
encourages ongoing client interaction and feedback throughout the development process.

Each Agile project typically has a customer representative on the team to create close contact
with the customer during development and to clearly grasp varied requirements. Stakeholders
and the customer representative examine and reevaluate the requirements at the conclusion of
each iteration.

Agile models rely less on extensive documentation and more on the deployment of functional
software. Transmission of incremental software updates regularly, spaced by a few weeks, to the
customer representative.

The importance of having effective team members and improving communications within
them is emphasized. It is understood that face-to-face communication, rather than formal
document exchange, can improve communication among development team members.

To enable the team members to genuinely engage in face-to-face contact and foster a
collaborative work atmosphere, it is advised that the development team be maintained small (5 to
9 people).
 Pair programming is typically used in the agile development process. Two programmers
collaborate on a single workstation during pair programming. One person codes, while the other
person checks the code as it is entered. Every hour or so, the two programmers trade places.

Figure 5 Agile Model

2.2 Advantages of SDLC

The Software Development Life Cycle (SDLC) offers several advantages for organizations
and software development teams. Here are some key advantages of following an SDLC
approach:

Structured and Organized Process: The SDLC offers a structured and systematic approach
to software development, guaranteeing that all required actions are taken in a comprehensible
order. It facilitates project planning and organization from beginning to end, which lessens
confusion and increases efficiency.

Clear Requirements Gathering: Effective requirement collection and documentation are

emphasized by SDLC approaches. This helps in precisely defining the project's scope,
understanding user needs, and coordinating the development process with client demands. It
minimizes the possibility of misunderstandings and assures that the final product satisfies the
required standards.
 Quality Assurance: SDLC incorporates testing and quality assurance activities throughout
the development process. The risk of defects and issues is reduced since it ensures that each
stage has been completely verified before moving on to the next. This produces better software
and a more reliable final product.

Risk Management: The main goal of SDLC methodologies is to monitor and control risks
throughout the project. Potential problems can be resolved effectively through carrying out risk
assessments and mitigation plans at each level. It helps in reducing project challenges, holdups,
and cost overruns.

Increased Collaboration: Collaboration is encouraged amongst team members and

stakeholders due to the SDLC. Collaboration encourages teamwork, boosts creativity, and
improves comprehension of project objectives.

Effective Resource Management: SDLC techniques aid in maximizing resource allocation

and usage. Teams can efficiently plan resource requirements by establishing clear project
milestones, assigning tasks, and estimating efforts. It minimizes the possibility of resource
stresses or shortages and promotes effective project execution.

Scalability and Flexibility: SDLC models offer the capacity to scale and flexibility to
handle projects of many sizes and complexity levels. It does not matter if the project is a small
one with few resources or a massive corporate application—SDLC methodologies may be
customized and adjusted to meet the unique requirements of each.

Continuous Improvement: The SDLC encourages a culture of ongoing development by

incorporating feedback loops and taking lessons from each project iteration. The use of lessons
gained from earlier projects leads to process improvement and enhanced project outcomes in the
future.

Overall, SDLC methodologies bring discipline, structure, and efficiency to the software
development process. They offer a structure for successfully organizing, carrying out, and
delivering high-quality software solutions while lowering risks and boosting client satisfaction.

Without a plan, it can be exceedingly challenging to complete a complex collaborative

project like software development. Each software development methodology is a blueprint for
how to create software; many will be discussed here. How to assess success in software
development and which approach is better overall and for a specific kind of software are hotly
contested topics. But there is one thing you can count on: a plan is better than nothing.

The intended outcome of development is unknown. How much a project is closer to

completion than the project manager is aware of. Without a plan, the company would not even be
able to determine whether the finished product satisfied their needs.

Software development life cycle is a methodical process that guarantees the quality and
accuracy of the software created. The structure enforced by this SDLC is purposefully created to
increase the likelihood that a software development effort will be successful. It comprises of a
thorough strategy that outlines how to organize, create, and maintain software. Every piece of
software starts out as a concept and progresses through various stages before being built and
released. Up until the day it is decommissioned or replaced, an application or system's software
development life cycle is still active and adding updates and new features. Over the years,
several software development techniques have developed.

SDLC offers many benefits such as:

 A standardized language for each action

 Clear lines of communication between stakeholders and development teams
 Project managers, business analysts, developers, and designers should all have clear roles
and responsibilities.
 There should also be inputs and outputs defined from one phase to the next.
 A deterministic definition of each step that can be used to determine whether a step is
indeed finished.
 CHAPTER 3

3.1 What is Software Testing Life Cycle

STLC (Software testing lifecycle) stands for Software Testing Life Cycle. It is a collection of
procedures and actions carried out during the software development process' testing phase. Prior
to deployment, software must be tested for reliability and quality using the STLC methodology.
The main goals of STLC are to find errors and confirm that the program complies with the
criteria.

A life cycle is the progression through several forms that a thing goes through. From
beginning to end, many distinct and concrete entities undergo many transformations. The
software is an entity when discussing the software testing life cycle. The process of carrying out
various operations while testing is known as the software testing life cycle.

The main goal of STLC is to guarantee the product's quality. Every application differs in
terms of performance, usefulness, and reliability. And STLC makes it easier to improve these
qualities and create a perfect final output.

Typically, STLC involves the following activities:

Requirement Analysis
The specifications and requirements must be viewed, studied, and analyzed by your
important software testers. By providing certain requirements with input data, they can yield
results. These requirements can be put to the test. Both functional and non-functional
requirements are examined by testers. They must then choose testable requirements after that.

During this phase, tasks like requirement analysis brainstorming and test requirement
identification and prioritization are undertaken. They also involve identifying requirements for
both human and automated testing. Even if they are not mentioned directly, a few items require
testing. A phone number text field should not allow entered alphabets when a button is active
and should do some action when clicked.

These concepts should constantly be examined because they are widely used. However, the
goal of the requirement analysis stage is to get more precise information about the product. You
must understand the perfect state of the product. This phase also analyzes the viability of test
automation and produces a complete requirement report as deliverables.

By making sure that every testing effort is linked to a need that adds value for the client, you
can eliminate waste in this manner. Briefly stated:

 Become familiar with the product's planned output.

 Any gaps in the requirements should be noted.
 Set up your priorities.
 Run feasibility tests for automation.

Test Planning
The QA (Quality Assurance) team designs the test plan in the second stage after reviewing
all the relevant testing requirements. After comprehending the product domain, they define the
scope and goals. To develop a strategy, the team first evaluates the risks involved and establishes
timetables and testing settings.

After that, management completes the tools and assigns people to specific jobs and duties.
Also specified is a rough timetable for when testing for each module is to be finished. The test
plan, a document outlining the purpose and specifics of the testing activities for a given project,
is the most crucial output produced in this step. To summarize:

 Generate the documentation for the test plan.

 Analyze your efforts and time.
 To conclude, the platform and tools.
 Give teams and individuals their tasks.
 Determine the training needs

Test Case Designing and Development

The test cases should be comprehensive and entirely representative of all potential scenarios.
It is necessary to compile all permutations and combinations.

By determining which test cases are most frequent or have the greatest potential to affect the
product, you can order them in order of importance. The documentation stage then moves on to
the verification and validation of the stated requirements. Additionally, crucial procedures at this
stage include reviewing, updating, and approval of automation scripts and test cases.

Determining various test conditions, together with the input data and anticipated results, is
another step in this process. As a result, the actual test cases arranged in their test suites are the
key deliverables created during this phase. Briefly stated:

 Find out more about the product and collect potential actions.
 Establish test cases.
 Prioritize the test cases.
 For test cases, create automated scripts.

Test Environment Setup

To execute created test cases, testing activities require specific environmental components,
such as servers, frameworks, hardware, and software. Smoke testing is also required, as is
providing your testers with tools for logging bugs. that is typical to hear "it ran on my system,
but it's not running on yours" in the developer community.

A comprehensive test environment management strategy is the stage's key deliverable.

Setting up the test environment is the responsibility of the QA manager overseeing the team. To
summarize:

 Recognize the minimum requirements.

 List the hardware and software requirements for each performance level.
 Make test environments a priority.
 Create testing environments.
 Test the constructed environments for smoke.

Test Execution
Once the team has completed all the earlier stages, the application is prepared for testing. The
testers carry out test cases in accordance with the test plan. Additionally, they recognize, detect,
and log the flaws, thereby reporting the faults. The team is also in charge of contrasting actual
results with those that were anticipated. If any bugs are discovered, they must be recorded so that
the development team can fix them.
 Testing for regressions starts as soon as a bug is fixed by the development team. Regression
testing verifies that the program or application continues to function even after a modification
has been deployed.

It is also advised to utilize scripts or automated testing tools because the same tests must be
repeated after each patch and release. The test results, which should be confirmed and
communicated automatically, might be considered the major deliverables in this phase. To
summarize:

 Execute test cases.

 Determine whether the product's behavior differs from what is expected.
 Keep a detailed log of failed cases.
 After bug fixes, retest.

Test Closure
The test closing phase begins after test execution is complete and the finished product is
delivered. The QA team reviews the test results and has a team discussion about them. They also
consider project cost, test coverage, and product quality. Further analyses can be performed to
determine what went wrong if actual data differs from the estimates.

Getting together to discuss the results after testing is a crucial habit for testers. We can
address any problems encountered during testing or weaknesses in our approach here. Based on
what you learn from testing, you can focus on developing a better testing strategy. Testing is
routine if you use the DevOps or canary release methodology.

In addition, the team considers test data, target completion, and deadline observance. They
can assess the entire testing strategy and process after they have a complete understanding of
what transpired. To summarize:

 Make sure all tests have been performed.

 Examine elements including quality, test coverage, schedule, and cost.
 Report the outcome.
 Determine whether the testing procedure may be improved by talking about the learning.
 Generate a test closure report.
 STLC is integral to the overall Software Development Life Cycle (SDLC) and works with
other phases, such as requirements gathering, design, and development. The purpose of STLC is
to ensure that the software is thoroughly tested, defects are identified and fixed, and the final
product meets the desired quality standards.

Figure 6 STLC
 CHAPTER 4

Manual Testing

Manual testing is a type of software testing in which a software tester generates and executes
test cases without the use of automated testing tools. Finding problems, bugs, and flaws in a
software program is the primary goal of manual testing. Before performing the automation
testing, any new software program needs to be manually tested. Manual Testing is crucial
because of the principle of software testing "100% Automation is not possible".

(Bartlett, 2016) defines manual testing as the practice of utilizing an application's features
and functionality exactly as an end user would to confirm the system's behavior. When testing
software, the tester runs tests using test cases that have already been created and records the
findings. The requirements document serves as the basis for the test cases. A black box testing
approach is manual testing. Understanding the requirements is advised to properly run manual
tests (Bartlett, 2016). An idea of what might be categorized as a software system defect can then
be created from an understanding of the requirements. According to the author, a software
system has a flaw if it does not meet the client's needs. As it can be done on any part of the
software system and it is simple to record test results and provide feedback, manual testing can
be a successful test methodology.

4.1 Performing Manual Tests

Writing the test case is the initial step. Clarifying how the test will be conducted is one of the
most critical topics to be addressed while writing a test case. The environment in which the tests
will be run must be known to the tester, and after it is established, it must be determined if this is
also the environment in which the client will use the system.

Before doing the manual test, a test case's expected result should be described as a method of
documentation. The likelihood of fulfilling the functional requirements increases with the
percentage of test cases that match the expected results. Respectable test cases, according to
(Bartlett, 2016), should be repeatable. This will enable different people to run the same test
without repeatedly asking questions. According to (Hetzel, 1984), it is not feasible to test every
potential scenario; instead, a selection of test cases should be made, and the planning and
attention given to that selection determines the difference between good and poor testing.

After the tests have been written, the platform for running the manual tests should be
decided. The steps outlined in each test case should be followed when executing the test case.
Each tester should use the same platform to produce reliable results. By keeping track of each
test's results, management can use them to choose when to release the software while also
determining the software's current quality. Effective bug reports should include a powerful title,
instructions on how to recreate the bug, the expected and actual findings, and any pertinent
attachments that can be used in the inquiry, according to (Bartlett, 2016).

4.1 .1 Boundaries of manual testing

Although manual testing allows for flexibility and human judgment, it can also be labor-
intensive, time-consuming, and prone to mistakes. However, it continues to be a crucial step in
the testing process, particularly for some tests, in the early phases of development, or when
automation is not practical or economical. To ensure effective and thorough test coverage,
automation testing methods can be used with manual testing.

Manual testing has certain drawbacks even if it is unquestionably a useful strategy for
handling test results documentation. It takes a lot of time and resources to achieve quality targets
with manual testing. Graphical user interface (GUI) object size difference and color
combinations are two crucial metrics, but they are difficult to uncover when doing manual
testing, according to (Professionalqa.com, 2018). The manual testing technique is seen to be
unsuitable for lengthy and large-scale projects. The reason for this is because it will take an
excessive amount of time to manually test each module of a big software system. Attempting to
compare massive amounts of data with manual testing would be both unreasonable and
impossible.

4.2 Automation Testing

Hetzel (1983) stated that "Software tools and support packages are very important to testing
in the large". The effectiveness and expense of software testing can be impacted by support.
Software testing manually is extremely challenging owing to the time and effort requirements.
Utilizing test automation software is a substitute for manual testing. By enabling an increase in
code coverage, automation can lower the cost of failure by catching errors before they have a
chance to cause significant harm in the production environment. Software can be used to test a
software system component as part of automation testing.

In contrast to manual testing, automation testing is simply a quicker method of testing. There
are studies that imply automation is a better alternative to manual testing, and the use of
automation in the context of software engineering is a well-developed research area.

4.2.1 Automation Testing Benefits

Without a doubt, using automation testing software has been extremely beneficial for
businesses. According to research by (Dudekala et al., 2012), it has increased the quality of
software products by reducing the number of flaws that are present. Testing may be done more
quickly and with fewer resources thanks to automation. a rise in system confidence among
developers. Due to software businesses' use of automation tools, the amount of human work is
reduced, freeing up resources for other stages of the development process. Companies have
observed a greater fault detection rate when using testing procedures such defect pooling or fault
seeding, according to (Dudekala et al., 2012).

4.2.2 Automation Testing Boundaries

Automation testing clearly aids in software quality assurance, but there are several
drawbacks that should be considered before using it. According to (Dudekala et al., 2012), not all
tests can be automated, at least not readily, hence it is believed that automation testing cannot
totally replace manual testing. Due to the growth of software products and the changing nature of
technology, organizations have trouble maintaining test automation. Further automation testing
necessitates that the tester be familiar with testing frameworks and tools, which forces businesses
to invest in training staff in this area. Some familiar challenges of automation testing include:

• Initial Investment: An initial time, effort, and resource investment is needed to set up an
automation testing framework and create test scripts. For businesses with tight schedules or little
finances, this might be a problem. • Skill and Knowledge Requirements: Testers that are skilled
in scripting languages, test automation tools, and frameworks are needed for automation testing.
It might be difficult to locate qualified personnel and to offer the appropriate training,
particularly for firms that are new to automation testing.
 • Test Case Selection: Not every test case can be automated. Thorough preparation and
analysis are needed to decide which test cases should be automated and which should be run
manually. There may still be times when manual intervention is necessary, for as in usability
testing or exploratory testing.

• Maintenance Work: To keep automated test scripts current with software upgrades,
constant maintenance is necessary. The automation suite maintenance may require more time
and resources as the program develops because scripts may need to be modified.

• Script Stability and Fragility: Automated test scripts may be vulnerable to modifications
made to the underlying technology or user interface of the program. Scripts may fail or give false
negatives because of minor UI tweaks or program updates, necessitating script revisions.

• Test Data Management: For automation testing, effective test data management is
essential. It can be difficult and time-consuming to create and manage test data sets that cover a
variety of scenarios, especially when working with massive amounts of data.

• Complex Testing Scenarios: Automating some testing scenarios, like those involving
complex workflows or multi-threaded operations, can be difficult. It could take more time and
effort to write test scripts to handle such cases.

• Non-Deterministic Applications: Some applications may be difficult to automate because

they contain dynamic features, random behavior, or timing-dependent operations. In such
situations, obtaining reliable and consistent findings might be challenging.

• Limited Human Judgment: Unlike manual testing, automation testing lacks the human
judgment and intuition it offers. Testing professionals could overlook minute flaws or
unanticipated problems that exploratory or ad hoc testing can reveal.

• The Cost of Test Automation Tools: Test automation tools and licensing, particularly for
enterprise-level solutions, can be costly. Organizations may have difficulties when evaluating,
choosing, and procuring effective tools within their financial capabilities.
 CHAPTER 5

Automation Testing

There are numerous automation testing software tools available in the market, each with its
own features and capabilities. Here are some popular automation testing tools:

1. Selenium
2. Appium
3. Test Complete
4. JUnit
5. Cucumber
6. Robot Framework

These are only a few examples of the software tools for automation testing that are offered on
the market. It is crucial to assess the precise requirements of your project, consider aspects like
cost, support, compatibility, and convenience of use, and select the tool that best suits your
requirements.

5.1 Maven
The Apache Group created the well-known open-source build tool Maven to build, publish,
and deploy several projects simultaneously for better project management. Developers can create
and document the lifecycle framework using the provided tool.

Projects created in C#, Scala, Ruby, etc. are built using Maven, a Java tool. This tool, which
is based on the Project Object Model (POM), has made it simpler for Java developers to create
reports, check builds, and test automated settings. Maven primarily aids in the download of
dependencies, which are libraries or JAR files, for Java-based applications. Due to the possibility
of various versions of individual packages, the tool aids in obtaining the appropriate JAR files
for each project.

5.1.1 Apache Maven

Apache created Maven to manage many projects at the same time, including publishing
project details, fostering teamwork, deploying projects, and sharing JARS among many projects.
 Maven has a ton of excellent features, which goes a long way toward explaining why it is so
popular. Here are a some of Maven's most notable characteristics:

5.2 TestNG
A well-known testing framework for Java-based applications is called TestNG (Test Next
Generation). It offers additional functions for test execution and test management and is intended
to overcome some shortcomings of the more traditional JUnit framework.

For testing Java applications, TestNG offers a wealth of functionality and a strong, adaptable
architecture. It encourages test reuse, efficient test execution, and code maintainability. All types
of tests, including unit, functional, end-to-end, integration, etc., are covered by TestNG.

5.3 Selenium
Selenium is a portable testing framework mostly used for web-based applications testing.
When Jason Huggins tested an internal application at Thought Works in 2004, he concluded
there was a better way to test than with manual testing. Because Selenium is free software, its
source code can be obtained and correctly updated. This utility works with Firefox, Chrome, and
Internet Explorer and may be used on a variety of operating systems, including Linux and
Windows. Numerous programming languages, including Java, Perl, C#, Ruby, Python, and
others, are supported by Selenium. Selenium can be used with other tools to make it easier to
use.

Figure 7 Selenium Suite

 5.3.1 Selenium Webdriver
One of the parts of the Selenium toolkit is the Selenium Web Driver. It was unveiled as
an improved version of the Selenium RC, which was its predecessor. It exploits the browser's
inherent functionality and direct communication to automate the test case execution procedure.
The Selenium Web driver is now regarded as one of the quickest of the Selenium toolkit's other
components. The Selenium Web driver offers better assistance for testing dynamic web pages. It
may be used with browsers like Firefox, Chrome, and Macintosh. Additionally, it allows testing
on a few uncommon browsers, including the HTML Unit browser. Selenium Web driver's
interaction with web page elements is more realistic.

Figure 8 Selenium WebDriver Architecture Diagram

5.4 Test Driven Development

Test-Driven Development (TDD) is a software development approach that emphasizes writing

tests before writing the actual code. It is a part of the Agile software development methodology and
follows a cycle of "Red-Green-Refactor." TDD aims to improve code quality, maintainability, and
reliability by ensuring that code is thoroughly tested from the beginning. Here is how the TDD process
works:
 Figure 9 TDD Cycle

This approach initially seems difficult and slow in the short run, raising the overall quality of
the software project. However, the long-term benefits of improved code quality and
maintainability make it a valuable practice for many software development teams. Enough test
coverage provides as a precaution to prevent unintentionally changing the functionality.

5.5 Selenium Cheat Sheet

Selenium Cheat Sheet is a reference guide for learning Selenium commands, navigators,
operations, locators etc.
 5.6 Framework Design

Figure 10 Framework Structure

5.6.1 Page Object Model

The Page Object Model (POM) design pattern is widely used in test automation to improve
the maintainability and reusability of automated tests. It helps in the structuring of test code and
separating of it from the user interface within the underlying web application.

POM represents each web page or user interface as a separate class that encapsulates the
page's elements and interactions. This supports code modularity, enabling page objects to be
reused across various test cases and test suites. This reusability eliminates code duplication and
simplifies test maintenance. Any changes to the web application's user interface or element
locators can be handled by updating the relevant Page Object class. The changes will
automatically propagate to all test cases using that page object. This significantly reduces the
maintenance effort when the UI progresses or changes.
 Figure 11 Page Class

5.6.2 POM.xml
Maven defines the project structure, dependencies, and configurations using a Project Object
Model (POM). The POM is an XML file with the extension pom.xml that acts as the project's
main configuration and administration file.

The project home directory is where you may find the XML file. Maven looks for the POM
in the current directory when you run a task.

Figure 12 Maven pom.xml File

 5.6.3 Test Suite XML

TestNG test suite XML files are configuration files used to define the test suites and their
configurations for executing tests in TestNG. These XML files help organize and manage the
execution of test cases, allowing testers to group related tests, specify test parameters, and
control the test execution flow. XML files provide a flexible and organized way to manage test
configurations and executions, making it easier to control the behavior of test suites and tailor
them to specific test requirements.

Figure 13 Smoke Test Suit

Figure 14 Parallel Test Suit

Figure 15 Regression Test Suit

5.6.4 Tags in TestNG

 Tags are used in TestNG to organize and group test classes or methods. Based on their
classifications, tags enable the selective running or exclusion of certain tests. They give testers an
effective approach to plan and manage test execution, enabling them to run test groups, use
unique configurations, and carry out focused testing depending on test categories.

5.6.5 Dependencies

Dependencies are the connections among various components or modules in a project in the
context of software development. When one module depends on another for functionality, there
is a dependence. Maintaining an orderly, manageable, and scalable codebase requires an
understanding of and ability to manage dependencies.

Effective dependency management contributes to the development of modular, reusable, and

maintainable code. Also, it makes it simple to integrate external libraries and frameworks,
eliminating the need to create all the same functionality from scratch. Additionally, it makes it
easier for developers working on various project components to collaborate.

5.6.6 Utilities

Utility classes in Java are also known as assistance classes. It is an effective way for creating
reusable methods. A utility class can hold code that we often use. In Java, the final and public
keywords are not allowed to be used to create or define the empty utility class. Because object
methods must be generated, the methods of the utility class should be tagged static rather than
abstract. The final keyword forbids subclassing.

Figure 16 Config Reader

 Figure 17 Driver Class

Figure 18 Logs Class

5.6.7 Target Folder

Target folder is a folder where we store generated TestNG reports and screenshots.
 Figure 19 Target Folder/Reports

5.6.8 Reports
Test reporting provides essential information about the testing process, including
gaps and obstacles, in the context of continuous testing. Teams can postpone the
software release procedure until the issues are repaired, for example, if a test report
reveals numerous unresolved flaws.

The next-to-last phase before a product is released onto the market is software
testing. It involves looking at, analyzing, observing, and rating various parts of a
product; thus, it is essential to provide a report that can highlight the success of a
product. As a TDD framework, TestNG requires an accurate reporting system. To
generate reports in html format, we extended the report dependency in our
TestBaseReport class under the utilities folder by adding it to the pom.xml file.
Additionally, for better comprehension, we included the possibility of taking screenshots
of errors.
 Figure 20 Test Base Report Folder

5.6.9 TestNG HTML Report

TestNG reports are generated in HTML format and stored under Target Folder. Since
HTML report is not user friendly it is openable as graphic on any browser.

Figure 21 HTML Report

5.6.10 TestNG logs.txt Report

The TestNG logs.txt reports are generated in txt format and stored under Logs
Folder. We get advantage of log4j library to log all steps for each test case.
 Figure 22 Log.txt

5.6.11 Screenshot Method

Screenshot Method is created under TestBaseReport class, and it captures the failure
images after the execution.

Figure 23 ScreenShot Method

5.6.12 Performed Testing Types

In this project Regression, Smoke and Parallel Testing were performed.

Parallel Testing
Parallel execution was performed to reduce testing time that required multiple browsers running
simultaneously. Test suite xml code was added into testing.xml file to achieve Parallel Testing.
 The thread-count field gives us flexibility to run how many tests that we want simultaneously. The
verbose field gives us the report style that we need, such as only info or debug or more detail report. We
can use the verbose level between 1-10.

Figure 24 Parallel Test Suite

Regression Testing
Regression testing is a crucial software testing process that verifies that recent
changes or additions to a software application have not adversely affected existing
functionality.
 Figure 25 Regression Test Result Smoke Testing

Smoke testing, commonly referred to as "Build Verification Testing" or "Build

Acceptance Testing," is a crucial and first stage of software testing carried out on a fresh
build or release candidate of an application. Smoke testing's main goal is to quickly
determine whether the software's crucial features are operating as intended and whether
the build is stable enough for additional testing.

Figure 26 Smoke Test Result

Version Control
GitHub is a web-based service for version control using Git. This feature is extremely useful
to keep track of developers and test engineers working simultaneously in the project.

We uploaded our code into our GitHub repository

 Conclusion

The Shein website testing project was undertaken to evaluate the functionality, usability,
and overall quality of the Shein e-commerce website. The testing process involved diverse types
of testing, including functional testing, usability testing, performance testing. TestNG was used
as a framework to create a robust and organized test suite for testing the various functionalities of
the Shein website. The TestNG framework allowed us to execute tests in a structured manner,
manage test dependencies, and generate comprehensive test reports. The initiative to test the
Shein website using the TestNG framework was successful overall. We were able to thoroughly
test crucial features, confirm how the program behaved, and offer the development team
insightful feedback. TestNG's automation and organization increased testing productivity and
assisted in spotting potential problems early in the development cycle.

Furthermore, Testing e-commerce websites like Shein can indeed be challenging, primarily
due to the dynamic nature of web applications. Web element locators and page structures tend to
change frequently, making test maintenance a continuous effort. Some of the challenges we
faced during testing Shein include:

1. Dynamic Locators: Web element locators (we used XPath) can change whenever the
website's code is updated or redesigned. This necessitates updating the locators in test scripts,
which can be time-consuming and error prone.
2. Unpredictable Changes: Since e-commerce websites are subject to frequent updates and
improvements, changes can occur without prior notice. We had to update or recreate new test
cases during the project.
3. High Test Maintenance: Frequent changes in web element locators and page structures lead
to high test maintenance overhead. Test cases that were once stable may start failing due to
the changes, demanding regular updates.
4. Data Variability: E-commerce websites handle substantial amounts of dynamic data, such as
product catalogs, prices, and user profiles. Testing with a diverse set of data is crucial to
uncover potential issues related to data handling.
5. Performance Testing: E-commerce websites experience significant traffic during peak
periods, like sales events. Conducting performance testing to assess how the website
performs under heavy load is essential to avoid potential bottlenecks.
Despite all the challenges throughout the testing process, we successfully designed and
executed test cases covering critical aspects of the Shein website, including user registration,
product search, add to cart functionality, checkout process, and account management.
 References

1. Seleniumhq.org. (2019). Selenium Documentation — Selenium Documentation.

2. http://www.seleniumhq.org/docs/
3. https://mindmajix.com/manual-testing-tutorial
4. https://www.simplilearn.com/tutorials/maven-tutorial/what-is-maven
5. Professionalqa.com. (2018). Software Testing Limitations |Professionalqa.com.
6. http://www.professionalqa.com/software-testing-limitations.
7. Bartlett, J. (2016). TestLodge. [Blog] What is Manual Testing?
8. https://blog.testlodge.com/what-is-manual-testing
9. Hetzel, B. (1941). The complete guide to software testing. 2nd ed. United states of America.
10. https://www.geeksforgeeks.org/software-engineering-prototyping-model/
11. https://www.guru99.com/software-engineering-prototyping-model.html
12. https://www.w3schools.in/sdlc-tutorial/spiral-model/
13. https://raygun.com/blog/software-development-life-cycle/
14. https://www.tutorialspoint.com/sdlc/sdlc_spiral_model.htm
15. https://sampletestcases.com/spiral-model/
16. https://testng.org/doc/documentation-main.html
17. https://smartbear.com/learn/automated-testing/what-is-automated-testing/
18. https://www.automationtestinginsider.com/2020/02/selenium-data-drivenframework with-
pom.html