Types of Project:

1. Traditional– Developing & Testing done under one roof – means in same company
2. Off The shelf- Developing & Testing team are from different company
3. Maintenance- Under The maintenance technical & non-Technical maintains will
come
Technical means – KPO
Non-Technical Means – BPO

Error, Defect, Bug, Issue

Error – A mistake in coding or program known as Error

Defect – If error found by Tester known as Defect

BUG –If Defect valid & is accepted by developers known as BUG

Issue –If Application does not meet functional requirement is known as issue

Means Defect is there – in open state – developers not able to fix it known as

issue

Types of Testing in Development Environment-

 In Dev. environment, developer will work

 Developer will done coding then they perform the Unit testing & Integration testing
1. Unit Testing-

 Unit Testing will perform by develop on every User Story

 Unit testing will perform with +ve Testing
 Unit Testing documents will +ve contains flow of application

2. Integration Testing-

After completion of Unit Testing – Integration Testing comes in picture

In integration Testing WBT is involved – They integrate all dependent modules
together to form a one application/Product

Integration testing is performed by developer

Integration testing to combine all sub-modules& perform the testing on main
module
Developer should have all knowledge about FN, relation, dependency module on
other module
Output of one module is act as input to other

Integration Testing is the process to check completeness & correctness of the flow of
functionality whenever integration of module performed

Integration testing has Two Types

Frond end Integration - Call all modules, sub-module- Using Call Function
Back end Integration –Database - Tables –Using Combine Join Statement

Integration Testing has 3 approaches-

1. Top down approaches

2. Bottom up approaches

3. Bi-directional approaches
 1. Top down approaches

 Top –down approaches will perform, when sub-module is not available for integration
testing
 In this approach – main module with function is available but to test main module sub
module is not available
Because sometimes it under -
Development
Developed by some other other company
Having defects
I.e. physical not available to test main module functions

So to test main module -

 Developer will prepare the Temporary program in XML language is known as

Stub
 Dummy code
 Stub is nothing it is Html/XML program
 XML : Its coding language used to communicate between two application
 Request & response is in XML language

Email Sign In page Home Page

STUB < Email >
EMAIL ID

PSW < PSD>

LOGIN
XML

Is not available/ Temporary

development / under development
 2. Bottom up approaches-

Bottom up approaches will perform, when don’t have Main or starting-module is not

available for integration testing or to test sub modules

Developer will prepare the Temporary program/ Driver – Driver

Driver is nothing it is Html/XML program

 In this approach –SUB module with function is available but to test main module is
not available

Because sometimes it under -

Development
Developed by some other other company
Having defects
I.e. physical not available to test main module functions

Email Sign In Home Page-

Driver Inbox |Sent Item |Trash

Is not available/ Temporary

development/ under development-
3. Bi-directional approaches-
Driver
3. Bidirectional Approach

Bi-directional approaches when we don’t have Main module & Sub-module

For Main module- driver & Sub-module-Stub, interaction testing
It’s a combination of Top down & bottom Up approach

Functionality of main module – Stub

When developers want to check functionality of main module but don’t have sub module then
they uses STUB program

Functionality of Sub module – Driver

When developers want to check functionality of Sub module but don’t have main module
then they uses STUB program

Main Module Stub or Driver Sub Module

Types of Testing in SIT-

 Tester will perform the testing in SIT environment

 After we will get build from developer then we start the Testing
 SIT environment having different types testing

1. Sanity Testing

After the completion of Integration testing – Sanity Testing initiated

Also known as –

Zero Level Testing

Build verification level Testing

Sanity testing is called level zero testing cause 1st testing in SIT environment start with sanity

Sanity Testing also called Build verification testing

Sanity testing – After getting build form developer then we perform then sanity testing

Stability of Build – Once we get initial build from Development Team – we check whether
build is ready or not for testing

I.e. Testing the stability of build

People Involved – DBA Team (for testing build) & QA

Agenda –Check Basic & core functionality of Application & application working flow

Database Analyst Team create the test Environment - Testing Environment

In that Environment DBS team insert the code

 Development/Code

DBA

Build

Test Environment Creation

DBA

Update

Build Run

Developers > Develops code > DBA team create Test Environment > Testing starts > Update
the code by Developers > DBA Team > Deploy the new code > Build> Cycle repeats

In sanity we are Validates basic & core functionality of application whether it works properly
or not

In Sanity testing we are checking

1. GUI/ UI Validating the – Loading , Page format,

2. Basic &core functionality validation – Happy flow - E.g. IRCTC
3. Link Validation (Ex. 172.20.10.30.8080/paytm/recharge) – linking connectivity
4. Tab Validation – Text Box
5. Page Validation - One page to other

1. Basic & core functionality validation – Functionality flow | Critical defects |

Defects affects Functionality

2. Tab Validation – Text box – where we enter input |

Characters | Number Special character

3. Page Validation - One page to other navigation

Number of pages – Previous – Next

4. Link Validation: Interlinking of pages tested

5. GUI Validation : Display of Application

Images or Logo
Alignments
Visualization Testing – GUI Testing

In Sanity Testing tester are not writing the test cases.

In Sanity Testing if we found defects– Buggy Build - Tester will reject the build

 Ex. IRCTC (V9.0- New Build) When developer will developed the new build 
Sent to tester for testing  Sanity testing (stability of build)
Check for basic & core functionality  defectsRejecting the build (V9.0)
Developer will change code/or modify – prepared a new build (V9.1 New build) 
Sanity testing (stability of build) 
If build is stableRemaining in SIT i.e. system & functionality
 Whenever we got new build then only, we perform Sanity testing
 Duration : 2 to 4 hr. for Sanity testing

 Defect which found in Sanity Testing due to

1. System hangs out problem
2. Run time problem/Time Out error
3. Pop or link is not working
4. Environment problem (due to deployment process, System configuration,
Libraries)
Show Stopper Defect/ Blocker

While testing if any defect occurs while testing at any Fn& if the defect is critical we lock that
defect as blocker or know as blocker

When Blocker occurs > we lock that defect > Defect Tool > assigned to developer > High
priority

He will work on It > provide fix on new build > fixed

If we found a defect in sanity we will Mail (JIRA/HPALM) to developer

How Sanity Performed?

E.g. Flip Cart – Mobile

Sanity Successful or partial successful – Once Sanity testing done Tester put comments

Sanity is performed once build – Received – Ready for Testing – Stable –

Once on Friday or Monday

Not every day

Build come with – Build number & other details for identification

Tester will update sanity Testing report in Team along with TL – Mail - so we can move
build for testing

Scenario Date Status Defect ID Comments

 2. Smoke Testing
Smoke Testing = It anadvanced Version of Sanity

It is also known as extra sake of sanity Testing

During Smoke – Team founds if Defect > Team tries to trouble shoot the problem.

I.e. Finding Root cause of defects

Smoke = Sanity + Troubleshoot

= Sanity + Package validation

= Back End Developers are involved for Package validation

Package Validation = Package means collection of object

All The interdependent objects are grouped together known as Package

Back end developers involved in this &Validates package for exact root cause detection

Sanity Testing Smoke Testing

New Build from developer If we found defects in new build

Validation- Core, GUI/UI, Page, Navigation, Validation- Troubleshooting, Package
Validation
Perform by Tester Perform by Tester + developer
No TC No TC
If we found defects in sanity testing If we found defects in smoke testing
Rejecting build Troubleshooting
Interview Question-

1. Which testing will follow when you got new build?

 Answer- In my organization, we are performing Sanity Testing
 When we got new build form developer then we perform then Sanity testing

 In Sanity testing we are checking

1. Validating the GUI/ UI of application
2. Validating core functionality (ex. Recharge module- Mobile no. recharge)
3. Validating the link (Ex. 172.20.10.30.8080/paytm/recharge)
4. Validating the tab/pages
5. Validating the navigation

2. What is difference between Sanity & Smoke Testing?

3. What is Stub
4. What is Driver
5. Stability of Build means what
6. How you get the build & when?
7. Where you tested your application?
8. What is the diff between V module & agile Module
9. Advantages of Agile M
10. Modules of Agile
11. What is sprint? & duration?
12. Explain water fall module? Have you worked on IT?
13. Integration Testing
14. Are you being the part of integration testing?
15. Explain DRE & PM Testing
16. Explain V module?
17. Difference Between verification & Validation
18. QA Vs QC
19. Sprint wise delivery
20. Release plan of your project
21. Did you worked in Agile M
22. Duration of agile
23. Agile Meetings
24. Tell me about Scrum Meeting |Sprint planning meeting
25. How you receive user stories

26. Have you performed sanity testing?

27. How you get the Build for Testing?

28. What is Estimation & How you are giving the estimation in project?
Q. If development is not done at last day of sprint? What are approaches?
OR Last day of sprint but still development is pending or Testing is pending?
 Answer- If developer build last moments + Tester try to TCE
 But, Saturday + Sunday working (Developer + Tester + PM)

System & Functional Testing

DIT – Integration Testing

SIT – Sanity Testing

Then System & functional Testing comes in picture

Also known as Black box Testing

Tester involved in this – BBT validates overall functionality of application – Completeness &
correctness application as per the customer’s requirements

Validates start to end internal functionality of application as per external functionality

As per the user stories – Test execution started – nothing but system & functional Testing

S & F Testing Includes

1. Functional Testing
2. Usability Testing 95%
3. Security Testing
4. Performance Testing 5%

Functional Testing -

In functional Testing we are completeness & correctness of application – functional point of

view

Checking internal functionality based on External functionality or interface

 Functional Testing Includes

Functional Testing Nonfunctional Testing

Usability Testing

In usability Testing we checks - User friendliness of application

How it looks

How easy it can be used by real end customers

Observe & encounter defects if any

Checks- fonts| colors| resolution | visually

Security Testing

Security Means – Privacy

Checks – users operation & information is secured | protected or not

E.g. Either OTP or Password

Performance Testing

Speed – to ensure performance of application

How is able to handle load

How it works under workload & without workload condition

Functional Testing

Functional Testing
Nonfunctional Testing

Functional Testing [BIEBSC]

It is the part of BBT in which Tester validates completeness & correctness of

application as per the customer’s requirement

In functional Testing – Tester checks internal features & functionality of product

application

1. Behavioural coverage testing

2. Input domain coverage testing
3. Error handling coverage testing
4. Backend coverage testing/ Database Testing
5. Service level coverage testing
6. Calculation based coverage testing

1. Behavioural coverage testing-

Tester Validates= Property of the object

Tester Validates = behaviour of the object

Validating objects behavioural&objects Property

Objects Property of the object

Text box Enabled or disabled/ Focus or unfocused

Check box Check or Uncheck
Radio Button On or Off
Select box/ Drop box Drop Down Value - Select or Not
Buttons Enabled or Disabled
 Link Click or Unclick

2. Input domain coverage testing-

Here Tester Validates input values which we are passing into the objects/ web elements

Checking Size (length) & Type of the object (Data Type)

Type Means – Data Type – Integer, Char

Size Means – Length

While testing Input domain converges having fallowing approaches

BVA (boundary value analysis)- Checks- Size/ length of input values

ECP (Equivalent class partitioned) - Checks - Data types of input values

Decision table testing techniques – different input combination

Checking Valid & invalid scenarios

Tester only Involved

 Ex. Login Page –

Username–Text Box - Should Accepts only mobile no

Password- Should accept combination of 4 to 6 char, (1 capital, 1 small, 1 no. & 1
special no)

Username-

Password-

Submit
ObjectsUsername _Text Box

 ECP- Data type –

0 to 9 (Integer only) --Pass One Two three nine (Char.)- Fail

 BVA- Size/length-
10 digits enter -- Pass 9 digits enter – Fail

ObjectsPassword

 ECP- Data type of input values –

Integer, Char. --Pass Only one Integer/ Char – Fail

 BVA- Size/length of input values-

Min- 4 digits enter -- Pass 7 digits enter – Fail

5 digits enter -- Pass 3 digits enter – Fail
Max- 6 digits enter -- Pass

Object- Submit button

Decision table testing techniques-

Object Rule 1 Rule2 Rule3 Rule4

Username valid valid In-valid Blank
Password valid In-valid valid Blank
Submit Click Click Click Click
Result Next page Error message Error message Error message

E.g. Textbox should accept only 4 to 6 characters (take text box from above )

BVA ECP

Size Result Valid Invalid

Min = 4 Pass 0-9 space
Max =6 Pass a-z _
Min+1 = 5 Pass A-Z
Min -1 = 3 Fail SP.char
Max+1 =7 Fail
Max-1 = 5 Pass

Textbox should accept only 4 to 6 characters - ? HW

BVA ECP

Size Result Valid Invalid

Min = 4 Pass a-z 0-9
Max =6 Pass A-Z space
Min+1 = 5 Pass symbol
Min -1 = 3 Fail -_
Max+1 =7 Fail Sp char
Max-1 = 5 Pass

Mobile Number should accept 10 digits

BVA ECD

Size = 10 Result Valid Invalid

Min = 10 Pass 0-9 a- z
Max = 10 Pass A-Z
Min+1 = 11 Fail Sp Char
Min -1 = 9 Fail Symbol
Max+1 = 11 Fail space
Max-1 = 9 Fail -_
Password – Text Box – Should allowed

8 to 14 digits | 1CAP char | 1 Small Char | Special Symbol |No space and _|

BVA ECD

Size Result Valid Invalid

Min = 8 Pass A-Z Space
Max =14 Pass a- z -_
Min+1 = 9 Pass Special Char
Min -1 = 7 Fail 0-9
Max+1 =15 Fail Symbol
Max-1 = 13 Pass

Check BVA & ECP for cycle stand having 100 cycles

BVA ECD

Size Result Valid Invalid

Min = Pass A-Z 0-9
Max = Pass a- z Special Char
Min+1 = Pass Symbol
Min -1 = Fail Space
Max+1 = Fail
Max-1 = Pass
3. Error handling coverage testing-

It validates – if any error occurs – weather it displays proper error message or not

 Validation the error message, when we pass in-valid test data/ blank data in objects
 Validation/ Check different error messages present against the object
 Ex. Paytm- Recharge module – Mobile, Circle, operator, Amount invalid or Blank