Software:

Set of programs given as instructions to any machine which will respond to user
requests.
Software testing :
1)Verifying or checking application feature functionality is working as expected
or not.
2)Testing is an application with an intention to identify bugs.
Bug:
1)Any feature not working as tester expected.
2)Deviation between expected and actual result.
Error:
i)Mistake in a program.
Types Of Error:
a) Compile Time Error:- syntacally error
b) Runtime Error:-While executing program.
Note:-
i)Because of mistakes made by the developer tester will identify bugs.
ii)If the tester identifies a bug means runtime error is identified.
Software Testing:-

3)Testing an application with intention to identify mistakes(error)made by developers.

Q 1] Who required software?

-> Customer who handles business.
Q 2] When will customers fill in to use software in business?
-> If it is difficult to handle business manually.
Q 3] When we should perform testing?
-> Once application is completely developed before realising product to customer.
Q 4] Why should we do testing ?
-> i)To improve quality of application.
ii)To avoid loss in customer business.
iii)To check if an application supports customer business or not.
iv)To identify bugs.
Types of testing:-

Types of application:-
1] Web application :-
Applications which need to be accessed using a browser.
2]Client server application:-
Applications which need to be installed in local machines & to
access the internet are mandatory .

3]Stand Alone Application:-

Applications which need to be installed in a local machine without
the internet can access applications.

Types of application layer :-

1]Presentation layer:HTML/CSS?Angular JS/JS
2]Midware /Business logical layer : J2EE/Python/.Net /PHP/C#/JS
3]Backend/database layer: Oracle/ SQL/NoSQL/My SQL
Server:
Server is a machine with huge configuration which can be accessed by multiple users
& data can be stored at centralised location.
 TESTING SYLLABUS
1)Software Development Life cycle:
a]Waterfall Model
b]Spiral Model
c]Prototype Model
d]V&V Model
e]Hybrid Model
f]Agile Model
2)Testing Types
A)White Box Testing
1]Statement Coverage
2]Path Testing
3]Conditional Testing
4]Loop Testing
5]Memory Point Of view Testing
6]Performance Point Of View Testing
B)Black Box Testing
1]Functional Testing
2]Integration Testing
3]Smoke Testing
4]System Testing
5]Ad Hoc Testing
6]Acceptance Testing
7)Compatibility Testing
8)Exploratory Testing
9)Usability Testing
10)Sanity Testing
11)Globalisation Testing
12)Regression & Retesting
13)Performance
3)Test Cases:
1)Test Scenario
2)Test Case Design Tech
3)Test Case Documentation
4)Request Traceability Matrix
5)Procedure To Write T.C
6)Procedure To Execute T.C
4)Software Testing Life Cycle(STLC)

5)Defect Life Cycle

6)Test Plan
7)Tools:a)Defect Tracking Tool:Bugzilla /Mantis
b)Test Management Tool:JIRA/Test LInk/QC

Software developing procedure:

1) Customer will prepare requirement document.(CRS) and send it to business analysis.

2) BA will converts CRS to SRS document.
3) Once project manager selected feasibility static meeting will be conducted analys
customer needs.
4) In this meeting business analyst will explains customer needs to project manager,
architech financial & HR.
5) Onces project team is setup BA will share requirment with both developing &testing
teams.
6) Develops by refering to requirement documents develops application.
7) Developing team will performs WBT and send product to testing team.
8) Testing team by referring to requirement performs BBT.
9) If they identifies any bug prepare bug report and sends to developing team.
10) Developer will fix bug and send product to testing team.
11) Testing team should retest bug fixed or not.If bug is fixed continue testing.
12) If bug is not fix again send it to develops.
13) This iprocess will continue untill application is bug free,stable and realise product to
customer.

SOFTWARE TESTING PROCEDURE:-

*Customer will prepare requirment document and send it to project manager.
*Project manager will share requirment with both developing and testing team.
*Both the teams will analys requirment if they face any difficulty clarify with BA or
customer
*By the time architech will setup developing and testing environment.
*To develop application developer will use following approaches.

APPROACH 1:-
In this approach developers will develop complete application perform
white box and send application to testing team.
LIMITATIONS:
1)Both developing and testing team are not working together.
2)Chances are there tester are not perform effective testing so quality
Might get affective.
3)Overall project cost and duration might get increase.
APPROACH 2:-
In this approach developer will develop few features and send it to
testing team.
While testing team test that features developers will create new features.
ADVANTAGES:
1)Both developing and testing teams works together.
2)Overall project cost and duration reduced.
3)Tester can perform affective testing and product quality might be
Improve.
#Once few features are develop.Developer will compile, compress programs and creates
a file.(i.e.build)
BUILD: 1)It’s piece of software which contains few features.
2)It’s piece of software which contains compiled and compressed programs.
3)Its piece of software which converts programs to features.
*Developing team will install build01. In testing environment.
*Testing team will refering requirement test features or build one,if they identifies any bug
send it to developers.
*While testing team is busy in testing build1 developing team will develop build2.(Adding
new program old program.
*Once build testing is completed developers send new build.
*This process will continious untill all features are completely develop and realise
product to customer.
*When a build came for testing test lead will decides test cycle duration.Within that test
cycle testing team should test all develop features. If they identifies any bug send it to
developers.

*Developer will fix the bug in next week.

*Onces build is completely tested developing team send new build. But every test cycle
testing team will receive only one build
*Chances are there tester might identify blocker bugs.So developer need to fix that
blocker bug immediately and sends respin in same test cycle.

Test Cycle:-
Time taken by testing team to test build.
Blocker Bug :-
It’s type of bug which will not allow tester to perform further testing.
Respin:-
More than one build same test cycle.No of respin in test cycle depends on no of
blocker bugs found by testing team

WHITE BOX TESTING:-

Testing each and every line of code in set of programs.
White Box Testing is also known as open box or transparent because code is visible to
developers.
In White Box developers use to test each and every program so it is also
known as Unit Testing.
Developer is first person to test the product.
1) How to perform White Box Testing?
Approach 1]:-
In this approach developer will review source code which is
develop by him.

Approach 2]:-
In this approach developer will review other developer written code.
Approach 3]:-
In this approach other project team developer will review source
code i.e(peereview).

2)Why we should do White Box Testing?

a)To reduce cost of fixing a bug.
b)To identify mistake or errors at initial state.
c)To check develop program work as excepted pr not.
d)To have confidence whether develop program supports customer business or
not.
E.x:Bookmyshop
Req:-
i)It should accept i 1 to 10 digits.
ii)It should not accept alpha,special character,negative no’s,
decimal,Expression, blank and space.

*White box testing can be perform manually or by using Automation?

White Box testing is reputative task which need to be perform after every build
development developer will use Automation.
In automation developer will write scripts to check main program.

Procedure to perform white box testing using automation:

1)By referring to
requirement developer develops main program & to test that main program
parallely script will be created.

2)All the testscripts will be converted into suite file or XML file.

3)To perform White Box Testing XML file will be executed.

4)Each test script will execute main program if main program works fine then
testscript will pass otherwise fail.

5)Once all testscripts are executed report will be generated.

6)By referring to report if any test scripts is fail then main program will be
modified & XML file will be reexecuted.

7)Once all testscripts are pass White Box Testing is passed & send build to
testing team.

To do White Box Testing Developers Will Use Following Techniques:

1)Statement Coverage:-
In this technique developers will check each and every
statement in set of programs.

Class
{
int a; //statement 1
Int b; //statement 2
if(a==b)
{
Print”same” //statement 3
}
Else
{
Print”not same” //statement 4
}
}

100% statement coverage =2

Conditional Testing:
In this technique developer will check each and every condition for
both True and False.In set of programs.

Request:Banking App.
a.Account holder can transfer amount within range 500-50,000.

Class Amt_Transfer
{
Int amt;
Int current_bal;
if(amt>=500&&amt<=50000&&amt<=current_bal)
{
Transfer amount
}
Else
{
print”Error Message”;
}

Sr.no amount Current condition1 condition2 condition3 Result

balance

1 500 1,00,000 T T T Transfer

2 100 1,00,000 F T T Error

3 60,000 1,00,000 T F T Error

4 10,000 100 T T F Error

Loop Testing:
In this technique developer will checks each and every loop is executing for all
possible iterations or not.

Ex.Banking App
a.In a day, Account holder can do max 4 transactions.
b.Each transaction Account Holder can transfer max.50,000.

Class Transaction
{
Int amt;
Int Currentbal;
Int count;
while(count<=4)
{
if(amt>=500&&amt<=50000&&amt<=currentbal)
{
Transfer amt;
count ++;
}
else
{
Error message;
break;//stop loop execution
}
}

sr.no Ammount Current balance Count Iteration

1 1000 1,00,000 1 4

2 25,000 50,000 1 2

3 1000 10,000 4 1

Path Testing:
In this technique developer will checks each and every individual path in set
of programs.

Memory point of view Testing:

In this technique developer will concentrate on reducing
size of the application.
Some common mistakes that can be made by developers.
1)Because of repetition of coding
To overcome this,developer should use generic method(common).
2)Because of using wrong logic:
Ex.
Int a=10; int c=10;
Int b=a; -------> print c;
printc=b; o/p:-10
o/p:-10
3)Because of unused variables and methods:
 To identify unused variables and methods developers will use rational
purifier tool.
This tool will analyze each and every program identifying unused variables
and method and generates reports by referring to that report developer will
decides whether to keep variables or method for future reference or to remove.

Performance point of view Testing:-

In this technique developer will
checks each and every program execution or response time.
Developer will use rational Quantifier tool To perform performance point
of view testing .
This tool will executes each program,analys execution time and generates
output in the form of thin and thick lines.

Black Box Testing:

Verifying or checking application features functionality
by referring to the requirement document.
Black Box Testing is also known as closed box because code is not
visible to tester .It is also known as Behaviour Testing As we test each feature's
functionality.

Que:Difference between White Box Testing and Black Box Testing.

White Box Testing Black Box Testing

1.In WBT we will check each program 1.In BBT we will check each feature
functionality.

2.It is performed by developers,Sometimes 2.Only Testing team

testers if they have coding knowledge.

3.To perform WBT internal coding is required 3.To perform BBT coding knowledge not
. require

4.As code is visible it is known as open box 4.As code is not visible it is known as closed
testing. box testing.

5.To perform WBT developer use technique 5.To perform BBT tester will use testing types
like statement coverage. like functional ,integration etc.

1)Functional Testing :
Testing each and every component completely or thoroughly
or rigorously by referring to requirement document.
SRS document for signup page .
1.When a user accesses an application by entering URL .
1.2.It should contain the following features.
a.Sign Up
B.login
2. When user clicks on sign up button.
2.1. Sign up page should be displayed.
2.2. It should contain following features.
2.2.1.Username
a.It should accept 6 to 12 characters.
b.It should accept numbers,special characters,blank,space and operators.
2.2.2. Password
a. It should accept 8-15 char
b. It should be combination of alpha + number.
c. Only one special char allowed(optional).
d. Blank and space not allowed.
2.2.3.Email Id
a.Should accept a valid email id.
2.2.4DOB
a.should accept valid DOB.
2.2.5 Contact
a.Should accept a 10 digit number.
b.Alpha , no’s ,spl.char, decimal, space , expression not allowed.
2.2.6 Gender
User should select anyone
a.Male
b.Female
2.2.7:Sign up button
When a user clicks on the sign up button with valid data in mandatory fields.
a. Home page should display.

1) In function testing we need to test each component by using all possible

inputs(valid&invalid).
*Rules to perform Functional Testing:-
a)Understand the requirement.
b)Priorities the feature.
c)Always test all components in web page completely then switch to the next page.
d)Always test one component at a time.
e)Always perform valid test first then checks for invalid.

*Procedure to perform functional testing:

step1)Understand the requirement for component.
step2)Identified all possible inputs and document.
step3)Test component with identified inputs.
step4)If any input not working as expected then status is fail and prepare bug report.

Username:
a.It should accept 6 to 12 char.
b. It should accept only alpha.
c.It should not accept number, special character,blank and space , operators.

Sr.No Action Inputs Expected Actual Result Status

Result

1 Enter 6 char dingaa Should accept pass

username accept
with alpha

2 Enter 12 char abcdefghijkl Should accept pass

username accept
with alpha

3 Enter 8 char abcdefgh Should accept pass

username accept
with alpha

4 Enter<6 char abcd Should not accept fail

username accept
with alpha

5 Enter >12 fdafsjdfjdsajfx Should not accept fail

char accept
username
with alpha

6 Enter 123456 Should not accept fail

username accept
with numbers

7 Enter dinga123 Should not accept fail

username accept
with alpha
+number

8 Enter dinga@1234 Should not accept fail

username accept
with
alpha+splcha
r

9 Leave blank Should not accept fail

 accept

1o Enter Should not Should not fail

username accept accept
with space

#Functional testing on related fields:-

Password
Dinga@1

Confirm Password

Functional testing on related fields :-

Password

Dinga@1

Confirm Password

1) Enter same text-Dinga@1

2) Enter different text –manager

3) Enter same same text in reverse -1@agniD

4) Enter same text in uppercase –DINGA@1

5) Enter same text in lowercase – dinga@1

6) Enter same text upper in lower case and lower in upper- dINGA@1
7) Leave blank –

8) Enter space –

9) Enter same text in password field and change the password field text

#Functional testing on date of birth field:-

DOB :

DD MM YYYY

(01-31) (01-12) (2000-2020)

Case 1:

V/I V V

Case 2:

V V/I V

Case 3:

V V V/I

Case 4:
 I I I

Case5: Special case

Case 1:

V/I 03 2005

(01/31)

1)01/03/2005

2)31/03/2005

3)15/03/2005

4)0/03/2005

5)33/03/2005

6)-1/03/2005

Case 2: (01-12)

04 V/I 2001

1)04/01/2001
2)04/12/2001

3)04/05/2001

4)04/00/2001

5)04/13/2001

6)04/one/2001

7)04/1.2/2001

Case 3: 2000-2020

01 08 V/I

1)01/08/2000

1)01/08/2020

1)01/08/2010

1)01/08/1+2

1)01/08/1999

1)01/08/2021

1)01/08/….

Case 4:
 I I I

00/00/0000

-1/1.2/1+2=3

@/**/****

Case 5:Special case

31/04/2000 (invalid i.e 4 th month has 30 days)

30/02/2000( invalid i.e leap year)

29/02/2001(valid not leap year)

# Functional Testing On Mandatory Fields:

1) Enter any one mandatory field and check other mandatory fields
displays error message or not.

2) Enter any two mandatory fields and check other mandatory fields
displays error message or not.

3) Enter all mandatory fields and check user can create account or not.

4) Enter all mandatory fields and check user can create account or not.

5) Check all mandatory fields display error message or not if we click on

create account button.
 6) Enter mandatory and optional fields, check user can create account
or not.

#Types of Functional Testing:-

1) Over Testing:

Testing component with multiple inputs which are

covering same requirement.

2) Under Testing:

Testing component with multiple inputs which are not

covering requirement completely.

3) Optimized Testing:

Testing component with multiple inputs which

covers requirement completely.

Ex. Amount Transfer

To

Amount

Transfer

Cancel

Amount: It should be accept 50-50000.

It should accept decimal values within range.

Alpha, negative numbers, Special characters ,blank ,space

,operators ,Expression not allowed .

Valid inputs Invalid inputs

1)50 1)49

2)120.5 2)49.99

3)50000 3)-50

4)25000 4)***

5)51 5)fifty

6)200.54 6)leave blank

7)55.55 7) 12

8)15000 8)$50

9)0245 9)10+2

10)200 10)80000

#Integration Testing:-

Testing relation between two features or

testing data flow between two features based on relation.

Action: Check account holder transfer amount deducted from current

balance or not.

Steps:-1) Open app.

 2) Login to app.

3) Click on amount transfer.

4) Enter to amount and click on transfer button.

5) Click on current balance.

Expected Result:

Transfer amount should be deducted.

Action 2: Check account holder transaction update on transaction history

or

Not.

Steps: 1) Open app.

2) Login to app.

3) Click on amount transfer.

4) Amount transfer.

5) Click on my transactions.

Expected Result:

Transaction details should be updated.

Action 3: Check account holder transferred amount greater than current

balance amount is deducted from current balance.

Steps: 1) Open app.

2) Login to app.

3) Enter amount > current balance.

4) Click on amount transfer.

 5) Click on current balance.

Expected result: Amount should not deducted.

Action 4: Check account holder amount greater than current balance

transaction details updated in my transaction or not.

Steps: 1) Open app.

2) Login to app.

3) Enter amount > current balance.

4) Click on amount transfer.

5) Click on my transaction.

Expected result: Transaction should not updated.

Relation:

Relations are classified into two types .

1) Mono-directional:-

Relation between features will be in any one direction.

A---------->----------B

A----------->---------B

E.g: Compose---->------Inbox
2) Bidirectional:-

Relation between feature will be in both directions.

A --------<-->-------- B

E.x: Inbox -------<-->---------Trash

* Integration Testing with multiple users:-

Action : Check whether payer transfer money to payee and check it will be
transfer or not.

Steps:- 1) Open app.

2) Login as payer.

3) Click on amount transfer.

4) Select amount and click on transfer amount.

5) Log out payer.

6) Login payee.

7) Click on current balance.

8) Check whether balance either money will be credited or not.

Expected result: Payer transfer money to payee successfully credited.

Action: Check payer transferred amount transaction details are updated in

payee my transaction or not.
Precondition: Payer should transfer amount to payee.

Steps :- 1) Login as payee.

2) Click my transaction.

Expected Result : Payer transaction details should be updated.

Action:- Check whether payer transfer amount more than available balance
and should check amount credited in payee account or not.

Steps: 1) Open app.

2) Login payer account.

3) Click on amount transfer.

4) Transfer amount more than available balance.

5) Logout payer.

6) Login on amount details.

7) Logout page.

Expected Result:- Amount should not be credited in payee account.

Action: payer transfer amount greater than available balance and it check
whether payee transactions should updated or not.

Pre-condition:- Payer transfer amount to payee greater than available

balance.
Step: 1) Login payee.

2) Click on my transaction.

Expected Result: Payee transaction details should not be updated.

# Rules to perform integration testing

1) Priorities to features.

2) Understand requirement completely for priorities to feature.

3) Identify all possible relation.(valid & invalid)

4) Test each relation.

Types Of Integration Testing:-

Integration testing is classified into two types based on how testing team
will perform or check relations.

i) Non-incremental Integration Testing:-

Testing relation between

features by grouping which are having a set of relation.

It is also known as BIG BANG integration testing.

Limitations:-

i) Its complex and time consuming.

ii) Chances are their tester might miss one or

two relations testing which might have bugs.

iii) It can be perform affectively only if we are

experienced.
II) Incremental Integration Testing:-

Testing relation between two

feature by incrementally adding one by one feature.

Incremental Integration Testing is classified into two types based on data

flow between features.

1) Top Down Incremental Integration Testing:-

Testing data flow

between parent to child or high level to low level module.

Chances are their developers may create high level

module but not low level module to perform testing team might required low
level module so developers will create dummy module or feature stubs.

Stubs:-

It’s dummy feature which will receive data from high level module.

Limitations:-

1) Stub will not verify data is valid or invalid.

2) Stubs only receive data but not transfers.

2) Bottom Up Incremental Integration:-

Testing data flow from child

to parent or low level feature to high level feature.

To perform bottom up , Top down is mandatory and

relation between features should be bidirectional.

Chances are their developers may develop low level

feature but not high level feature to perform testing on low level feature. So
developer will create dummy feature Driver.

Drivers:-

Its dummy feature which will receive, analyse and transfer the
data.

Que : What is the difference between stubs and drivers?

Stubs Drivers

1) It’s dummy feature which will 1) It is dummy feature which will

receive data receive and transfer data.

2) Drivers are created when

2) Stubs are created when low high level feature is not
level feature are not available available

3) Drivers are mainly used in

3) Stubs are mainly used in top Bottom-Up approach.
down approach.
4) Stubs are created when 4) Drivers are created when
relation is mono-directional. relation is bidirectional.

5) Driver are calling functions.

5) Stubs are called functions.

6) Stubs are Subprograms. 6) Drivers are main Programs.

Defect:

1) Deviation between expected result and actual result.

2) Any application feature functionality not working as expected.

Que : Why defect will happen?

1) Because of mistake in program.

2) Because of logical mistake.

3) Chances are their developer misunderstood the requirement .

4) Chances are their developer miss any feature adding.

5) Chances are their tester misunderstood the requirement.

When tester identifies a bug prepares bug report and send it to

development team.

Bug report template

 Project name:
Feature name:
Build no:
Severity:
Priority:
Reproducibility:
Platform:
Bug id:
Bug status:
Bug summary:
Bug description:
Steps to reproduce:
Expected result:
Actual Result:
Attachments:

1) Project name: This section explains in which project testing team found
bug.

2) Feature name: This section explains in which feature bug happen.

3) Build no: This section explains by testing which build bug is identified.

4) Severity: This section explains how tester identified bug will show impact
on customer business.

a) Blocker: Further testing is possible.

b) Critical: High loss in customer business.

c) Major: No loss but customer will face some difficulties.

d) Minor: No loss no difficulties but application will not looks good.

e) Feature: Not a bug just a suggestion to make application more

affective.
 5) Priority: This section explains how fast tester identified bug need to
be fix by developer.

*Priority types*

a) Immediate/urgent: If bug need to be fix in same build.

b) High: Bug need to be fix next build.

c) Medium: Bug need to be fix within 5 to 10 builds.

d) Low: Bug need to be fix in any build even delivering product to customer.

#Note: Severity is set by Tester and Priority is set by Developers

sometimes tester can also set.

Severity Priority

Blocker Immediate

Critical High

Major Medium

Minor Low

# High severity with high priority:-

Identified bug will show saviour

impact on customer business and number or users uses application in bug
identified way are more.

*Bug: User unable to login app.

Severity: Critical/High

Priority: High

# High severity with low priority:-

Identified bug will show saviour

impact on customer business and number of users uses application in bug
identified way are very rare/less.

*Bug: user unable to login using help option.

Severity: High

Priority: Low

# Low severity with high Priority:-

Identified bug will not show any

impact on customer business but every user can easily understood that
mistake.

*Bug: Logo contains mistake.

Severity: Low

Priority: High

# Low severity with low priority:-

Identified bug will not show any impact

on customer business no of user can understand mistakes are less.
*Bug: In terms and condition 50 th line content mistake.

Severity: Low

Priority: Low

Reproducibility:

This section explains whether bug is consistent or

inconsistent.

a) Consistent Bug: If tester able to reproduce bug in all the attempts.

b) Inconsistent Bug: If tester unable to reproduce bug in multiple attempts.

# Status:

1) Alternate: Bug represent in alternate attempt.

2) Rarely: Bug reproduce twice or thrice in multiple

attempts.

3) Only once: Bug reproduce only once in multiple

attempts.

Que : Why we should send inconsistent bug to developing team?

Chances are there bug which is inconsistent at testing side might

become consistent at customer site. To have a proof document that testing
team identified bug we need to send it to developer.

Que: How developer will fix inconsistent bugs?

By referring to Log file.

# Log file:-

Its document which will record all the actions that are performed
on application automatically.
# Platform:-

This section explain in which O.S and browser testing team

found bug.

# Bug summary:

Overview of the bug.

# Bug Description:

In details about identified bug.

#Steps to reproduce:

Step by step procedure how tester identified bug.

#Expected Result:

How system should respond.

#Actual Result:

How system is responding.

# Attachment:

Bug related documents (log file, screen shots).

 Project name: ICICI Net banking App
Feature name: Current balance feature
Build no:05
Severity: Critical
Priority: High
Reproducibility: Always
Platform: O.S- Windows 10 , Browser-chrome
Bug id: _
Bug status: _
Bug summary: Transferred amount not deducted from current balance
Bug description: When payer T/F amount<available balance to payee
amount credited to payee A/C but not deducted from payer A/C.
Steps to reproduce: 1) Open App.
2) Login as payer.
3) Click on amount T/F.
4) T/F amount to payee.
5) Click on current balance.

Expected result: Amount should be deducted from current balance.

Actual Result: Amount not deducted from current balance.
Attachments: Images + Log files…………

Bug Report

Que: where we should prepare defect reports?

1) Word documents.

2) Excel.

3) Spread sheets.

4) Defect tracking tools (Mantis, Bugzilla)

5) Test management tools- Qc, JIRA…..

# Assign feature to testing team:-

a) Approach 1:

In this approach test lead will assign specific testing

to every team member which need to be perform on application
feature.

Limitations:-

1) Testing time might get increased.

2) Tester need to spend more effect.

3) Until functional Testing complete other testing can’t be

perform.

b) Approach 2:-

In this approach test lead will assign few features to

every tester and all types of testing tester need to perform on
assigned features.

Limitations:-

Chances are there feature which is a assign to one

tester might be related with other tester assigned feature that
relation might not be tested.
c) Approach 3:-

In this approach test lead will analyse requirement

and assign feature based on relation and independent features.

Every tester need to perform all types of testing on assigned

features.

Que: When tester should send a bug?

Immediately when tester identify the bug.

Que: Why tester can’t send all bug report at the end of the day?

1) Chances are their tester might miss forget one or two

bug logging.

2) Delay will happen in assign bug to developer.

3) Chances are their tester bug might become duplicate.

#Duplicate bug:

Same bug identified by multiple tester.

Que: Why duplicate bugs will happen?

1) Become of common feature navigation.

2) Might be relation between features.

Requirements:

1) Signup

2) Login

3) Compose

4) Inbox

5) Send mails

6) All mails

7) Forget password

8) Important

9) event

10) help

11) starred

12) chat

13) Privacy

14) contact

15) labels

16) change password

17) logout
 Test Lead

T
e
s
t
L
e
a
d

I F
n e
d R a
e e t
p l u
e a r
n t e
d e s
e d
n
t
F
e
a
t
u
r
e
s
h S C
e i o
l g m
p n p
u o
p s
e

A L I
b o n
o g b
u i o
t n x
u
s

C L A
o o l
n g l
t o m
a u a
c t i
t l
s

C F S
h o e
a r n
t g d
e m
t a
p i
a l
s s
s
 w
o
r
d

T C S
a h t
s a a
k n r
g r
e e
p d
a
s
s
w
o
r
d

f S L
a e a
c c b
u e
r l
i s
t
y

P i
r n
i d
v e
a p
e
 c n
y d
e
n
t

T T T
E E E
- - -
3 1 2

( ( (
F F F
T T T
/ / /
I I I
T T T
/ / /
S S S
y y y
. . .
T T T
) ) )

Que: For whom testing team should send bug report?

è Developing lead.

Que: Why we should not send bug report to test lead or developer?

1) We don’t know who develop that feature

2) If we send bug report to test lead delay will happen in assigning bug to
developer.

Defect Life Cycle:

1) When tester identifies a bug prepares bug report with status new/open
and send it to develop team.

2) Develop lead will review bug report identify developer who develop that
feature and assign bug report by changing status Assign.

3) Developer will review bug report reproduce a bug and modify source
code, change bug report status to Fixed.

a. When new build came for testing tester will rechecks bug
fixed or not if it is fixed change status to Closed, if bug is not
fixed to Reopen and send it to develop lead.
4) This process is continue until bug is fixed.

# Duplicate:

1) This status is given by develop lead

2) If the status is given developing lead not accepted

tester bug report because similar bug report already
assign to developer.

Que: Why duplicate bugs will happen?

1) Because of common features navigation.

2) Chances are their features are having relation which are assign to
testers.

New/open>Duplicate>Closed

#Postponed/Deffert:

This status is given by developer. Developer

accepted the bug but it will be fixed later or in next build.

Que: Why developer change bug report status to postponed?

1) Chances are their developer is busy in adding new features.

2) Might be bug severity is major or minor.

3) Bug priority might be low or medium.

 4) If the customer is expecting any changes in bug identified
feature.

New->Assigned->Postponed/Defferd->Fixed->Closed/Reopen

# Unable to reproduce:-

This status will be given by developer. If

developer unable to reproduce tested identified bug.

Que: Why developer will give unable to reproduce status?

1) Chances are their bug might be inconsistent.

2) Developer might use different platform to reproduce the bug.

3) If build is not installed properly in testing environment.

4) Might be bug report not clear to reproduce bug.

a) Inconsistent:

Open->Assigned->Unable to reproduce->

b) Build installation problem:

Open->Assigned->Unable to reproduce->closed

c) Bug report not clear/platform:

Open->assign->unable to reproduce->fixed->closed/reopen
# can’t be fixed:-

This status is given by developer. Developer accepted

tester identified bug but it will be not fixed.

Que: Why developer can’t fix tester identified bug?

1) Might be technology not to supporting to fix the bug.

2) Chances are their cost of fixing is more when compare to loss give to
loss give to that bug.

#Rejected:-

This status will given by developer when bug is not accepted.

Que: Why developer not accepted tester identified bug?

1) Chances are their tester is understand the requirement.

2) Chances are their developer misunderstood the requirement.

3) If bug is inconsistent.

4) If developer adds any new feature without updating the customer.

a) TE .Misunderstood-> New->assign->rejected->closed

b) DE .Misunderstood->
New->Assign->rejected->reopen->fixed->closed/reopen.

c) Inconsistent.

d) New feature.

# RFE:- (Request for enhancement)

 This status will be given by developer if it is a bug from tester point of
view but it can’t be accepted from developing point of view because bug
related content is not documented in requirement document.

All RFE’s will be discussed with the customer if customer agrees then
fix the bug otherwise reject.

(Customer approved) fixed->closed/reopen

New->assign->RFE->

( Customer not approved) Rejected ->closed

#Smoke Testing:

1) Developer will develop few features after WBT send build to testing
team.

2) Test lead will decide test cycle duration.

3) Testing lead will start testing each feature chances are their tester might
identify blocker bug at the end of the test cycle.

4) To fix that blocker bug and to retest and respin testing team might
require sufficient time which results in delay in next delay testing.

5) To avoid this before testing build testing lead to verify whether build
contains blocker bugs are not by performing smoke testing. If there is no
blocker bug then accept the build and perform through testing.

*Definition:

Testing basic and critical feature functionality before

accepting the build.
Que: Why we should perform Smoke testing?

1) To identify blocker bug at initial state.

2) To avoid delay in new build testing.

3) To avoid increasing project duration and cost.

4) To reduce tester efforts.

5) To insure build is testable or not.

6) It act as an entry criteria for developing team to develop new

build.

#Note:-

To perform Smoke testing we use only valid data. So it is also known

as Positive Testing.

Que: What type of testing will perform in Smoke?

Any type of testing which performed with valid data is considered as

smoke testing.

Que: When we should perform smoke testing?

1) Developer will perform smoke testing after every build installation is

testing environment.

2) Tester will do smoke testing on every build before accepting.

3) Customer will do smoke testing after installing product at production site

with sample/dummy data. i.e Dry Run Testing.
Adhoc Testing
Definition1: Testing application randomly without referring to any
requirement document.

E.g: Whatsup-> create group

Definition 2: Testing application by using creative scenarios.

E.g: Banking app.

Creative scenarios:-

1) Try to block account while user using/ transfer amount.

2) Try to block already blocked account.

3) Try to transfer amount to blocked account.

4) Try to block account who need repay loan.

Definition 3:- Testing an application without using any logic.

Que: Why we should perform adhoc testing?

1) Chances are their enduser might use application randomly and face
difficulty to avoid that we should perform adhoc testing.

2) Application quality will get increase.

3) To identifying more no of bugs.

4) To improve tester test efficiency.

5) To improve test coverage.

6) To break product.
Que: When we need to perform adhoc testing?

1) While testing a build if tester identifies creative scenarios stop normal

testing and perform adhoc testing.

2) If we identify more number of creative scenarios document and perform

adhoc testing at the end of test cycle.

3) If we identify more creative scenarios but time is not sufficient perform

adhoc testing at end of next test cycle.

4) In every build tester identified more creative scenarios but time is not
sufficient contact test lead so that new tester will be assign to perform
adhoc testing.

#Adhoc testing on G-mail:-

Synario 1) Login to Gmail copy URL and paste URL in other browser.

Synario 2) Login to Gmail with same account with multiple browsers,

change password in one browser and try to access application in other
browser.

Synario 3) Logout from Gmail application and click on browser back button.

Synario 4) While Login to Gmail same email id and password, Change

password and logout, try to login with same password.

Synario 5) Try to access application through browser History.

#Note: Basically adhoc testing is an unplanned testing activity where test

lead will not assign time to perform adhoc testing.

*Types of adhoc testing:-

1) Monkey testing:-
 In this type every tester need to identify creative
scenarios on their assigned feature and performs adhoc testing.

2) Interchange testing:

In this approach every tester will identify creative

scenarios another tester assigned features and performs adhoc testing.

3) Pair Testing: In this approach experienced tester will identify creative

scenarios and send it to tester by referring to those scenarios other tester
will perform adhoc testing on their assigned feature.

4) Buddy testing:-

In this approach developers will explain internal design

and coding structure to tester based on that knowledge creative scenarios
will be identified and adhoc testing will be perform.

· Difference between Defect, Bug, Error, Failure.

1) Defect: If tester identifies any feature functionality not working

as expected will be terms as defect.

2) Bug: If developer accepted tester identified defect it will be

considered as Bug.

3) Error: Mistake in program is known as error.

4) Failure: If application unable to support customer business it will

be consider as failure.

* Reliability Testing:
 Verifying or checking application features
functionality continuously for a period of time.

* Migration Testing:

Verifying or checking features functionality which

are developed in old technology or supportable in new technology or not.

*Recovery Testing:

1) Chances are their application might get crashed

at a customer site so we need to rebuild and check application works as
expected or not.

2) Chances are their tester might immediately crash the software and
checks rebuilded software works as expected or not.

* Test Cases *
1) Test a build testing team will use following approaches:

Approach 1:

In this approach by referring to requirement document

tester will identify inputs and test every build features.

Limitations:-

1) Consistency will not be their in testing.

2) Testing depends on tester interest.
3) Product quality might be affective.

Approach 2:

In this approach before testing the application tester will

identifies all possible inputs,document and by referring to that document
build will be tested. The document is known as test case.
Test Case:-

It's a document which contains all possible inputs that are used
to test application.

Que: Why we need to prepare test cases?

1) To have consistency in testing.

2) To improve product quality.
3) To improve test coverage.
4) To avoid training of new testers.
5) To avoid delay in build testing.
6) It act as proof document to customer that testing team had tested
application.
7) Its base document for Automation testing.
8) To depend on process rather person.

Test Cases can be documented in

a) Word document
b) Excel sheets
c) Spread sheets
d) Test management tool like QC, Test link, JIRA, Test Rail.

#Difference between test case and test scenario.

Test Scenario: Action that need to be perform.

Test Case: Step by step procedure to execute action.

Que: What type of cases to be document.

1) Functional Testing
2) Integration Testing
3) System Testing
4) Adhoc Testing
 Test Scenario Template

Project Name:

Module Name:

Feature Name:

Types of Test Scenario:

Request no.:

Severity:

Platform:

Brief Description:

Sr no Subfeature TestScenario_ID Test Scenario Status

Author:

Written Date:

Reviewed By:

Reviewed Date:

Approved By:
Procedure to fill test scenario document:-

Step 1: Identify Feature that need to documented.

Step 2: Understand the requirement completely for documentary

feature

Step 3: Identify all possible actions.

Step 4: Document identified action.

a) Fill header part first

b) Fill body
c) Fill footer part
 Functional Testing Scenario

Project name:
ICICI Net Banking
App

Module Name:
Bank Employee
Module

Feature Name:
Create Account
Feature

Type of Test Scenario: Functional Testing Test Scenario

Request No: 3.3.1,3.3.2,3.3.3,3.3.4,3.3.5,3.3.6,3.3.7

Severit
y:High

Platform:OS,Windows8,Browser-Firefox/Chrome

Brief Description:This document contain create account

feature functional test scenario.

Sr.no Sub Test Scenario Id Test Scenario Sta

Feature tus

1 Name TS_ICICI_BankEmployee_CreateAcc Check name field accept valid

ount_Name_FT_01 data or not

TS_ICICI_BankEmployee_CreateAcc Check name field accept invalid

ount_Name_FT_02 data or not

2 Accoun TS_ICICI_BankEmployee_CreateAcc Check AccountNo field accept

t no ount_AccountNo_FT_03 valid data or not

TS_ICICI_BankEmployee_CreateAcc Check AccountNo field accept

ount_AccountNo_FT_04 invalid data or not

3 Contact TS_ICICI_BankEmployee_CreateAcc Check ContactNo field accept

ount_ContactNo_FT_05 valid data or not

TS_ICICI_BankEmployee_CreateAcc Check ContactNo field accept

ount_ContactNo_FT_06 invalid data or not

4 UserId TS_ICICI_BankEmployee_CreateAcc Check UserId field accept valid

ount_UserId_FT_07 data or not

TS_ICICI_BankEmployee_CreateAcc Check UserId field accept invalid

ount_UserId_FT_08 data or not

5 Passw TS_ICICI_BankEmployee_CreateAcc Check Password field accept

ord ount_Password_FT_09 valid data or not
 TS_ICICI_BankEmployee_CreateAcc Check Password field accept
ount_Password_FT_10 invalid data or not

6 Create TS_ICICI_BankEmployee_CreateAcc Check Account create message

Button ount_Create_FT_11 display or not

TS_ICICI_BankEmployee_CreateAcc Check incorrect details message

ount_Create_FT_12 display or not

7 Cancel TS_ICICI_BankEmployee_CreateAcc Check acount cancelled

ount_Cancel_FT_13 message display or not

Auther: Shrikan
t Pawar

Written 20-01.2
date: 021

Reviev
ed By:

Reviev
ed
Date:

Approv
ed By:
 Integration Testing Test Scenario

Project
Name:-ICICI

Module Name:-Bank
Employee Module

Feature Name:-Create
Account Feature

Types Of Test Scenario:-Integration Testing Test Scenario

Request No:-3.3.1,3.3.2,3.3.3,3.3.4,3.3.5,3.3.6,3.3.7

Severity:-Hig
h

Platform:-OS,Windows10,Browser -Chrome

Brief Description:-In this document create account relation with

features is documented.

Sr.No Valid/Inv Test Scenario Id Test Scenario Stat

alid us

1 Valid Ts_ICICI_BankEmployee_CreateAcco Check Employee Created account login or not

unt_IT_01

2 Valid Ts_ICICI_BankEmployee_CreateAcco Check Employee Deposit amount in user acount

unt_IT_02 or not

3 Valid Ts_ICICI_BankEmployee_CreateAcco Check Employee block user account or not

unt_IT_03

4 Valid Ts_ICICI_BankEmployee_CreateAcco Check Employee Created account logout or not

unt_IT_04

5 Valid Ts_ICICI_BankEmployee_CreateAcco Check Employee credit amount or not

unt_IT_05

6 Valid Ts_ICICI_BankEmployee_CreateAcco Check Employee debit amount or not

unt_IT_06

7 Invalid Ts_ICICI_BankEmployee_CreateAcco Check Employee block account can be login or

unt_IT_07 not

8 Invalid Ts_ICICI_BankEmployee_CreateAcco Check Employee credit ammount in blocked

unt_IT_08 accout or not

9 Invalid Ts_ICICI_BankEmployee_CreateAcco Check whether employee blocks user account or

unt_IT_09 not who take loan

10 Invalid Ts_ICICI_BankEmployee_CreateAcco Check whether user can create new account who
unt_IT_10 already have account
Author: Shrikant
Pawar

Written Date: 20/01/20

21

Reviewed by:

Reviewed
Date:

Approved By:

Test Scenario review process :-

1) By referring to requirement document every tester will prepare test

scenario documents and send it to test lead for approve.
2) Test lead will assign test scenario documents to reviewer.
3) Reviewer by referring to requirement document review test scenario
identifies mistakes and prepares review document and send it to the
author.
4) By referring to the review document author will fix all the mistakes
and modify the test scenario document will be shared with the
reviewer.
5) Reviewer will recheck if all mistakes are fixed or not and send it a
letter for confirmation to test the lead.
6) Test lead will approve the test scenario document.

Sr Module Feature Type of Test scenario id Reviewer status Author Status

no document

1 Account Amount Functional Ts_ICICI_Accoun t’s wrong scenario If open-->clos Scenario removed Fixed
Holder Transfer Testing tHolder_AmtT/F_ we click on cancel ed
Cancel__FT_09 button with amount
less than/Greater
than avail.bal same
message will display

2 Account Amount Functional Ts_ICICI_Accoun Its wrong scenario.. open Scenario removed Fixed
Holder Transfer Testing tHolder_AmtT/F_ If we click on cancel -->closed
Cancel__FT_010 button, with
correct/Incorrect
payee details same
message will be
 display

3 Account Amount Integration Missing scenario open-->clos Scenario added Fixed

Holder Transfer Testing If we click on cancel ed TS_IT_09
button a)Amt TS_IT_10
shouldn’t deducted
from payer A/C
b)Details shouldn’t
display in payer
Mytran
c)Amt shouldn't
credit to payee A/C
d)Details shouldn’t
display in payee
Mytran

Que 1) What type of mistakes reviewers will identify?

1) Missing Scenario
2) Wrong Scenario
3) Modification Scenario

Que 2) How test lead will identify reviewer?

1) Chances are their features might be related

2) Based on domain knowledge
3) Based on testing experience

Que 3) What are review ethics?

1) Always review content but not author.

2) Always identificial mistake but not solution.
3) Even after review if any mistake is their both reviewer and author
responsible.

Test Case Template

Project Name:

Module Name:
Feature Name:

Types of Test Case:

Request no.:

Severity:

Priority:

Test_data:

Precondition:

Platform:

Brief Description:

Sr.n Subfeatur Test case Id Test step Input Expected result Actual Status
o e scenario Result

Author:

Written date:

Reviewed by:

Reviewed Date:

Approved By:

Approved Date:
 Boundary Value Analysis:-

If any component accepting range A to B to

test that component inputs are A-1,A,A+1 & B-1,B,B+1

E.g: Amount

Amount:

Req: It should accept within range 500 to 50000

Inputs: 499,500,501,49999,50000,50001

Username:

Req: a) It should contain UN within 8 to 12 char

b) Username must contain alpha

Inputs:

1) 7 char UN- abcdefg

2) 8 char UN- abcdefgh
3) 9 char UN-abcdefghi
4) 11 char UN-abcdefghijk
5) 12 char UN-abcdefghijkl
6) 13 char UN-abcdefghijklm

Equivalent Partition:-

1) Pressmen Technique:-

If any component accepts range test that

component for one valid and two invalids.
 a. Component accepts range

(One invalid I/P)--<A----valid input-----B<(One invalid I/P)

Eg: Account

Req: a) It should accept amount within range 500-50000

Inputs:-

1)30000

2)100

3)60000

B) Component accept set of values.

If component accepts set of values test that component for one valid and
invalids.

a) One valid
b) Two invalids

Ex: Enter product Id :

Price:

Sr no product Id
1 idli 10
 2 puri 20
3 dosa 30
4 Masala dosa 40

Inputs:

1) 10
2) 15
3) 20.1

C) If a component works on boolean condition test that component for both

true and false.

# Practice Technique:

a) If a component accepts range then test that component for multiple

valids and two invalids.
b) Multiple valid inputs identified by dividing range into small parts each
part is known as equivalent class.

Ex.amount

a) It should accept 500-50000

Inputs: 1)500 2)2123 3)12000 4)21000 5)25000 6) 29121

7)38000 8)42000 9)50000

c)If a component accepts a set of values test that component for multiple
valid and two invalids.

d)If a component accepts boolean condition then test multiple components

for both true and false.