What is testing????

It is a process of validating whether the application has been developed as per the
client requirement or not.
If there is any deviation between client requirement and the application under
test, we will file the bug in bug tracking tool and will assign the bug to the
developer to fix.
Once the bug has been fixed by the developer, we will verify and close the bug.

The different types of environments are for Testing:

1. Local environment
2. Dev environment
3. QA environment
4. UAT/Stage environment
5. Production/Live environment
If we need to check performance of the application there is another
environment between QA and UAT i.e. performances testing environment.

1. Local Environment:-
The coding will be developed by the developers on their own machines.
Once the code has been developed, Developer will perform Unit testing
once Unit testing is done. He will check in the code to perforce tool/any
version control tool.

Perforce: - perforce is a tool which can manage the versions of the code.
There are some other tools like GIT, GIT HUB, SVN and CVS etc.

2. Dev Environment:-
The code will be checked out from perforce and deployed to dev
environment by Release manager or developer. The developer will test the
functionality of application whether the integrated code is working as per
the requirements or not. If he faces any bugs developer will modify the code
in the local environment and the fixed code will be deployed to dev.
Functionality: Behavior of an application, we call it as functionality. (Login/Logout)
3. QA Environment:-
The code will be checked out from perforce and deployed to QA
Environment by Release Manager or QA Lead. QA will executed the test
cases, If there is any deviation between Test case and Application under
Test, he will file the bugs in bug tracking tool and will assign to the
developers. Once the bugs have been fixed by developers, he will verify and
close the bugs.

4. UAT/Stage Environment:-
The code will be checked out from perforce and deployed to UAT/Stage
Environment by Release Manager. QA will prepare and execute the UAT test
cases, if the build is stable (bug free) UAT environment will be handover to
the client. Client will execute the end to end scenario which has been
prepared by him. If the application is defect free then it will be deployed to
production environment else client will reject the build. QA has to file the
bugs found in stage environment or sometimes client will file the bugs and
Dev team has to fix them ASAP.

5. Production Environment:-
The code will be checked out from perforce and deployed to Production/Live
Environment by Release Manager. QA will perform Smoke followed by
Sanity testing. If the application is defect free then the QA will send a release
email to the team (Client, Dev team, QA team). If QA finds any bugs in
production, he has to file the bugs and Dev team has to fix them ASAP. And
the fixed code should be released to production on the same day.

We have following live application (Live/Production) i.e.

www.gmail.com,www.facebook.com
Note:-Release email contains the release notes like “New Functionality”
released, “Bugs which got fixed” etc.
 Web Application Architecture
DEV/QA/UAT Environments
Client Server Business layer Data Layer

Mobile
Browser
Web Server Application
Server Database

Web Browser

File System External

System/API
Application

3 – Tier Architecture: The Web Server, Application Server and Database Servers
are physically separated but internally integrated with each other for processing
data is called 3-tier architecture.
If we try to access any browser through Mobile/Laptop or any other Applications –
the address will hit the web server where the static pages will contains and
interlinked with Application Server where the business logic will contains the Java
Codes, JAR Files and War Files and to reduce load on main server we can keep a
File System. The Database server will contains the entire Table forms like user
tables, address tables, payment tables and pin code tables and we can use External
System/Application Program Interface (API’s) which will communicate with the
third party payment gateway. For example third party payment gateways like
Credit / Debit and UPI’s transactions. (Google is an Entire architecture)
What is a Web Server?
A Web Server is a software application which handles HTTP requests sent by the
HTTP Client, like Web browsers, and returns web pages in response to the clients.
Web servers usually deliver html documents along with images, style sheets, and
scripts.

List of Web Servers:

Apache web server – the HTTP web server
Apache Tomcat, Microsoft’s Internet Information Services (IIS) Windows Server
Nginx web server, lighttpd, Oracle Web Tier

What is Application Server?

An application server exposes business logic to client applications through various
protocols, possible including HTTP. While a Web server mainly deals with sending
HTML for display in a Web browser, an application server provides access to
business logic for use by client application programs.

List of Application Servers:

GlassFish, WebLogic, Jboss : Usually used for Java
IIs – Microsoft Internet Information Services – Usually used in dotnet.

What is DATABASE server?

A database server is a server that provides other servers/systems with services
related to accessing and retrieving data from a database. Access to the database
server may be through an application via a “front end” running and displayed on a
user’s machine (e.g. phpMyAdmin), or “back end” running on the database server
itself (e.g. from the command prompt using a command such as mysql). After the
information within the database is retrieved it is outputted to the user requesting
the data.
Many companies utilize a database server for storage. Users can access the data by
executing a query using a query language specific to the database. For example,
SQL is a good example of a query language.
List of Data Base Servers:
Oracle – Oracle Based Servers, MySQL, DB2, Teradata
Commonly Used Commands in Linux Server for Testing:
1. ls : Command line utility for listing the contents of directory
Syntax – $ ls
2. ls – ltr : Long list (It Provides the important file attributes such as
Permissions, User / group of file / Size / date – last changed)
Syntax - $ ls - ltr
3. id : Id prints real user id and various other details related to the account
Syntax - $ id (Displays user Id)
4. pwd : It prints present work directory of the user
Syntax – pwd
5. cd : Change Directory - this command will helps you to change the current
directory
Syntax - $ cd
6. mkdir : Creates new Directory
Syntax - $ mkdir
7. rm : rm command is used to remove a file or directory . The –r option is
being used to remove in a recursive way with –f (forcible) you force the
removal, ignoring errors and never prompt.
Syntax - $ rm – rf <Filename> or $rmdir –rf <directory> or rm –rf *.pdf
8. cp : copy a file in the linux shell. To copy a folder with its contents recursively
use the cp and with – r flag.
Syntax - $cp <Source file - Path> <Destination file – Path>
9. mv: renaming or moving a file or directory
Syntax - $ mv <old name> <New Name>
10.tree: Displays directory structure
Syntax - $ tree
11.grep : The grep filter searches a file for a particular pattern of characters
Syntax - $ grep ‘filename’
12.ps : ps command will find the particular process with ID.
Syntax - $ ps
Syntax - $ ps – ef |grep <filename>
13.kill -9 : It helps to kill the process of the application
Syntax - $ kill -9 <Process ID>
Before we can check the process ID with $ ps
14.cat: short for concatenate. Cat command allows us to create single or
multiple files and appends and execute.
Syntax - $ cat file1 (Single) with extension / $ cat file1 file2 (ctrl d+)
15.chmod – change mode access
Syntax - $ chmod 777 <filename> or chmod u+x <filename>
Read(r ) – 4 , Write (w ) – 2, Execute (x) – 1 and no.permission (0) – 0
16.Top – shows the summary information of the systems and the list of process
of threads. (PID/User/Priority task-PR/% CPU/SHR-Shared memory)
Syntax - $ top
17.head :To know the above lines of the file
Syntax - $ head – 10f <logfile name>
18.tail : to know the last lines of the file
Syntax - $ tail -10f <logfile name>
19.du : Estimates disk space
Syntax - $ du or $ du –a (documents to know) or du –h (human readable).
Syntax - $ sudo – sh / var
20.sudo: “Sudo” command is super user to do. Super user can do all the
processing and have access rather than normal user. They can change
systems setting, change system properties and change permission
access(add or deletion)
Syntax - $ su <username>
Syntax - $ sudo –s ( for create password) to login into sudo user
21.Start and Stop Server (./ start.sh or sh start.sh) and (./stop.sh or sh stop.sh).
Access to the user a/c with sudo or root privilege
22.find : To find the files and filter by wild cards. We can find and filter
Syntax - $ find. –name <file chars or extension>
Syntax - $ find./ GFR –name sample.txt ( finds in Specific Directory)
23.vi editor: vi editor command is widely used in the linux by QA engineers.
Syntax - $ vi <filename>
I – Inserts : this mode enables you to insert text into the file
Esc – to terminate and comes to command linen
u- undo last change
U – undo all changes in the entire line
o- open a new line
dd – deletes line
3dd – deleted 3 lines
D – delete contents of the line after cursor.
 C – delete contents of the after the cursor and insert new text
dw – delete word, 4dw – delete 4 words
cw- Change word
x – delete character at cursor
r – replace char and R – overwrites char from cursor
s – substitute one char under cursor continue to lines
S – Substitute entire line and begin to insert at beginning of the line
~(tilde) – changes case of individual char
‘-a’ – write after cursor
‘-A’ – write end of the line
‘:w’ – Save text
‘:q’ – quit without save
‘:qw!’ – save and Quit
‘Shift+ZZ’ – save and quit
‘Ctrl+R’ – to re do.

Root Cause Analysis for a Valid Bug Filing:

Before filing / Logging the bug to the Developer through bug tracking tool. We
have to thoroughly verify whether it is a valid bug or not by root causing analysis
i.e logging into the linux Server using “Putty”. We can verify the logs how the bug is
occurred, whether it is occurred by Coding or database server or any connection
issues or whether the Database server is down. Once we confirmed that the bug is
a valid we can file/log the bug in bug tracking tool to the Developer to fix.
When we have to file the bug through bug tracking tool the scenario is like
below:
1. New – Assigned to Developer – In Dev – Fixed ready for QA – Verify & Close (
Valid bug will fix )
2. Assigned to Developer – Duplicate or As Per Design or Deferred or Not
Reproducible ( When the valid bug not filed) – Assign to QA
3. Reassigned to Developer – if Bug not fixed properly
4. Re-Open – After some time the same bug will occurs
Bug Life Cycle Theory:
Whenever we will try to file a bug through bug tracking tool the status is New,
after assigning to the Developer the status is assigned to developer, developer may
check that the bug is valid or not, if the developer is not facing the bug in his local
environment he will mark to QA that the bug is Not – Reproducible, if the bug is
valid i.e he is also facing the same issue/bug in his local environment the developer
will accept the bug through IN Dev and the status is In Dev , after fixing the bug
Developer will inform to QA that the bug has been “fixed and Ready for QA”. QA
will test the fixed bug, if we will face the same issue again we will reassign to
developer or if the fixed bug is working as per FRS we will verify and Close. If we
are filing a bug to the developer without verifying in our bug tracking tool, whether
the bug has been filed by other team members or not, in that cases the developer
will mark it as duplicate “bug” or FRS has been changed by client and the same was
not updated by the QA in his QA Test cases and QA assigned the bug to the
developer, in that cases developer will mark that it as “as per design”. If we filed
the bug but the module has been moved out from the particular release or not
required by the client then the developer will mark it as deferred, in this case
developer himself will close the bug or QA will close the bug. Some days later if we
will face the same bug then the QA can Re-Open the bug.
How to file the bugs in bug tracking tool with the Severity Priority

Severity: Seriousness of the Bug with functionality

Priority: How soon the bug should be addressed by developer is Priority

Find some examples to file the bug to developer.

Filing Critical or Showstopper severity of Bugs and its Priority – P1:

1. Short Description – Unable to Join Meeting

Steps:
1. Hit https:// qa.webex.com
2. Enter host link in the Join Meeting Address bar
3. Click Join Button

Actual Value/Results : Not taking me into the Meeting Room

Expected Value / Results: Join me in the Meeting Room

Severity: Critical or Showstopper

Priority: P1

Filing High severity Bugs and its priority – P1/P2:

1. Short Description – Unable to Scan QR Code for payment.

Steps:
1. Hit https:// qa.googlepay.com
2. Open Payment Option
3. Select QR Scan for payment
4. Click to Proceed

Actual Value/Results : QR Scan Disabled Payments allowed only through Mobile No.
Expected Value / Results: Payment to be accepted through QR Scan and Mobile

Severity: High, Priority: P1/P2

Filing Medium severity Bugs and its priority – P2/P3:

1. Short Description – Unable to find Chat Box

Steps:
1. Hit https:// qa.webex.com
2. Click on Join Meeting
3. In Meeting Window Person Chat Option not Showing

Actual Value/Results : unable to find the Chat box

Expected Value / Results: User can chat through Chat Window

Severity: Medium,Priority: P2/P3

Filing Low severity Bugs and its priority – P3/P4:

1. Short Description – Unable to Change Text Fonts

Steps:
1. Hit https:// qa.gmail.com
2. Login with valid credentials
3. Home Page / Compose Mail

Actual Value/Results : Unable to Change Written Text as “Bold”

Expected Value / Results: User can change Text Fonts

Severity: Low, Priority: P3/P4

Steps to Filing a Bug in Bug Tracking Tool: Whenever we are getting a bug in QA environment we will file
that bug in bug tracking tool, While filing the bug we will give the short description of the synopsis, steps
to reproduce along with that we have to give severity and priority. Severity and Priority will be given by
the QA Engineer, if the severity and priority is not proper QA lead can be change/ update the actual
severity of the bug. If the developer will fixed it that is fine if not bug triage meeting will be conducted by
the manager to know the status of bugs to be fixed by Developer as well as QA to validate.

Bug / Defect Triage Meeting:

If QA Engineers has filed the 30 bugs to the developer, in that bug list developer is able to fix the 10 bugs
only left another 20 bugs. To discuss about 20 bugs meeting will be conducted.

Meeting will be conducted with team i.e in that Meeting QA Lead, QA Members, Developers, Dev lead
and Project Manager will be there to discuss about the 20 bugs left by developer. The Manager will ask to
developer how much time it will take to fix the 20 bugs. Developer will reply that you want me to fix this
particular bug it will take 2-3 hours to fix a bug. In the same way Manager will ask to QA how much time it
will take to validation whether the bug got fixed or not / to do the regression testing.

Developer is unable to fix all the bugs, so the manager will pick the bugs according to the severity. He will
pick all P1 /P2 Bugs and he will ask the developers to complete this within three days that we are
reaching to Point of time to submit the enhanced application. So, how much ETA (Expected time of
Arrival) is required to fix. So, developer is request that we can fix some severity bugs and the remaining
bugs will be moved to next sprint, but the status is open i.e. assigned to developer only.

**We are having a bug triage meeting, in that meeting QA Lead, QA Members, Developers, Dev lead and
Project Manager will be there to discuss about the bugs which are in open state and they are targeting
the Severity P1/P2 bugs which are high and medium or which will be impact in the functionalities if it
released. So, they will triage the particular bugs stating that how much time (ETA) / efforts required to
developer to fix and QA to test and close the particular bugs and the remaining bugs moved to the next
sprint or release. The moved / low severity bugs status will be the same as “Assigned to dev” only, they
won’t change the status.

Regression Testing:
Regression testing is defined as a type of software testing to confirm that a recent program or code
change has not adversely affected existing features.

Regression testing is nothing but a full or partial selection of already executed test cases which are re-
executed to ensure existing functionalities work fine.

This testing is done to make sure that new code changes should not have side effects on the existing
functionalities. It ensures that the old code still works once the latest code changes are done.

Differences between “Error”, “Bug and Defect” and “Exception”

Error: Whenever the developer unable to handle the code properly it will throw errors. In Unit Testing
when the developer is validating the piece of code or validating his logic has been developed as per
requirement or not he might get error. i.e syntax errors or semantic errors.

QA is testing a web page he might see some java script errors – we have file this as bug.

Bugs and Defects: Both are same

Exception: Whenever the developer has handled that particular error it will throw an exception.

Exception is an abnormal condition. An exception is an event that disturbs the normal flow of the
program. It is an object which is thrown at runtime.

Null Point Exception: Whenever java code is looking for parameters or some value and that value it has
to get it from API’s , if the API has given Null value then it will throw Null Point Exception.

Exception: Which can be handled?

Error: Which can’t be handled?

Bug Tracking Tool: ( BugZilla, Squish List, JIRA, QC and Team Tracker)
1. Bug tracking tool may vary as per the Project Requirement
2. Linux server configured with bug tracking tool
3. We have to open Linux server through Host/IP Address but masking with name:
www.tcs.bugzilla.com
4. We can Loging through our SSO (Single Sign on), which will be given to QA at the time of Joining
in the Organization.

While we open a bug tracking tool, we can get a Template:

 1. We will get the template where functionalities / features like Create New Bug, already Open
Bugs ,search , advance search, download the excel work book for all the bugs we can download,
we can update, we can modify the status we can.
2. By Clicking the New / Create button where we have to file a bug. In that we will have version no,
short description, steps to reproduce, build no, modules to select, developer to select,
attachments to attach logs or screen shot of bug. After submitting we will get the bug ID like:
10001 unable to open Fund Transfer or unable to create new A/c. We will get the email after
filing a bug.

Software Development Life Cycle:

Waterfall Methodology: WATERFALL MODEL is a sequential model that divides software development
into pre-defined phases. Each phase must be completed before the next phase can begin with no overlap
between the phases. Each phase is designed for performing specific activity during the SDLC phase.

Waterfall model can be used when

 Requirements are not changing frequently

 Application is not complicated and big
 Project is short
 Requirement is clear
 Environment is stable
 Technology and tools used are not dynamic and is stable
 Resources are available and trained

What is Agile Methodology?

AGILE methodology is a practice that promotes continuous iteration of development and testing
throughout the software development lifecycle of the project. In the Agile model, both development and
testing activities are concurrent, unlike the Waterfall model.

1. Customer can monitor the requirements, he can change any point of time

2. He can have short releases

3. He can get revenue out of it and he can invest again it depends upon the competitor

4. He can add some more features if he can.

What is Agile Software Development?

The Agile software development methodology is one of the simplest and effective processes to turn a
vision for a business need into software solutions. Agile is a term used to describe software development
approaches that employ continual planning, learning, improvement, team collaboration, evolutionary
development, and early delivery. It encourages flexible responses to change.

The agile software development emphasizes on four core values.

1. Individual and team interactions over processes and tools

2. Working software over comprehensive documentation
 3. Customer collaboration over contract negotiation
4. Responding to change over following a plan

Scrum:
Scrum is an agile development method which concentrates specifically on how to manage tasks with-in a
team-based development environment. Scrum believes in empowering the development and advocates
working in small teams. It consists of three roles, and their responsibilities are explained as follows:

Scrum Master: scrum master is responsible for setting up the team, sprint meeting and removes obstacles
to progress.

Product Owner: The Product Owner creates product backlog, prioritize the backlog and is responsible for
the delivery of the functionality at each iteration.

Scrum Team: Team manages its own work and organizes the work to complete the sprint or cycle.

Scrum Calls: Daily meeting we are attending is scrum calls.

Sprint Planning Meeting (2-3 Weeks Sprint):

In the Agile we are getting the requirements in the form of stories, these stories will be discussed in one
meeting i.e sprint planning meeting. The manager will discuss with the developers and QA that we can
release the stories within the sprint size or not(i.e 2-3 Weeks). Once sprint planning meeting completed
the stories will be assigned to the Developers and QA Lead for testing. QA Lead will assign the sub stories
for Testing to QA Members if required.

Agile with Scrum Process for Software Development : When we get the requirements
from the product owner that will be fed into the JIRA Project Management tool so, from JIRA will have
sprint planning meeting will discuss about stories , once the stories has been assigned to me I will create
the sub task and I will give the effort estimation for that. So once that has been done I will start working
on the particular story and if I’m having any issues we are having daily scrum calls will discuss about the
issues or any dependency like database or any other which I’m facing and once the particular task has
been completed I will mark that as completed in JIRA. Rector Spectrum Meeting: So, once the particular
sprint has been completed we will go with rector spectrum meeting to discuss what went wrong in the
previous sprint and what should be corrected as part of next sprint. So that all the stories chosen for the
particular sprint we can cover in the next sprint accordingly.

In this we have velocity graph checking – how many team members are there and how much time it will
take to complete the Sprint.

Burned out chat – how munch percentage of work done and how much percentage is left to done

Sprint backlog – whenever in that particular sprint if any story has been moved to next sprint, we call it as
sprint back log.

Whichever story not completed and that will be moved to the next sprint is called sprint back log. The
Sprint back log will be picked-up in next sprint it depends up on the product owner.

Software Development Life Cycle:

The Business analyst will gather all the requirements from the Product Owner and add to the JIRA and the
Technical Architect will study the feasibility whether we can develop the story as required by the Product
owner in that Sprint size once the feasibility study completed designer will design the High Level Modules
and Low Level Modules after completion of the design, development team will start the coding /
development of the story, completed story will assigned to the QA for Testing if the testing is completed
with all bug fixing and all it will be moved to the Implementation and Maintenance or Product Launch.

Types of Bugs: 1. Sticky Bugs, 2- Masked Bugs, 3 – Seeding Bugs

Sticky Bugs:

Masked Bugs: A Masked Defect is a defect already existing in the software, however, it hasn't caused any failure in
the application execution mainly because it is covered or masked by another defect

Seeding Bugs: Defect seeding is a practice in which defects are intentionally inserted into a
program by one group for detection by another group.

MANUAL TESTING PROCESS

Levels of Testing:
1. Unit Testing: Unit Test will be done by the Developer in their local environment. They will create
another class in a folder called unit testing folder, and the class name is unit test unit test fund
transfer. So it is very important for a developer to create unit test cases for each and every class
because before moving that code, he has to validate with all the probabilities whether that
particular code is working as per the requirement or not.

Definition-1: Once the developer has developed a piece of code he will validate whether the
particular unit is working as per the business logic or not for that reason he will create a calling
class and he will pass different set of arguments like Valid and Invalid set of arguments to validate
that particular unit has been developed as per client / customer requirement or not.

**Before integrating code with the UI (User Interface), developer will perform Unit testing in the
local environment.
Definition-2: Developer will create a calling class and he will pass set of arguments like valid and
invalid set of arguments to check whether the piece of code has been developed as per the
business logic / customer requirement or not.
Unit testing will be done by Developers only.
2. Module Testing: If we combine two or more than two units that we will call it as module, if any
one perform testing on top of that is called as module testing.
Developer will perform module testing in his local environment where in more than two units of
code has been integrated. The Developer will check the data flow between one unit to another
unit is working as per the client requirement or not after integration is called module testing.
Example: When we Transfer a fund and the transferred amount should reflect in accounts
statement.
3. Integration Testing: Individually the Modules are working fine but after integration how the data
flow will work is called Integration Testing. Integration testing can be done on dev environment;
in integration testing if one module is not ready they will add the hard coded values to validate
their functionality.
Example: While making Ganesh Idol makers will put cement ball on hand instead of laddu which
is not yet ready to put on hand. So makers put cement ball on hand and they will remove cement
ball after got ready of laddu.
The Integration test can be done in Dev Environment by developer or QA – Depends on the
Project. If a QA is validating he can’t raise the bugs in bug tracking tool.
 If developer will push the code with hard coded values to QA, we can file the bugs in bug tracking
tool.
***Capturing Response Code from the API that we call it as Hard Coded value.

4. System Testing: System Testing means, you are testing in a QA Environment where the hard
coded values are not there, application has been developed as per the customer requirement,
and application has been developed in that customer environment only. So the customer
requested that I want to deploy this particular application on Weblogic, Tomcat and Oracle, so
the application deployed there only.

Definition-1: System Testing is performed on a complete integrated system to evaluate the

compliance of the system with the corresponding requirements of the client. System testing
detects defects within both the integrated units and the whole system. System testing tests the
design and behavior of the system and also the expectations of the customer.

We can perform functional and non functional testing in system testing.

Definition-2: when we are testing that application in QA Environment that application has been
deployed as per customer request. In system testing we are trying to test a complete application
and that application deployed in the Environment which has been specified by the client.

Difference between Integration Testing and System Testing: We can perform functional and non
functional testing in system environment but in integration we can do only functional testing. In
integration testing we might face hard coded values but in system testing we won’t see any hard
coded values. System Testing will be done by the QA in QA Env.

5. UAT (User Acceptance Testing)Testing: UAT ulr: stage.icici.com

In UAT we will test the end to end scenarios. We will verify whether everything is working fine or
not, then we will give the application URL to Client. Client will certify this particular application
has been developed as per his requirement or not. If we found any bugs – in UAT – the developer
will fix with in the 24 Hrs / 48 Hrs max. In UAT, url will be accessed outside the Organization to
check the working status of the application by the client.

Test Plan for Testing:

A Test Plan is a detailed and high level document that describes the test strategy, objectives,
schedule, estimation, deliverables, and resources required to perform testing for a software
product. Test Plan helps us determine the effort needed to validate the quality of the application
under test.
Plan is a high level document, as a QA lead I’m preparing the plan so that team and stack holder
will be in the same page.
In that Plan - I will perform data base testing, automation testing and manual testing
How to write a Test Plan
You already know that making a Test Plan is the most important task of Test Management
Process

1. Analyze the product

2. Design the Test Strategy

3. Define the Test Objectives
4. Define Test Criteria
5. Resource Planning
6. Plan Test Environment
7. Schedule & Estimation
8. Determine Test Deliverables

Walk through: Definition: After Completion of our Test Plan we will explain the test plan to the
client each line by line how we are going to test and what we are doing in the test in test plan and
the same we have to take approval from the client to proceed further.

Ex: for this particular sprint we will test 4 stories and these are the story no / story names.
We are going to perform 4 Test cases and I’m going to validate the data base testing, I’m
going to perform functional testing.
Objective of Plan: Whenever the application has developed by the developer, all the
functionalities should work as per the customer requirement if not working we file the bug
that is an Objective.
Scope: Scope will contain In-Scope and Out of Scope
In Scope: In Scope contains all the stories which we are going to the cover as part of this
particular sprint or Particular release. (In Story we can have story no, story details, module
names, functionality details, enhancement details)
Out of Scope: the modules which we are not going to cover and which we are not going to
cover types of testing is out of scope. (Performance and API Testing’s)
Entry and Exit Criteria: When to Start Testing and When to Stop Testing
Build: A build is the process of converting source code files into standalone software
artifact(s) that can be run on a computer.

**Smoke Testing: Whenever any build has been deployed to the QA Environment, we will
perform initial testing to validate the Build is stable enough for the further testing or not. We
will verify whether the important features and functionalities are working fine and there are no
showstoppers in the build that is under testing.

Example: Bike given to repair and brake pads were broken and mechanic fixed and we will
check the bike at mechanical showroom, if it is working fine we will give money and come
Advantages of Smoke testing

 Easy to perform testing

 Defects will be identified in early stages.
 Improves the quality of the system
 Reduces the risk
 Progress is easier to access.
 Saves test effort and time
 Easy to detect critical errors and correction of errors.
 It runs quickly
 Minimises integration risks

Entry Criteria: Once the build is stable or once we are done with smoke testing, if the smoke
testing is passed we can start our testing
Exit Criteria: Once P1/P2 bugs are fixed and P3/P4 has been triaged we can stop our
testing.

Functional Testing and Functionality Testing:

Functionality means the behavior of the application, how it is behave

Functional Testing: IN functional Testing we will perform both functionality and GUI Testing

What is functionality testing: Verifying the behavior of the application?

What is GUI Testing: Verifying the Graphical Functions in Graphical User Interface, like Color, Tab,
Template, Logo

Non-Functional Testing is also called as a Performance Testing: If we open an application how much
time it is taking is called performance of the application and we will measure the time

Functionality testing is performed to verify that an application performs and functions correctly
according to design specifications. During functionality testing we check the core application
functions, text input, menu functions and installation and setup on localized machines, etc.

Functional Vs Non-Functional Testing:

Functional Testing Non-Functional Testing

Functional testing is performed using the Non-Functional testing checks the

functional specification provided by the Performance, reliability, scalability and
client and verifies the system against the other non-functional aspects of the
functional requirements. software system.

Functional testing is executed first Non-functional testing should be performed

after functional testing
 Manual Testing or automation tools can be Using tools will be effective for this testing
used for functional testing

Business requirements are the inputs to Performance parameters like speed,

functional testing scalability are inputs to non-functional
testing.

Functional testing describes what the Non-functional testing describes how good
product does the product works

Easy to do Manual Testing Tough to do Manual Testing

Examples of Functional testing are Examples of Non-functional testing are

 Unit Testing  Performance Testing

 Smoke Testing  Load Testing
 Sanity Testing  Volume Testing
 Integration Testing  Stress Testing
 White box testing  Security Testing
 Black Box testing  Installation Testing
 User Acceptance testing  Penetration Testing
 Regression Testing  Compatibility Testing
 Migration Testing

TYPES OF TESTING:
SMOKE TESTING: Smoke Testing is the initial testing performed on the released build to validate
whether the critical functionalities of the applications are working fine or not. If it is not working we will
reject the build and we will wait for patch build. If the smoke is passed then we will move to execute
regression test cases.

Some of the Organizations are following the Below Mentioned Process for Smoke
Testing:
1. Without having automation scripts, without having manual test cases, just they are validating all
the major functionalities are available or not.
2. They will have a formal testing where they will prepare all the test cases for the smoke they will
execute one by one if the smoke test cases passed they will execute the regression test cases
3. They will prepare the smoke automation scripts using selenium or any of the tools they will
execute on top of the application which has been deployed in QA Env. If anything is not working
they will reject the build and wait for path build.
SANITY TESTING: Sanity Testing is performed to validate when any bug fix /
enhancement have been done and no further issues are introduced due to these
changes.
EX: Some External API’s has changed and we will validate our application
functionalities which are dependent on that Particular API’s only.

In sanity we will check sub functionalities also when it comes to Production.

Difference between Smoke and Sanity Testing:

Smoke Testing Sanity Testing
Smoke Testing is performed to Sanity Testing is performed to validate
ascertain that the critical when any bug fix / enhancement have
functionalities of the program are been done and no further issues are
working fine. introduced due to these changes is
called Sanity Testing.
EX: Some External API’s has changed
and we will validate our application
functionalities which are dependent
on that API’s.

Smoke Testing is usually documented Sanity Testing is usually not

or Scripted documented and is unscripted but
sometimes we might execute the
partial test cases.
On Production Environment we will perform only sanity testing and we will
execute read only activities. We won’t execute any test cases in production. If
client gives the permission to execute write also we will execute.
Points to note.

 Both sanity tests and smoke tests are ways to avoid wasting time and effort by quickly
determining whether an application is too flawed to merit any rigorous testing.
 Sanity Testing is also called tester acceptance testing.
 Smoke testing performed on a particular build is also known as a build verification
test.
 One of the best industry practices is to conduct a Daily build and smoke test in
software projects.
 Both smoke and sanity tests can be executed manually or using an automation tool.
When automated tools are used, the tests are often initiated by the same process that
generates the build itself.
 As per the needs of testing, you may have to execute both Sanity and Smoke Tests in
the software build. In such cases, you will first execute Smoke tests and then go
ahead with Sanity Testing. In industry, test cases for Sanity Testing are commonly
 combined with that for smoke tests, to speed up test execution. Hence, it's a common
that the terms are often confused and used interchangeably

Release Note: we will give all the story details which has been released to production and
fixed bug details.

In QA/UAT – the definition will change – We will perform sanity when an External API’s has
been modified we will try to execute the test cases are dependent on those API’s.

Regression Testing:
Regression testing is defined as a type of software testing to confirm that a recent program or code
change has not adversely affected existing features.

Regression testing is nothing but a full or partial selection of already executed test cases which are re-
executed to ensure existing functionalities work fine.

This testing is done to make sure that new code changes should not have side effects on the existing
functionalities. It ensures that the old code still works once the latest code changes are done.

Let’s try to summarize the Software Testing Life Cycle (STLC) it now!

S.No Phase Name Entry Criteria Activities Performed Deliverables

1 Requirements Requirements Do brainstorming of the RUD

specification requirements. Create a list of ( Requirements
document requirements and get your understanding
doubts clarified. document.
Application
design document Understand the feasibility of Testing feasibility
the requirements whether it is report
User acceptance testable or not.
criteria document Automation
If your project requires feasibility report.
automation, do the automation
feasibility study.

2 Planning Updated Define the scope of the project Test Plan document.
requirements
document. Do the risk analysis and Risk mitigation
prepare the risk mitigation document.
Test feasibility plan.
reports “ Test estimation
Perform test estimation. document.
Automation
feasibility report. Determine the overall testing
strategy and process.
S.No Phase Name Entry Criteria Activities Performed Deliverables

Identify the tools and

resources and check for any
training needs.

Identify the environment.

3 Analysis Updated Identify the detailed test Test conditions

requirements conditions document.
document

Test Plan
document

Risk Document

Test estimation
document

4 Design Updated Detail out the test condition. Detailed test

requirements condition document
document Identify the test data
Requirement
Test conditions Create the traceability metrics traceability metrics
document
Test coverage
metrics

5 Implementation Detailed test Create and review the test Test cases
condition cases.
document Test scripts
Create and review the
automation scripts. Test data

Identify the candidate test

cases for regression and
automation.

Identify / create the test data

Take sign off of the test cases

and scripts.

6 Execution Test cases Execute the test

cases Test execution
report
Test scripts Log bugs / defects in case of
discrepancy Defect report

Report the status Test log and Defect

S.No Phase Name Entry Criteria Activities Performed Deliverables

log

Updated
requirement
traceability metrics

7 Conclusion Updated test cases Provide the accurate figures Updated traceability
with results and result of testing metrics

Test closure Identify the risks which are Test summary report
conditions mitigated
Updated risk
management report

8 Closure Test closure Do the retrospective meting Lessons learnt

condition and understand the lessons document
learnt
Test summary Test matrices
report
Test closure report.

HAPPY TESTING!!

Regression Simple Definition:

Whenever any enhancement (It Might be Code/Functionality/GUI/Database /

Migration) or bug fix made on to the existing application we will do regression to
validate due to this enhancement / bug fix other functionalities which are working
fine got affected or not.

Regression testing is nothing but a full or partial selection of already executed test
cases which are re-executed to ensure existing functionalities work fine.
This testing is done to make sure that new code changes should not have side
effects on the existing functionalities. It ensures that the old code still works once
the latest code changes are done.

Partial Regression Testing:

Where we will execute the test cases or the functionalities which will be affected
due that particular bug fix we will do partial regression. The tractability matrix is
interlinked with partial regression.

If we don’t have a time we will execute P1/P2 test cases followed by ad-hoc testing
What is Re-Testing, when we will do Re-Testing, tell me with example?

Re-Testing: Testing the application with different set of data is called Re-Testing

a) When we execute the same test cases with different set of data
b) When we are trying to reproduce the bug with different set of data or in
different peers machines.
Example:
a) if we want to validate the register page of Gmail i.e every text box field
has their own validations so depend upon the validations we will write
test data in test cases with different set of data.
Steps:
1. Hit www.gmail.com
2. Click on Signup button
3. Enter Valid data in first name like – (Hema, Hemanth, Hemanth1982) –
Min – 4 and Max-12
4. Enter Valid data in other text fields and click submit button
b) If we got a bug say “send mail” is not working
We will try to reproduce the same issue on IE, FF and other browsers as
per client requirement to see if it is really a code issue or browser issue.
Say it is not working on both browsers and its working on IE and not
working on FF, we will file a bug and we will send it to appropriate
developer, once the bug got fixed and the code is pushed to QA
Environment we will do re-testing i.e we will execute the steps which
we have provide in the bug and will verify if the bug is fixed or still exist.
If the bug is fixed then we will close the bug else we will re-assign to
developer.

Re-Testing is a Part of Regression Testing

Exploratory Testing:

Exploratory testing is done to explore the application and is done to get the
knowledge of the application in this user tries to understand the application as well
as functionalities of application.

Example: Banking Domain and Insurance Domain or E-Commerce Domain

What is Ad-hoc Testing or Define Ad-hoc Testing when you will perform ad-hoc
testing?

It is a type of random or free style testing performed on the application without

using the test case document, unlike formal testing in order to cover the functional
areas which are not covered with test case coverage and to refine the test cases
document ultimately.

Ad-hoc testing is done by QA, who is having application knowledge.

We will perform Ad-hoc testing in the following scenarios?

1. This testing is conducted when there is no time for complete testing (i.e no
time to execute all the test cases). In this testing we will test main
functionalities of the application randomly.
2. When we have execute the entire test cases and we have left with time then
we will do ad-hoc testing to cover some corner which was not covered in
test document
3. When we don’t have any proper document like(Test cases, FRS), we will do
ad-hoc testing by using our application knowledge

Ad-hoc is a part of regression testing

Ad-hoc is also called as Monkey Testing

Black Box Testing

Black Box Testing is a software testing method in which the functionalities of software
applications are tested without having knowledge of internal code structure, implementation
details and internal paths. Black Box Testing mainly focuses on input and output of software
applications and it is entirely based on software requirements and specifications. It is also
known as Behavioral Testing.

White Box Testing

White Box Testing is software testing technique in which internal structure, design and
coding of software are tested to verify flow of input-output and to improve design, usability
and security. In white box testing, code is visible to testers so it is also called Clear box
testing, open box testing, transparent box testing, Code-based testing and Glass box testing.
Compatibility Testing:

Testing application in different hardware and Software environment is called

compatibility testing. We will do this type of testing with client server and desktop
applications. (This can be done on System Testing)

.Exe file is different (32 bit / 64bit) for each and every different operation system

Browser Testing:

We are trying to validate whether the application is compatibility with different

browsers are not. Not only the Browsers but also the different versions.

Validate on IE / GC/FF - any versions.

Session Testing:

Testing the application session expire time is called session testing, the developer
will write the test session expiry time in web.xml file.

<Session-Config>

<Session-timeout>10</Session-timeout>

</Session-Config>

For Example: if Session timeout is given as 30Mins in web.xml file and if the user is
sitting idle for 30 mins. In 31st minute, the user will try to do any operation on that,
the session will be expired and the user will be taken to the default login page. If
the user is doing any action on 29th minute the count will be reset to 30 mins.

We can do testing by deleting session cookies once cookies are deleted the user
should be taken to default login page.

Session ID: Session ID is the Unique ID which will be generated by the session
programming which has been developed by the programmer.

Whenever we will login, Application server will send the session ID, every time it
will create session id for each login with different Session ID’s.
Define Cookies:

Cookies are usually small test files, given ID tags that are stores on your computers
browser directory. Cookies are created when you see your browser to visit a
website that uses to keep track of your movements within the site, help you
resume where you left off, remember your registered login, theme selection,
preferences and other customization functions.

There are Two Types of Cookies:

1. Session Cookies or Non Persistent Cookie: These are temporary cookie files
which are erased when you close your browser. When you restart your
browser and go back to site the website will not recognize you. You will have
to log back in (If login is required) or select your preferences theme again if
the site uses these features. A new session cookie will be generated, which
will store your browsing information and will be active until you leave the
site and close your browser.
Example: Session cookies allow users to be recognized within a website so
any page changes or item or data selection you do is remembered from page
to page. The most common example of this functionality is the shopping cart
feature of any e-commerce site. When you visit one page of catalog and
select some items, the session cookie remembers your selection so your
shopping cart will have the items you selected when you are ready to
checkout. Without session cookies, if you click CHEKOUT, the new page does
not recognize your past activities on prior pages and your shopping card will
always be empty.

2. Persistent Cookies: These files stay in one of your browsers sub folders until
you delete them manual.

Security Testing: This involves confirming the identity of a person.

Authentication: **Only authorized user can use that application or not.

If we are trying to login with valid username and password, we will check we are
able to login or not into the application. If we are trying to login with valid
username and Invalid Password, that means that the authentication is not proper.

Authorization: Authorization is a process that comes after a successful

authentication; QA has to verify only authorized users should be able to access a
specific module which has been assigned to that user.
ACL-Tool: Which can give permission to you i.e allocation of roles and
responsibilities

Usability: How user friendly application has been developed

Usability Testing also known as User Experience (UX) Testing, is a testing method
for measuring how easy and user-friendly a software application is. A small set of
target end-users, use software application to expose usability defects. Usability
testing mainly focuses on user's ease of using application, flexibility of application
to handle controls and ability of application to meet its objectives.

Navigation: Navigation tests analyze how users navigate through your website or
application, given a specific task or goal. The results help you hone critical user
flows, and improve your information architecture.

Pagination: List of items displayed more than one Page and the displayed pages
are properly navigated or not.

Accessibility: ability and disability persons should be access the application

End to end Testing: End-to-end testing is a technique used to test whether the
flow of an application right from start to finish is behaving as expected. The
purpose of performing end-to-end testing is to identify system dependencies and
to ensure that the data integrity is maintained between various system
components and systems.
The entire application is tested for critical functionalities such as communicating
with the other systems, interfaces, database, network, and other applications.
Use Case: Use case plays a significant role in the distinct phases of the Software
Development Life Cycle. Use Case depends on ‘User Actions’ and ‘Response of
System’ to the User Actions.

It is the documentation of the ‘Actions’ performed by the Actor/User and the

corresponding ‘Behavior’ of the System to the User ‘Actions’. Use Cases may or
may not result in achieving a goal by the ‘Actor/User’ on interactions with the
system.
Test Case’s
Before writing Test Case’s we should know the techniques to write proper Test
Case Document.
1. Boundary Value analysis
2. Equivalence Partition
3. Error guessing Mechanism
4. Decision making charts / tables
Boundary Value Analysis: Instead of entering all the values to check the
application, we can use a formula i.e lb+1,lb-1,ub+1,ub-1 ( Lower Bound and
Upper Bound) which will give us Positive and Negative Values to Test.
Equivalence Class Partition: whenever we are writing a test case we will segregate
positive and Negative test case’s which is called equivalence class partition.
Error Guessing Mechanism: whenever we will try to leave fields as blank or enter
alpha numeric or special characters is called error guessing mechanism
Decision making chart / tables: The decision table is a software testing technique
which is used for testing the system behavior for different input combinations.
This is a systematic approach where the different input combinations and their
corresponding system behavior are captured in a tabular form.
Depend upon our Input the functionalities are changing.
Test Case Document Template:
1. Test Case ID : TC-Module Name-Version – 0001
2. Test Description : Test Description which we are going to verify
3. Pre-Condition : Where the user is
4. Test Data : What we are testing for
5. Steps : Write Steps, taking data from Test Data
6. Excepted Result : Write Expected Results if tested the data
7. Actual Result : Actual Results will write after testing
8. Status : If test meets exp. And Actual test will “Pass” or “Fail”
9. Bud ID : Test Fail
10.Remarks : Any Notes
After that we will prepare test data document for an application module by using
the Test Template in Excel.
Sample Test Cases Example
T.I TEST EXPECTED ACTUAL
DESCRIPTION TEST STEP STATUS
D SCENARIOS RESULT RESULT

1 login Test the login 1.Launch the Login should as Pass

credentials functionality of the application be success expected
web application to 2.Navigate the
ensure that a login page
registered user is 3.Enter valid
allowed to login with username
username and 4.Enter valid
password password
5.Click on login
button

2 Adding item Able to add item to 1.Select Item should Item is Fail
functionality the cart categories list get added to not
2.Add the item to the cart getting
cart added to
the cart

3 Sign out Check sign out 1. select sign out The user User is Fail
functionality functionality button should be not able
able to sign to sign
out. out

Example 1: Test Scenario for eCommerce Application

For an eCommerce Application, a few test scenarios would be

Test Scenario 1: Check the Login Functionality

In order to help you understand the difference Test Scenario and Test Cases, specific test
cases for this Test Scenario would be

1. Check system behavior when valid email id and password is entered.

2. Check system behavior when invalid email id and valid password is entered.
3. Check system behavior when valid email id and invalid password is entered.
4. Check system behavior when invalid email id and invalid password is entered.
5. Check system behavior when email id and password are left blank and Sign in
entered.
6. Check Forgot your password is working as expected
7. Check system behavior when valid/invalid phone number and password is entered.
8. Check system behaviour when "Keep me signed" is checked

As evident, Test Cases are more specific.