Automation

Selenium Maven Java

A. Maven Repository

Figure 1.0 - Maven Repository

● Download and Install Dependency on Maven at

https://mvnrepository.com/artifact/org.testng/testng/7.7.1

B. Selenium WebDriver Test Case

Figure 1.0 - Selenium Maven Project Structure

Figure 1.1 - Sample Java File

 Figure 1.2 - Install Dependencies in Maven Project via pom.xml

● Selenium WebDriver Documentation

○ Ref: https://github.com/bonigarcia/webdrivermanager
○ Ref: https://bonigarcia.dev/webdrivermanager/
Figure 1.3 - Basic Script for Automating Sign In Process
C. Read Values from Property File

Figure 1.0 - Config.properties file for Storing Dynamic Data

 Figure 1.1 - Read File via FileReader() and Properties() Objects in Java

● Use SelectorsHub chrome extension to automate the determination of the XPath

expression. Ref:
https://chrome.google.com/webstore/detail/selectorshub/ndgimibanhlabgdgjcpbbndiehljc
pfh/related?hl=en
D. Variables in Base Class

Figure 1.0 - Edit or Put Variables inside Base Class,

Figure 1.1 - Instantiate Browser Setup 1

 Figure 1.2 - Instantiate Browser Setup 2

● In the tear down what we can do is we can simply close the browser right so usually in
the teardown what you do you, you close the browser. You log off the application so all
of that logic we can maintain or move it into the teardown right so we can simply say
driver.close().

Figure 1.3 - Teardown Method

Figure 1.4 - @BeforeTest Annotation TestNG

Figure 1.5 - @AfterTest Annotation TestNG

 Figure 1.6 - @Test Annotation TestNG

Figure 1.7 - Import BaseTest and utilize Extends BaseTest

 Figure 1.8 - Thread.sleep(4000)

● The Java Thread.sleep() method can be used to pause the execution of the current
thread for a specified time in milliseconds.
E. Remove Hardcoded FilePath in Framework

Figure 1.0 - User.dir

● This directory is named by the system property user. dir, and is typically the directory in
which the Java virtual machine was invoked. In other words, user. dir is the working
directory of the process that started the Java process at the time when it started the
process.
Figure 1.1 - User.dir 2

Figure 1.2 - User Path

F. Externalize Locators from Test Script

Figure 1.0 - Locators

Figure 1.1 - Locators Properties File

 Figure 1.2 - Externalized Locators

G. Create and Use TestNG.XML in Selenium

Figure 1.0 - Testrunner Folder for Multiple Test Cases

H. Data Driven Testing with TestNG DataProvider

● Data driven testing when we say data driven testing it is basically say for example you
want to iterate through the data so if there is a registration functionality so you want to
register 100 users on a web portal then you provide the user data for each of these
users and there is a single script that populates all that data right picking up the rows
from the excel sheet or from the data provider and populates all that data into the form
and submits the form right or does the user registration so you do not have to write
rewrite the script 100 times and hard code hundred percent or hundred people's data in
those hundred test cases single test case is enough as far as you have this data driven
approach.

● https://testng.org/doc/documentation-main.html#parameters-dataproviders

Figure 1.0 - DataProvider

Figure 1.1 - DataProvider to replace Hardcoded Data

Figure 1.2 - Pass DataProvider Parameters

Figure 1.3 - @BeforeMethod TestNG

Figure 1.4 - @AfterMethod

Figure 1.5 - BVT Test Suite
I. Excel for Getting Data

Reference: https://en.wikipedia.org/wiki/Apache_POI#:~:text=The%20name%20was
%20originally%20an,they%20were%20successfully%20reverse%2Dengineered.

● Apache POI, a project run by the Apache Software Foundation, and previously a sub-
project of the Jakarta Project, provides pure Java libraries for reading and writing files in
Microsoft Office formats, such as Word, PowerPoint and Excel.

● The name was originally an acronym for "Poor Obfuscation Implementation", referring
humorously to the fact that the file formats seemed to be deliberately obfuscated, but
poorly, since they were successfully reverse-engineered. This explanation – and those
of the similar names for the various sub-projects – were removed from the official web
pages in order to better market the tools to businesses who would not consider such
humor appropriate. The original authors (Andrew C. Oliver and Marc Johnson) also
noted the existence of the Hawaiian poi dish, made of mashed taro root, which had
similarly derogatory connotations.

Figure 1.0 - Excel Library (Apache POI)

Figure 1.1 - How to Use Excel for Getting Data
Figure 1.2 - Create Excel References (Get Row Count)

Figure 1.3 - Excel Utils 1 (getRowCount())

Figure 1.4 - Excel Utils 2 (getRowCount())

Figure 1.5 - Excel Utils 3 (getRowCount())

Figure 1.6 - Create Excel References (Get Cell Data)
Figure 1.7 - Excel Utils 1 (getCellData)

Figure 1.8 - Excel Utils 2 (getCellData)

Figure 1.9 - Excel Spreadsheet Data
Figure 2.0 - Excel Utils 3 (getCellDataNumber)

Figure 2.1 - Excel Utils 4 (getCellDataString)

Figure 2.2 - Excel Utils 4 (getCellDataString & getCellDataNumber Output)
 Figure 2.3 - Call Excel Functions

Figure 2.4 - Excel Utils 5 (Avoiding Hard Coding)

Figure 2.5 - Excel Utils 6 (Avoiding Hard Coding)

Figure 2.6 - Excel Utils 7 (Avoiding Hard Coding)

Figure 2.7 - Excel Utils 8 (Avoiding Hard Coding)
TestNG
● Ref: https://testng.org/doc/

Figure 1.0 - Download TestNG Jar from Maven Repository

Figure 1.1 - Include in Java Build Path the Downloaded TestNG Jar

Figure 1.2 - TestNG Successfully Added

 Figure 1.3 - Add TestNG Dependency inside the Pom.xml

Figure 1.4 - The Main Method in Java is Not Needed when using TestNG

● Execute classes and methods within that is through the annotations.

Figure 1.5 - Using of the @Test Annotation to Execute loginTest() Function
Figure 1.6 - Usage of @Test(priority=1) for the Sequence of the Execution of the Methods
Figure 1.7 - Added Description Attribute @Test(priority=1, description=”This is login test”)
Artillery
Jenkins

Figure 1.0 - Why We Need Continuous Integration

Figure 1.1 - Before Continuous Integration

Figure 1.2 - Continuous Integration Architecture

Figure 1.3 - Continuous Integration Workflow

Figure 1.4 - Before vs After Continuous Integration

Figure 1.5 - Pipeline

Figure 1.6 - Pipeline Architecture
 Figure 1.7 - Types of Pipeline

Figure 1.8 - Build Plugin Pipeline

 Figure 1.9 - Build / Job failure (Jenkins Job)

● Continuous Delivery pipeline (Dev-Uat-Prod) using Build Plugin Pipeline

○ Ref: https://www.youtube.com/watch?
v=HkSwqt8ZTfM&list=PLVz2XdJiJQxwS0BZUHX34ocLTJtRGSQzN&index=3
○ Ref: https://www.youtube.com/watch?
v=HkSwqt8ZTfM&list=PLVz2XdJiJQxwS0BZUHX34ocLTJtRGSQzN&index=3

Figure 2.0 - Build Pipeline View

 Figure 2.1 - Build Pipeline Plugin

Figure 2.2 - Build Pipeline Sample (Dev-UAT-Prod)

Regression

Figure 1.0 - What is Regression Testing

Figure 1.1 - Regression Testing Techniques
Figure 1.2 - Regression Testing: How to Select Tests
Smoke Testing vs. Sanity Testing

● Package or Software builds - particular programming language to implement

functionalities

● Basically smoke testing came from the smoke testing done by the plumbers and usually
the plumbers used to do smoke test whenever they used to find or they wanted to find
any leakage into the pipes right so what they did is they physically say for example this
is the pipe and they wanted to find the leaks so if there are you know if they'll seal it
basically from one side or whether whether it's sealed and then from one side they'll put
you know like smoke within it and if there is you know like any smoke coming out of this
particular pipe then they will recognize that yes there is a leakage within the pipe right so
this is how plumbers used to do smoke testing.

Figure 1.0 - Smoke Testing for Build-1 as an Example

● Smoke testing is shallow approach and can be done by developers and testing team as
well because uh developers will ensure that the the build is successfully installed and
testing team will ensure that the key functionalities of the application are working as
expected right and this is most of the time in the initial development phases when the
build is relatively unstable okay so you do the smoke testing to ensure that key
functionalities are working as expected.

○ During the Initial phase when the builds are relatively unstable

○ Detailed testing

● Sanity testing is when the builds have become stable and you are verifying some of the
key functionalities after the defect fix or the new functionality is being added.

Figure 1.2 - Sanity Testing

● When the build becomes stable then you do the sanity testing if there is any new fix or
new defect fix or new functionality that comes in so you do a sanity check of the defect
fix module or the or the new module that came in before you get into the detailed
regression or the full regression cycle right so b progress further or everyone in the test
team can progress further with the detailed testing of the build.