Waterfall model:

Here, Software development progress through various phases like Requiremnets,

Design, Implementation, Verification, Maintenance
In this methodology testing team proceeds to the next phase only when the previous
phase is completed.

Advantages:
Very simple to plan and manage. Projects where requirements are clearly defined and
stated beforehand can be easily tested.

Disadvantages:

1. Next phase will be beginned only when the previous phase is completed. Hence
this model cannot accomodate unplanned events.
2. This method is not suitable for projects where the requirements change
frequently.

Iterative development model:

In this model, a big project is divided into small parts and each part is subjected
to different iterations. At the end of iteration
a new module is developed or an existing model is enhanced. This module is
integrated in the software architecture and the entire
system is tested all together.

Once the module is subjected to software architecture the entire system will be
tested. Feedback from testing team is immediately available
and is incorporated in next cycle.

Advantages:

Feedback from testing team is immediately available at the end of each iteration.
Any new changes will be immediately incorporated in the next cycle.

Agile methodology: AGILE methodology is a practice where continuous iteration of

development and testing takes place throughout the software development
lifecycle of the project. Both development and testing activities are concurrent in
this process.

In this process, a big project is divided into small parts and each part is
subjected to different iterations. At the end of iteration
a new module is developed or an existing model is enhanced. This module is
integrated in the software architecture and the entire
system is tested all together.

Once the module is subjected to software architecture the entire system will be
tested. Feedback from testing team is immediately available
and is incorporated in next cycle.

Types: 1. Scrum(Current one we are following) 2. Kanban

1. Scrum:
Scrum starts with the requirements in the form of user story that outlines how
features should perform and be tested. The team then cycles through
a series of sprints to provide small bursts of value quickly. Scrum calls for more
regular collaboration between testers, developers and
BAs, typically in the form of daily standups and sprint retrospectives, to ensure
proper communication and alignment.
Best practices for testers:
1.Determining acceptance criteria based on communication (typically in the form of
a user story) from a sales representative or
customer or product owner (note: this direct connection should help reduce
miscommunications).
2. Using the acceptance criteria to develop code and ensuring team approval of that
code .
3. Testing the code in sandbox-like environments as well as production-like
environments prior to deploying it to production.
4. Every iteration has its own testing phase. It allows implementing regression
testing every time new functions or logic are released.

Scrum Practices:

1. Sprint planning
2. Sprint
3. Daily scrum meet
4. Sprint review meeting
5. Sprint retrospective meet

As part of Scrum type, We will be having daily scrum meet to discuss about the
things that should be performed for that day.
Sprint review meeting where will discuss about the product that is developed as
expected.
Sprint retrospective meet to check what went well, what went wrong and areas to be
improved.

Process flow of Scrum methodologies:

1. Each iteration of a scrum is known as sprint.
2. Product backlog is a list where all details are entered to get end product.
3. During each sprint, top items of product backlog are selected and turned into
sprint backlog.
4. Team works on the defined sprint backlog
5. Team checks for the daily work.
6. At the end of the sprint, team delivers product functionality.

Software Testing Life cycle:

Software Testing Life Cycle (STLC) is the testing process which is executed in
systematic and planned manner. In
STLC process, different activities are carried out to improve the quality of the
product. Let's quickly see what
all stages are involved in typical Software Testing Life Cycle (STLC).

Software Testing Life Cycle (STLC) identifies what test activities to carry out and
when to accomplish
those test activities.
The different phases of Software Testing Life Cycle are:
a) Requirement Analysis: During this phase, test team studies and analyzes the
requirements from a testing perspective.
This phase helps to identify whether the requirements are testable or not. If any
requirement is not testable, test
team can communicate with various stakeholders (Client, Business Analyst, Technical
Leads, System Architects etc) during
this phase so that the mitigation strategy can be planned.
b) Test Planning: Test planning is the first step of the testing process. In this
phase typically Test Manager/Test Lead
involves determining the effort and cost estimates for the entire project.
Preparation of Test Plan will be done based
 on the requirement analysis. Activities like resource planning, determining roles
and responsibilities, tool
selection (if automation), training requirement etc.,
c) Test Design: Test team starts with test cases development activity here in this
phase. Test team prepares test cases,
test scripts (if automation) and test data. Once the test cases are ready then
these test cases are reviewed by peer
members or team lead. Also, test team prepares the Requirement Traceability Matrix
(RTM). RTM traces the requirements
to the test cases that are needed to verify whether the requirements are
fulfilled. The deliverables of this phase are
Test Cases, Test Scripts, Test Data, Requirements Traceability Matrix
d) Test Environment Setup: Development team or customer provides the test
environment. Meanwhile, test team should
prepare the smoke test cases to check the readiness of the given test environment.
e) Test Execution: Test team starts executing the test cases based on the planned
test cases. If a test case result is
Pass/Fail then the same should be updated in the test cases. Defect report should
be prepared for failed test cases
and should be reported to the Development Team through bug tracking tool (eg.,
Quality Center) for fixing the defects.

Defect life cycle: The different states of a bug in the bug life cycle are as
follows:
New: When a tester finds a new defect. He should provide a proper Defect document
to the Development team to reproduce
and fix the defect. In this state, the status of the defect posted by tester is
�New�.
Title -
Severity -
Priority -
Artifact -
Owners -
State - New
Assigned: Defects which are in the status of New will be approved (if valid) and
assigned to the development team by
Test Lead/Project Lead/Project Manager.
Ready for dev-
In dev -
Ready for Test -
In test -
Ready for showcase -
Re-opened

What is Severity?
Bug/Defect severity can be defined as the impact of the bug on the application. It
can be Critical, Major or Minor.
In simple words, how much effect will be there on the system because of a
particular defect.

Critical:
A critical severity issue is an issue where a large piece of functionality or major
system component is completely broken and there is no workaround to move further.

Major:
A major severity issue is an issue where a large piece of functionality or major
system component is completely
broken and there is a workaround to move further.
Minor:
A minor severity issue is an issue that imposes some loss of functionality, but for
which there is an acceptable & easily reproducible workaround.
For example, font family or font size or color or spelling issue.

What is Priority?
Defect priority can be defined as an impact of the bug on the customers business.
Main focus on how soon the defect should be fixed. It gives the order in which
a defect should be resolved. Developers decide which defect they should take up
next based on the priority. It can be High, Medium or Low.

Cucumber Intro: https://www.softwaretestinghelp.com/cucumber-bdd-tool-selenium-

tutorial-30/

A Behavior Driven Development (BDD) framework which is used with Selenium for
performing acceptance testing
1. A cucumber is a tool based on Behavior Driven Development (BDD) framework which
is used to write acceptance tests for
the web application(Prior point). Simply it defines the behaviour of a test case
with simple, Plain English.
2. It allows automation of functional validation in easily readable and
understandable format (like plain English) to
Business Analysts, Developers, Testers, etc(Prior point).
The basic concept of BDD test is to make the Test in Business readable format, so
that business users can understand it
easily.
3. Cucumber feature files can serve as a good document for all.
4. Initially, Cucumber was implemented in Ruby(language) and then extended to Java
framework.
5. Behavior Driven Development is an extension of Test Driven Development and it is
used to test the system rather
than testing the particular piece of code.
6. Cucumber can be used along with Selenium, Watir, and Capybara etc(web drivers).
Cucumber supports many other languages like
Perl, PHP, Python, Net etc

Cucumber Features and its usage:

1) Feature Files:
Feature files are the essential part of cucumber which is used to write test
automation steps
2) Feature:
This gives information about the high-level business functionality. Everybody
should be able to understand the intent of
feature file by reading the first Feature step. This part is basically kept
brief
3) Scenario:
Basically, a scenario represents a particular functionality which is under test.
By seeing the scenario user should be
able to understand the intent behind the scenario and what the test is all
about. Each scenario should follow given, when
and then format. This language is called as �gherkin�.
Given: As mentioned above, given specifies the pre-conditions. It is basically a
known state.
When: This is used when some action is to be performed. As in above example, we
have seen when the user tries
to log in using username and password, it becomes an action.
Then: The expected outcome or result should be placed here. For Instance: verify
the login is successful, successful
 page navigation.
Background: Whenever any step is required to perform in each scenario then those
steps need to be placed in Background.
And: And is used to combine two or more same type of action.

Example of Background:

Background:

Given user logged in as databases administrator

And all the junk values are cleared

Use case : After the requirements are clear, then the use cases can be
designed/decided which will clear the overall
flow of the system to developers first and then they can design the system
accordingly. Once the flow is clear to them,
then it becomes somehow simple to test the system by QA.

4) Scenario Outline:
Scenario outlines are used when the same test has to be performed with different
data set.
Examples:
|username |password |
|Tom |password1 |
|Harry |password2 |

5) Tags:Cucumber by default runs all scenarios in all the feature files. In real
time projects, there could be hundreds
of feature file which are not required to run at all times.

Implementation of Feature file(FF):

1. We have to implement these steps in Java and selenium in order to test the
feature files. Need to create a class which contains those given, when and then
statements.
Cucumber uses its annotations and all the steps are embedded in those annotations
(given, when, then).
2. Each phrase starts with �^� so that cucumber understands the start of the step.
Similarly, each step ends with �$�.
3. The user can use regular expressions to pass different test data. Regular
expressions take data from feature steps and pass to step definitions. The order
of parameters depends on how they are passed from feature file.
4. When you execute cucumber runner class, cucumber will start reading feature file
steps. For example, when you execute @smokeTest, cucumber will read Feature
step and Given a statement of scenario. As soon as cucumber finds Given the
statement, same Given statement will be searched for your java files. If the same
step is found in java file then cucumber executes the function specified for the
same step otherwise cucumber will skip the step.

Cucumber Project setup:

1. Create a new maven project
It looks as
src/main/java
src/main/resources
b.src/test/java(Create a class which will implement the steps)
a.src/test/resources(For feature files creation)
pom.xml
2. Add the dependencies(cucumber-java) in pom file
c.Create a JUnit runner to run the test.
 1 @RunWith(Cucumber.class)
2 @Cucumber.Options(format={"pretty(To display steps in
console)","html:reports/test-report"},tags= "@smokeTest")
3 public class CucumberRunner {
4 }
Note: The reports will store in �test-report� folder under project folder and
�pretty� format specifies the type of report.
Default report path: reports->test-reports->index.html.

@RunWith - This is a JUnit annotation that specifies which runner it has to use to
execute this class. You can see that we have provided Cucumber.class
as a parameter with this annotation. With this, JUnit will know that it has to
execute this test case as a Cucumber test.
@Cucumber.Options - This annotation provides some important information which will
be used to run your cucumber feature file.

Cucumber Options in runner class:

1. dryRun - It is used to check the mapping between feature file and step
definitions, If we miss implementing the step
definition for a particular feature file step it will let you know when runner
class is executed.
If dryRun = true, It will check mapping and the script will not be executed.
If dryRun = false, Script will execute as normal.
This option is really helpful when we have n number of fature files and step defns.
2. Features - It is the path where feature file is available, We can give multiple
feature files by separating comma or
we can give directly folder name where multiple feature files are available.
3. glue - The path of the step definitions.
4. Tags - Tags will be defined in feature file
5. Monochrome - To display the console output in a proper readable
format(recommended to use).
We need to define as monochrome = true
6. format - To generate different types of reporting
7. Strict - It will check if any step is not defined inside step definition file,
It will let you know to implement the missing steps.

Cucumber tags:
Cucumber has already provided a way to organize your scenario execution by using
tags in feature file. We can define
each scenario with a useful tag. Later, in the runner file, we can decide which
specific
tag (and so as the scenario(s)) we want Cucumber to execute.

Tag starts with �@�. After �@� you can have any relevant text to define your tag
like @SmokeTests just above the
scenarios you like to mark. Then to target these tagged scenarios just specify the
tags names in the CucumberOptions
as tags = {�@SmokeTests�}.

Tagging not just specifically works with Scenarios, it also works with Features.
Means you can also tag your features
files. Any tag that exists on a Feature will be inherited by Scenario, Scenario
Outline or Examples.

What are Hooks in Cucumber?

Cucumber supports hooks, which are blocks of code that run before or after each
scenario. You can define them anywhere
in your project or step definition layers, using the methods @Before and @After.
Cucumber Hooks allows us to better manage the code workflow and helps us to reduce
the code redundancy. We can say that
it is an unseen step, which allows us to perform our scenarios or tests.

Why Cucumber Hooks?

In the world of testing, you must have encountered the situations where you need to
perform the prerequisite steps
before testing any test scenario.

This prerequisite can be anything from:

Starting a webdriver
Setting up DB connections
Setting up test data
Setting up browser cookies
Navigating to certain page
or anything before the test

In the same way there are always after steps as well of the tests like:
Killing the webdriver
Closing DB connections
Clearing the test data
Clearing browser cookies
Logging out from the application
Printing reports or logs
Taking screenshots on error
or anything after the test

To handle these kind of situations, cucumber hooks are the best choice to use.

Unlike TestNG Annotaions, cucumber supports only two hooks (Before & After) which
works at the start and the end of
the test scenario. As the name suggests, @before hook gets executed well before any
other test scenario, and
@after hook gets executed after executing the scenario.

Webdriver implementation in cucumber stepdefinitions:

public class stepDefinition {

WebDriver dr;
@Given("^navigate to gmail page$")
public void navigate(){
dr=new FirefoxDriver();
dr.get("http://www.gmail.com");
}
@When ("^user logged in using username as \"(.*)\" and password as \"(.*)\"$")
public void login(String username,String password){
dr.findElement(By.xpath("//*[@id='Email']")).sendKeys(username);
dr.findElement(By.xpath("//*[@id='Passwd']")).sendKeys(password);
dr.findElement(By.xpath("//*[@id='signIn']")).click();
dr.manage().timeouts().implicitlyWait(20, TimeUnit.SECONDS);
}
@Then("^home page should be displayed$")
## Comparing two strings
public void verifySuccessful(){
String expectedText="Gmail";
String actualText=
dr.findElement(By.xpath("//*[@id='gbq1']/div/a/span")).getText();
Assert.assertTrue("Login not successful",expectedText.equals(actualText));
}
}

Data Driven testing Using cucumber:

1. Simple Data driven - Without Examples keyword.(Refer FreeCrmBDDFramework)

There are two types of regular expressions that can used to pass the data via
step definitions
a. \"(.*)\"
b. \"([^\"]*)\"
2. With Examples keyword+ Scenario outline(Refer FreeCrmBDDFramework)
3. Using tables(Data tables applicable for particular step) - Here we can
parameterize the hundreds of data using
Map concept. Refer FreeCrmBDDFramework for good understanding. This case will be
useful if we need to execute specific
data.
Maps in Data Tables:

Maps in Data Tables can be used in different ways. Headers/Columns can also be
defined for the test data. A same step
definition can be executed multiple times with different set of test data using
Maps.

Maps in Data Tables with Header:

In the previous tutorial video of Data Tables in Cucumber, we pass Username &
Password without Header, due to which
the test was not much readable. What if there will be many columns. The basic
concept of BDD test is to make the Test
in Business readable format, so that business users can understand it easily.

Webtable handling:

Below tags are generally defined in html tables:

1.�table� tag defines HTML table.

2.�tbody� tag defines a container for rows and columns.
3.�tr� defines rows in an HTML table.
4.�td�/�th� define the column of an HTML table.

Cucumber-JVM BDD Framework

PART-1
We have to implement page object model(approach or design pattern) in cucumber in
the form of BDD frame work
BDD - Behavioural driven development framework i.e defining the behaviour of the
framework or test cases or use cases(What exactly
the behaviour of the use case).
To define the BDD framework Gherkin is the language we are going to use.
To understand the cucumber, We have 3 different components
a. Feature file b. Step definition file c.Runner class
Feature file - With the help of standard keywords available in Gherkin, We will
define a scenario or scenario outline.

b. The corrsponding feature file code will be written in step definition file where
will use Selenium+Java+Annotations.
c. Test Runner class using Junit. The purpose of test runner is to run the feature
file, To generate the output/report.

So these are the three main componenets we need to create.

Prefer always maven project since dependencies can be added easily. Add supportive
jar files to the cucumber in POM.xml file. Ex: cucumber-junit
(Can write annotations and runner class), cucumber-java

What are the different dependencies you will be using with cucumber?
cucumber-java
cucumber-jvm
cucumber-junit
cucumber-jvm-deps
cucumber-reporting
gherkin
junit
selenium -java
Natural plugin(To make the keywords into Feature keyword) - Search in market
eclipse place, If not google it and just drag and drop in opened eclipse

Explain writing feature file, step definition and runner class (Example:
FreeCRMBDDFramework, Loginfeature and steps file)

PART-2
What are the different cucumber options available?
All the cucumber options will be defined in Runner class.
Sol: See content above
What are the different types of reports you can generate in cucumber?
We can generate html, json,xml reports. See Runner class in FreeCRMBDD framework
code.
Explain all the cucumber options available.

PART-3
How to achieve data driven testing in cucumber?(Since we are passing hardcoded
values in sendkeys method, To avoid hardcoded values going to use data driven
approach)
See related content above
How to achieve data driven testing using Examples Keyword and without Examples
Keyword.
Refer login.feature in FreeCrmBDDFramework.
What is the difference between Scenario and Scenario outline.
Whenever we use data driven approach using Examples keyword then it becomes
scenario outline, Without Examples keyword then we need to use Scenario.

PART-4

Data tables: Data tables will be applicable for particular step.(Refer

deals.feature and DealStepDefinition.java)
How can you approach data driven testing without scenario and scenario outline
In data tables The particular raw() method will return list of list of strings
because all the values passing are strings.
The problem in data tables is, If the data is increased i.e rows are added, The
same code has to be written again and again for every row.

PART-5
Now we are going to use Map object. (Refer dealsMap.feature)
Here for data tables, we can add header names and these names are going to act as
key and the data will act as value
Now particular asMaps() method will return Map object, It will store the values in
the key and value format.
How can you parametrize your test cases.
sol: By using Maps

PART-6
Cucumber Tags:See above content
Let's say I have 100 scenarios and i have to execute only particular scenarios
which are smoke tests, Then this concept
will come into the picture.
Refer tagging.feature in FreeCrmBDDFramework.
comma(,)means or, i.e it can execute either any of the tags

PART-7
Hooks in cucumber: Refer the content above
Hooks are used in the cucumber to define the preconditionds and post conditions in
the form of @Before and @After methods
Import the @Before and @After api's from cucumber not from junit
Give an example saying that, Launching the browser, Closing the browser before and
after each scenario.
For each and every scenario present in the feature file the before and after method
will execute.
The same will be applicable for the Scenario Outline also.
How to execute before and after methods for a particular scenario? Refer
taggedHooks.feature and stepdefinition file
Sol: That can be achieved by Tagged hooks. If we want to execute precondition for a
specific scenario.

Too much of hooks and tags will make confusing. Try to avoid and make simple,
robust and readable format

PART-8
Page Object model with Cucumber BDD Framework - Refer CucumberPOM
a. Baseclass - Where we initilaize the webdriver and browser we select and reading
the properties file (Done)
b. Page layer - Where we define all the page classes available. Here we will define
WebElements related to that
Particular page. All the page classes will extend the base class.
Ex: Login Page.java. It contains WebElements, login() Method which returns
HomePage object(landing page).
c. Feature file
d. Step definition
e. TestRunner class using Junit
All the above components gives the architecture of POM with cucumber BDD framework.
Next thing is each and every feature file step should be mapped with step
definition file.
Runner class has connection with step definition file and feature file.
What exactly we are doing in step def file is we will be creating number of methods
on the basis of feature file steps
and we are going to call these methods in the page classes. There is a link b/w
each and every page class with step def
files. This will give the basic architecture. Now lets start bulding it. Refer
CucumberPOM

Creation of base class is done and according to the architecture next step is
creating pages.(Done)
Whenever we are using @FindBy annotation , we need to initialize all the objects
available in that class using PageFactory class
Created Login page and Home page elements and corresponding actions. Next step is
to write feature file
Done with feature files. It's time to write step definition
Created step definition and started executing first step(TestBase.initialization).
Initially it will get NullpointerException since it's getting
property object prop as null because it hasn't been called . To avoid this we need
to extend TestBase class from step
def file since TestBase is the parent class, It will check for the constructor
defined and it executes since prop object
is initialized.

There are two types of HTML tables published on the web-

1. Static tables: Data is static i.e. Number of rows and columns are fixed.
Approach:

Below is the xpath of one of the cell in html table. Let�s say �firstname�

//div[@id=�main�]/table[1]/tbody/tr[1]/th[1]

tr[1] defines first row and th[1] defines first column.

If a number of rows and columns are always constant, let�s say our HTML table will
always have 5 rows and 3 columns.

for(int numberOfRows=1; numberOfRows<=5; numberOfRows++)

{
for(int numberOfCol=1; numberOfCol <=3; numberOfCol++)
{
System.out.println(driver.findElement(By.xpath
(�//div[@id='main']/table[1]/tbody/tr
[�+numberOfRows+�]/th[�+numberOfCol+�]�)));
}
}

2. Dynamic tables: Data is dynamic i.e. Number of rows and columns are NOT fixed.
(Example- ActiTime)
> Handling static table is easy, but dynamic table is a little bit difficult as
rows and columns are not constant.

a. First get the number of rows present the webtable.(Make Xpath upto
table/tbody/tr)
Xpath - int count =
/html[1]/body[1]/div[7]/div[1]/div[1]/div[1]/div[3]/table[1]/tbody[1]/tr

First row xpath

b. Row First input box -

/html[1]/body[1]/div[7]/div[1]/div[1]/div[1]/div[3]/table[1]/tbody[1]/tr[1]/td[1]/i
nput
String firstPath =
"/html[1]/body[1]/div[7]/div[1]/div[1]/div[1]/div[3]/table[1]/tbody[1]/tr["
String secondPath = "]"
firstPath+i+secondPath+ "/td[1]/input"
String finalXpath = firstPath+i+secondPath

c. not needed -
/html[1]/body[1]/div[7]/div[1]/div[1]/div[1]/div[3]/table[1]/tbody[1]/tr[1]/td[1]/f
ollowing-sibling::td[2]/input
d. Calendar xpath -
/html[1]/body[1]/div[7]/div[1]/div[1]/div[1]/div[3]/table[1]/tbody[1]/tr[1]/td[1]/f
ollowing-sibling::td[3]/child::*/child::*/child::*/child::*/child::td[2]/em/button
e. Type of work xpath -
/html[1]/body[1]/div[7]/div[1]/div[1]/div[1]/div[3]/table[1]/tbody[1]/tr[1]/td[1]/f
ollowing-sibling::td[4]/div/table/tbody/tr/td[2]/em/button

Second row xpath

b. Row First input box -

/html[1]/body[1]/div[7]/div[1]/div[1]/div[1]/div[3]/table[1]/tbody[1]/tr[2]/td[1]/i
nput
c. not needed -
/html[1]/body[1]/div[7]/div[1]/div[1]/div[1]/div[3]/table[1]/tbody[1]/tr[2]/td[1]/f
ollowing-sibling::td[2]/input
d. Calendar xpath -
/html[1]/body[1]/div[7]/div[1]/div[1]/div[1]/div[3]/table[1]/tbody[1]/tr[2]/td[1]/f
ollowing-sibling::td[3]/child::*/child::*/child::*/child::*/child::td[2]/em/button
e. Type of work xpath -
/html[1]/body[1]/div[7]/div[1]/div[1]/div[1]/div[3]/table[1]/tbody[1]/tr[2]/td[1]/f
ollowing-sibling::td[4]/div/table/tbody/tr/td[2]/em/button

Third row xpath

b. Row First input box -

/html[1]/body[1]/div[7]/div[1]/div[1]/div[1]/div[3]/table[1]/tbody[1]/tr[3]/td[1]/i
nput
c. not needed -
/html[1]/body[1]/div[7]/div[1]/div[1]/div[1]/div[3]/table[1]/tbody[1]/tr[3]/td[1]/f
ollowing-sibling::td[2]/input
d. Calendar xpath -
/html[1]/body[1]/div[7]/div[1]/div[1]/div[1]/div[3]/table[1]/tbody[1]/tr[3]/td[1]/f
ollowing-sibling::td[3]/child::*/child::*/child::*/child::*/child::td[2]/em/button
e. Type of work xpath -
/html[1]/body[1]/div[7]/div[1]/div[1]/div[1]/div[3]/table[1]/tbody[1]/tr[3]/td[1]/f
ollowing-sibling::td[4]/div/table/tbody/tr/td[2]/em/button

-----------------------------------------------------------------------------------
------------------------------------
Some Good Examples:
++link: Features
1. //a[text()='Features']
2. //a[contains(text(),'Features')] --recommended

++button:
//button[@type='button' and @class='btn']
//button[contains(text(),'Sign Up')]
//div[@class='dropdown']//button[@type='button' and @class='btn btn-secondary
dropdown-toggle' and @id='dropdownMenuButton']
//button[@id='dropdownMenuButton']

++preceding-sibling:
//a[text()='test2 test2']//parent::td[@class='datalistrow']//preceding-
sibling::td[@class='datalistrow']//input

++parent & preceding-sibling:

//a[text()='test2 test2']//parent::td[@class='datalistrow']//preceding-
sibling::td[@class='datalistrow']//input[@name='contact_id']
======================================================

BLACK BOX TESTING

It is verifying the functionality ( behavior ) against requirement specifications.
Types of Black Box Testing
1) FUNCTIONAL TESTING
Also called component testing. Testing each and every component thoroughly
(rigorously) against requirement specifications is known as functional testing.

2) INTEGRATION TESTING
Testing the data flow or interface between two features is known as integration
testing.
Ex:
Now let us consider the example of banking s/w as shown in the figure above
( amount transfer ).
Scenario 1 � Login as A to amount transfer � send 100rs amount � message should be
displayed saying �amount transfer successful� � now logout as A and login
as B � go to amount balance and check balance � balance is increased by 100rs �
thus integration test is successful.
Scenario 2 - Do positive and negative integration testing.

3) SYSTEM TESTING
It is end-to-end testing wherein testing environment is similar to the production
environment.

ACCEPTANCE TESTING
Acceptance testing is done by end users. Here, they use the s/w for the business
for a particular period of time and check whether the s/w can handle
all kinds of real-time business scenarios / situations.

SMOKE TESTING or SANITY TESTING or DRY RUN or SKIM TESTING or BUILD VERIFICATION
TESTING *** (Very very important interview question)
Testing the basic or critical features of an application before doing thorough
testing or rigorous testing is called as smoke testing.
It is also called Build Verification Testing � because we check whether the build
is broken or not.
Whenever a new build comes in, we always start with smoke testing, because for
every new build � there might be some changes which might
have broken a major feature ( fixing the bug or adding a new feature could have
affected a major portion of the original software).
In smoke testing, we do only positive testing � i.e, we enter only valid data and
not invalid data.

Why we do Smoke testing ?

Just to ensure that product is testable

AD � HOC Testing ( also called Monkey Testing / Gorilla Testing )

Testing the application randomly is called Ad-hoc testing.
Why we do Ad-hoc testing ?
1) End-users use the application randomly and he may see a defect, but professional
TE uses the application systematically so he may
not find the same defect. In order to avoid this scenario, TE should go and then
test the application randomly (i.e, behave like end-user and test)
2) Development team looks at the requirements and build the product. Testing Team
also look at the requirements and do the testing. By this method,
 Testing Team may not catch many bugs. They think everything works fine. In order
to avoid this, we do random testing behaving like end-users.

3) Ad-hoc is a testing where we don�t follow the requirements (we just randomly
check the application). Since we don�t follow requirements, we
don�t write test cases.

Test cases:
Test case is a document which covers all possible scenarios to test all the
feature(s).
It is a set of input parameters for which the s/w will be tested. The SRS are
numbered so that developers and testing team will not miss out on any feature.

When do we write test cases?

To have better test coverage � cover all possible scenarios and document it, so
that we need not remember all the scenarios
To have consistency in test case execution � seeing the test case and testing the
product
To avoid training every new engineer on the product � when an engineer leaves, he
leaves with lot of knowledge and scenarios. Those scenarios should be
documented, so that new engineer can test with the given scenarios and also write
new scenarios.
To depend on process rather than on a person

Test Case Design Techniques are,

Error Guessing
Equivalence Partitioning
Boundary Value Analysis (BVA)

Error Guessing :
Guessing the error. If the Amount text field asks for only integers, we enter all
other values, like � decimal, special character, negative etc. Check for
all the values mentioned above.

BVA � Boundary Value Analysis

If input is a range of values between A � B, then design test case for A, A+1, A-1
and B, B+1, B � 1.

Header of Test Case :

1) Test case name
2) Requirement number :
3) Module name :
4) Pre-condition :
5) Test data :
6) Severity :
7) Test case type :
8) Brief description :

REGRESSION TESTING : Testing the unchanged features to make sure that it is not
broken because of the changes is called Regression Testing.

SOFTWARE TEST LIFE CYCLE (STLC)

Testing itself has many phases i.e is called as STLC.
STLC is part of SDLC
Defect Life Cycle is a part of STLC

Use Case
Use case is a pictorial representation of requirements. It explains how the end
user interacts with the application. It gives all possible ways
 of how the end user uses the application.

Test Plan:
1) OBJECTIVE:- It gives the aim of preparing test plan i.e, why are we preparing
this test plan.
2) SCOPE :-
2.1 Features to be tested
2.2 Features not to be tested
3) TESTING METHODOLOGIES (Types of Testing)
Depending upon the application, we decide what type of testing we do for the
various features of the application
4) APPROACH
The way we go about testing the product in future
5) ASSUMPTIONS
When writing test plans, certain assumptions would be made like technology,
resources etc.
6) RISKS
If the assumptions fail, risks are involved
7) CONTINGENCY PLAN OR MITIGATION PLAN OR BACK-UP PLAN
To overcome the risks, a contingency plan has to be made. Atleast to reduce the
percentage from 100% to 20%
8) ROLES AND RESPONSIBILITIES
9) SCHEDULES :-
10) DEFECT TRACKING
In this section, we mention � how to communicate the defects found during testing
to the development team and
also how development team should respond to it. We should also mention the priority
of the defect � high, medium, low.
10.1 Procedure to track the defect
10.2 Defect tracking tool
10.3 Severity
10.4 Priority
11) Test Environment
Remaining things look into the document.

TRACEABILITY MATRIX
Traceability Matrix is a document which has got the mapping between requirements
and test cases. We write TM to make
sure that every requirement has got atleast 1 test case.
Advantages of Traceability Matrix:
Ensures that every requirement has atleast 1 test case
If suddenly requirement is changed � we will be knowing which is the exact test
case or automation script to be modified
We will come to know which test case should be executed manually and which are to
be done automatically.

DEFECT TRACKING
Defect : If a feature is not working according to the requirement, it is called a
defect.
Deviation from requirement specification is called as defect.

Test Execution Report :- Send it to customer � contains a list of bugs(major, minor

and critical), summary of test pass,
fail etc and when this is sent, according to the customer � the project is over.

Retrospect meeting � (also called Post Mortem Meeting / Project Closure Meeting)