Software Testing

 What is Software?
 Software is a series of instructions for the computer that perform a particular task, called a program.
 Or simply we can say Software is a collection of specialized programs.
 E.g. Excel,Word,Amazon, What's App, Banking Application,CRM etc.

 What is Software Testing?

 Software Testing is a method to check whether the actual software product matches expected
requirements and to ensure that software product is Defect free.

 Software Testing is a process of executing the application with the intent of finding the
defects by comparing the output behavior of the application with expected behavior
(requirement).
 In other words it’s comparing the actual behavior of an application with expected behavior.
 There are two approaches to test the application.

1. Manual Testing
2. Automation Testing

 Why is Software Testing is important?

Humans make mistakes all the time!!

 We humans can’t identify our mistakes in a work done by us. We should get someone else to check
our work because another person may identify the mistakes done by us.
 In the same way software developers may not identify the mismatches in a program or application
implemented by them which can be identify by the another department called Software Test
Engineer.

 Why is Software Testing is important?

 Testing is important because software bugs could be expensive or even dangerous.

 Software bugs can potentially cause monetary(economic loss) and human loss, and history is
full of such examples.
 In April 2015, Bloomberg terminal in London crashed due to software glitch affected more
than 300,000 traders on financial markets. It forced the government to postpone a 3bn pound
debt sale.
  Nissan cars recalled over 1 million cars from the market due to software failure in the airbag
sensory detectors. There has been reported two accident due to this software failure.

 Starbucks was forced to close about 60 percent of stores in the U.S and Canada due to
software failure in its POS system. At one point, the store served coffee for free as they were
unable to process the transaction.

 What are the benefits of Software Testing?

 Software testing helps in finalizing the software application against business requirements.

 Software testing makes sure that the testing is being done properly and hence the system is ready for
the customers to use.

 Below are few benefits of software testing.

 To Prevent defects
 Finding the defects before delivery
 Gaines the confidence about quality
 Ensure the requirements are delivered to client

 What is Software Quality?

 Software quality is nothing but delivering a bug free application and delivered on time with all
requirements.

 Software should:

 Meet Customer requirements

 Cost to Purchase (Economical)

 Time to Release (Timely Release of it)

 SQA: The Monitoring & Measuring the strength of development process is called SQA (Software
Quality Assurance).
 Check the quality OR to measure & monitor the process of development & testing
 BA Client

Developer Tester

 SQC: The Validation of final product before release to the customer is called SQC (Software Quality
Control).

 What is Project Vs Product?

 Project is developed for a single customer on his own requirements by the software companies
and the project will be used by the customer only.

 Product is developed for multiple customers on their consolidated requirements by the software
companies and the product will be used by all customers.

 What is Error?
 Mistake in the program is called error.

 What is Defect?

 When tester found mistake(error) called as defect

 A defect is a deviation or mismatch from the requirements.

 When actual result deviates from the expected result while testing a software application or product
then it results into a defect.

 What is bug?

 When developer accept that it is a actual defect then it is called bug.

 What is issue?

 When developer found difficulty to solve bug called as issue.

 Resources inovolve in software development

Customer

BA (gather requirement)

Developer (develop application as per requirement)

Tester (Check correctness and completeness of functionality)

Final product to customer as per requirement

 Software Development Life Cycle (SDLC)

 Software Development Life Cycle is a systematic approach to develop software. It is a Process

followed by Software Developers and Software Testing is an integral part(Entire) of Software
Development, so it is also important for Software Testers.

 Software Development Life Cycle (SDLC) is a process used by the software industry to design,
develop and test software. The SDLC aims to produce a high-quality software that meets or exceeds
customer expectations, reaches completion within times and cost estimates.

 Why Software Development Life Cycle?

SDLC ensure success in process of software development.

 Phases of Software Development Life Cycle

1. Initial/(Requirement Gathering)

2. Requirement Analysis- SRS

3. Design

4. Coding

5. Testing
 6. Delivery & Maintenance

1.Initial/Requirements Gathering :-

 Business Analyst is responsible for gathering requirement from customer.

 Requirement gathering involve business requirment specification (BRS)
 BRS is a bridge between client and developer ,tester.

2.Requirement Analysis :-

 Business Analyst involve in this process.

 In this phase SRS (Software requirement Specification) is made
 SRS document made after BRS
 SRS is a detailed documentation

BRS SRS

Sign up page Sign up page should have name,email,number

etc.
Home page It is a functional requirement specification
Access info By using BRS SRS document get generate
Contact number
Link

 SRS documentation includes

Functional flow diagram (it means task flow,proper sequence of task like sign up—log in—)

Functional Requirement(It means which attributes are required to complete the specification)

Use case

Snap shot

1... Initial(Requirement Gathering):

 Requirement Gathering is the most important phase in software development life cycle, Business
Analyst collects the requirements from the Customer/Client as per the clients business needs and
documents the requirements in the Business Requirement Specification and provides the same to
Development Team.

 Note: Document name may vary from one Organization to another, Some examples are Customer
Requirement Specification (CRS), Business Requirement Document (BRD) etc
  Suppose Our Planned Software is not intended for a single customer and the software product for
multiple customers then Business Analyst or Business Team collects Requirements from the Market
and also evaluate Other similar products in the Market

 Key Role in this phase is Business Analyst and Outcome of the phase is "Business Requirement
Specification"

2. Analysis
 Once the Requirement Gathering is done the next step is to define and document the product
requirements and get them approved by the customer. This is done through SRS (Software
Requirement Specification) document. SRS consists of all the product requirements to be designed
and developed during the project life cycle.

 Key people involved in this phase are Project Manager, Business Analyst and Senior members of the
Team. The outcome of this phase is Software Requirement Specification.

3. Design
 In Design phase Senior Developers and Architects, they give the architecture of the software product
to be developed. It has two steps one is HLD (High Level Design) or Global Design and another is
LLD (Low Level Design) or Detailed Design,

 High Level Design (HLD) is the overall system design, covers the system architecture and database
design. It describes the relation between various modules and functions of the system.

 Low Level Design (LLD) is the detailed system design, covers how each and every feature in the
product should work and how every component should work.

 The outcome of this phase is High Level Document and Low Level Document which works as an
input to the next phase Coding.

4. Coding
 Developers (seniors, juniors and fresher) involved in this phase, this is the phase where we start
building the actual software and start writing the code for the product.

 The outcome of this phase is Source Code Document and the developed product.

5. Testing
 Once the software is complete then it is deployed in the testing environment. The testing team starts
testing (either test the software manually or using automated test tools depends on process defined in
STLC)

 Testing is done to verify that the entire application works according to the customer requirement.
  During this phase, Testing team may find defects which they communicate to developers, the
development team fixes the defect and send back to Testing for a re-test. This process continues until
the software is Stable, and working according to the business needs of that system.

6..Delivery & Maintenance:

 After successful testing, the product is delivered (deployed to the customer for their use),
Deployment is done by the Deployment/Implementation engineers and Once when the
customers start using the developed system then the actual problems will come up and needs
to be solved from time to time.
 Fixing the issues found by the customer comes in the maintenance phase. 100% testing is not
possible – because, the way testers test the product is different from the way customers use the
product. Maintenance should be done as per SLA (Service Level Agreement)

Software Organization Hierarchy Structure

AM

DM
SPM

PM(Dev) PM(Testing)
PL PL
TL TL TL TL
Develpo Devolo TE’s TE’s
ers pers
Fish Model
It defines SDLC, I mean it defines what is SDLC?

• BRS -Business Requirements Specification

• SRS -Software Requirements Specification
• HLD -High-Level Design
• LLD - Low-Level Design
• Coding ----- White Box Testing
• Testing ----- Black Box Testing
• Maintainance ----Testing Software changes

 BRS -Business Requirements Specification

 The BRS defines the requirements of customer to be developed.
 This Doc developed by BA people
 It acts as bridge between customer and technical people.
Eg.
 Dual Sim-- 2 sims in single device.
 ATM Machine – user should withdraw money.
 Project related eg.
 Text box should not accepts blank value while filing a form.

Customer BRS Developer and testing team

 SRS -Software Requirements Specification

 This doc defines with respect to BRS.

 The SRS defines the functional requirements to be developed and the system requirements to be
used.
 1 BRS consists multiple srs’s.
Eg.
 BRS---ATM Machine – user should withdraw money.
 SRS– Magnatic tapes,ATM card, Pin code

Q. Do u aware about SRS?—Interview

 Yes,It is detailed documentation ,after BRS SRS is generated.

 In SRS all the functional requirement involved

Q. Where did u get SRS doc from?

From BA and upload it into sharepoint

Q. What SRS consists?

1.Functinal Requirement
2. Use case
3 Snapshot
4. Fun flow diagram

Q. Where do u get snapshot?---snipping tool

Q. Which tool is for taking snapshots?

 Design :----
 Pictorial representation of the project/Software to be developed.

HLD: -

The HLD documents defined the overall architecture of the system.

The below overall design is also known as Architectural Design / External Design
 LLD: - the LLD documents define the internal structure of every module or Functionality.
 Reviews:-

• A document level testing technique during this review, the responsible

people are estimating the completeness & correctness of corresponding
Document

There are different kind reviews for validate above BRS SRS and Design documents.

1. Walkthrough
In this review system, responsible people Study a document from 1st line to last line

2. Inspection:-

Search for a specific issue in a document (Without Intimation).

3. Peer Review :-

Compare a document with other similar document

4. Informal Review:-

It doesn't follow any process to find out any defects in document. In this review, they just review and
give informal comments.

5. Technical Review:-

Functional specifications will be reviewed and checked whether it is suitable to product.

Reviews in BRS/SRS

1. Are they Right Requirements?

2. Are they Complete Requirements?

3. Are they Achievable Requirements?

4. Are they Reasonable Requirements?

5. Are they Testable Requirements?

Reviews in Design
After completion of Analysis & their reviews the designer category

people develops HLD & LLD’s are conducts reviews on the documents for completeness & correctness.

The designers prepare these questions on the HLD & LLD’s.

1. Are they understandable designs?

2. Are they meeting the right requirements?

 3. Are they complete designs?

4. Are they followable designs?

5. Are they handling errors?

Coding:-
After completion of design & their reviews, the programmers start coding.

Coding is set of software program written by development team to construct a physical software.

 What is Program

Program: - A set of executable statements is called a program. Software consists of multiple programs. A
program consists multiple statements.

 In this phase, the programmers prepare programs & then test each program using

 White Box Testing Techniques.

White Box Testing

It is coding level testing technique used to check completeness and correctness of program.

• A program level testing technique. In this technique, the responsible people are verifying the internal
structure of the corresponding program. i.e developers

• White Box Testing techniques are also known as Unit Tesing/Open Box Testing / Glass Box
Testing / Clear Box Testing

Q. Did you involved in WBT/Unit Testing?

No, Amit. I didn’t got chance to work in WBT/Unit Testing.

White Box Testing

There are 4 White Box Testing Techniques:

1.Basis Path Testing

2.Control Structure testing

3.Program technique Testing

4.Mutation Testing

These Techniques are applicable only for Programs.

1.Basis Path Testing:

 During this test the programmers concentrate on the execution of

programs without any runtime errors. To conduct this test, the corresponding
programmer follows the below approach.
 Write a program with respect to LLD (Low Level Design)
 Draw a flow graph for that program.
 Run that program more than one time to cover all areas.

Eg If Else program….This program should be run 2 times executable.

° One time to check whether if condition is satisfied or not

° Next time to check whether the else condition is satisfied or not, without any runtime errors.

2. Control Structure Testing:

 During this test, the corresponding programmer concentrates on correctness of program execution in
this test, they verify every statements of program execution.
 In this test, they verify every statements input state & Output state.

Eg: Debugging

3. Program Technique Testing:

During this test, the programmers concentrate on the execution

speed of a program. If the execution speed is not reasonable, then programmers

perform changes in the structure of the program without disturbing functionality

of the program.

4. Mutation Testing:
During this test, the corresponding programmers estimate completeness & correctness of a program testing.
Total req, successful and failed req

 Testing:--
Testing is done to verify that the entire application works according to the customer
requirement.
  Black Box Testing
 This is build level testing technique.
 During this testing, test engineer validates the internal function with respective to external interface.
 Also known as ‘System and Functional testing’.
 Tester doesn’t need to know about internal code written by developer.
 Functional Testing and Non functional testing

Q. Where do you involved?

Ans.:- I involved in functionality testing

Functional Testing

1. Behavioral Coverage

2. Input domain Coverage(BVA And ECP)

3. Error handling Coverage

4. System level Coverage

5. Calculation Based Coverage

6. Backend coverage / Database Testing

1…Behavioral Coverage

Changes in Properties of Objects in Screen.

Objects Properties
• Textbox/ Textfield Focused/Unfocused
• Radio Button on/off
• Button Enable/ disable
• Check box checked/unchecked
• Dropdown list box select/deselect multiple items/choices
• Dropdown combo-box select/deselect single item/choice

2…Input Domain:-

Taking correct size & type of Inputs (applicable textbox only)

Size of data type Type of data type

3…Error Handling Coverage:-

 Error handling coverage means the weather system show error message or not .
  Preventing incorrect operations.

4…Backend Coverage:--

 In this ,the impact on backend tables due to front end screen.

 In backend coverage developer check the weather the external information by users get stored in
database or not

5…Service level coverage (Order of functionalities):---

 In the functional flow diagram BA creates sequence of function and module

 This aspect of sequenciality of functional modules get tested in service level coverage.
 They check the working of system as per functional flow diagram
 Eg—Signup—Login---Homepage like this means the correct sequence

6…Calculation base coverage :--

 Calculation base coverage check arithmetic operations

 Eg.Flipcard in this when we place the order firstly add in cart then suppose we add
other item also then total amount like this.
 Validation with respect to arithmetic calculation.
 Eg.-------Price=200
Quantity=5
Total=1000
Non Functional:---
Process of checking external functionality.

 Recovery Testing/Reliable Testing

 Compatibility Testing/Portability Testing
 Configuration Testing/Hardware Compatibility Testing
 Inter system Testing
 Installation Testing
 Sanitation /Garbage Testing
 Globalization Testing
 Parallel Testing

1..Recovery Testing:--
 Recovery testing also called as reliable testing
 During this testing we have to validate weather as application recover from abnormal situation to
normal situation .
 Eg:- Transaction (ATM)
 Abnormal situation:-

1. System Crash

2. Server Down
Eg 2 :-- Google ,suppose our we trying to connect with google without using
internet data that time we have error message after that we on the data and then
google search automatically in normal form what we want.

Q :- do you have involved in recovery testing ?

 ➔ Yes I have involved in recovery testing recently A & application B share the same database.
 Requirement is two application share common database --

• To test this application condition are :

 1.req of application A should be successfully executed .
 2. req of application A is under process & req of application B come then it has to wait for 2 min .
 3.If req of application A testing taking more than two min time then req of application A should
be terminated.
 4. req of application B should be successfully executed .
 5. Requirement of application B is under process and requirement of application A come then it as
to wait for 2 minute.
 6. Requirement of application B testing more than 2 minutes time then requirement of application
B should be terminated.
  7. Requirement of application A= requirement of application B come exactly on same time then by
FIFO requirement of application A process first.
 8. Requirement of application A & requirement of application B come on some time then
requirement of B processed this waiting for 2 minutes is considered as recovery.

2..Compatibility Testing/Portability testing:

 Compatibility testing also called as Portability testing.

 During this testing , test engineers validates that whether an application works on different
platform or not.
 There are two type of compatibility testing :
 1) Forward compatibility : when build /application is ok and problem with OS or browser is
called ‘’Forward compatibility’’.
 2) Backward compatibility:
 ---OS or browser is ok but problem with application or build is called as ‘’backward
compatibility’’.
 ---In generated test engineer find maximum defects in backward capability.

Q….: Do you involved in compatibility testing ?

 → Basically I was involved in Backward Compatibility Testing.

 Browser Compatibility Testing is divided in two types.
 1) Cross browsing: we are going to validate the application on different browsers as per
requirement.
Eg :- Edge vs Mozilla , Edge vs chrome , on intrenet explore,firefox.
 2) Version Comparison: we are going to validates the application on different version of same
browser/Os .
Eg: Chrome 96 vs Chrome 98

Q. Which compatibility testing you involved?

Ans.:- In browser compatibility testing.

Basically browser compatibility testing is again divided into two parts:

a. Cross Browsing: IE Vs Chrome
b. Version Comparison: I7 Vs I8

Q. Suppose you want to test your application on different version of browser or single machine. How
you do version compatibility testing?
Ans.:- VMware (Virtual Machine)

Q. Difference between Oracle 9I, 10E, 12C.

Ans.:- Oracle 9I ,Oracle 10E, Oracl12C
I-Internet ,E-End ,C-Cloud
Q. What are things you covered in browser compatibility testing?
Ans.:- This testing used for front end validation.

In this backend is absolutely zero we don’t touch backend

1. Functionality validation in terms of GUI
2. Hyperlink accessibility
3. Page navigation
4. Tab validation

Q. What types of defect during browser compatibility?

Ans.:- In general we get environmental related defects and GUI related defects as maximum.
Examples of environment related defects –
• 404 not found
• Run time errors
• DLL file missing

Q.. If HR ask about your company id and extension?

Ans.:- How does this question is related to my
interview?

3…Configuration Testing:----

 It is the process of checking weather our application are support or not on different different
hardware.
 It is the hardware compatibility testing.

4…Inter System testing:----

 It the process of checking weather the our application are able to share the resources to other
application.
 In this testing communication happens one to other applications
 Generally banking domain companies use this.
 Eg.Suppose we have to make payment for jio number from phonepay then phonepay fetch info from
jio app,this data get sharing checked in their system testing.

5..Installation System:---
  It is the process of checking the installation of our build with other existing software into user
expected platform.
 When user install app then it should create shortcut on desktop.
 Interface should be user friendly.

 During installation testing we validate below factor:

i. Setup program execution before installation i.e. all file are available or not.
ii. Should have easy interface during installation.
iii. Check occupied space after installation.
iv. Check it should get easily uninstalled.

6..Globalization Testing:----

 It is the process to checking the weather application support to different different languages or
not.
 When user changes in languages it should get changes but number should be in English.

 Note: During globalization testing we don’t touch backend i.e. Backend testing can’t be performed
i.e. validation should be performed only on front end.
During globalization testing we perform:
Functionality
Page navigation
GUI validation
Tab validation
Hyperlink accessibility /line validation

7…Sanitation Testing:---

 In this testing we test for extra features which are not mentioned in the customer requirement.
 Eg.----Suppose in paytm application in this customer requirement is below each object there
should be a price like Rs 400 but developed it Rs 400 Rs----This Rs is extra feature.

8.—Parllel Testing:--

 In this testing to check the our product with other product like a comparesion.

Maintainance:---
After successful testing, the product is delivered (deployed to the customer for their use), Deployment
is done by the Deployment/Implementation engineers and Once when the customers start using the
developed system then the actual problems will come up and needs to be solved from time to time.

Fixing the issues found by the customer comes in the maintenance phase. 100% testing is not possible –
because, the way testers test the product is different from the way customers use the product. Maintenance
should be done as per SLA (Service Level Agreement)
 Black Box testing Includes:==

1.Functional Testing 95%

2.Usability Testing
3.Security Testing 5%
4.Perfimance Testing

1.Functional Testing:---In this testing test the internal function depends upon external functionality.

2.Usabililty Testing:---It is also known as accesibilty testing, in this we test the user friendliness of
build.

1) Usability Testing:
 “During the test we validate user friendliness of screen or build.”
 Usability Testing is classified into 2 categories:
a) GUI (Graphical User Interface) b) Manual Support

a) GUI (Graphical User Interface)

 Ease of use (Easy to understand as simplified as possible.
E.g. Hike has more functionality than what’s up still most of people using
what’s up because of its ease of use.
 Speed of interface (Less no of events to complete a task)
E.g. For what’s up while sending a existing msg. there is a option forward it takes
less no of events than copy paste option
 Look and feel (pleasantness & attractiveness)

 GUI Defects
 Successful message is not getting displayed as “Green”
 Unsuccessful message is not getting displayed as "Red"
 Label name is not getting displayed with correct version with respect to baseline
document.
Note: What is mandatory field?
Mandatory / compulsory: without filling this user should not proceed.

Note: As a test engineer we have to work like a technical engineer but think like an end
user.

3.Security Testing:---This check the privacy of build for user aspect.

Q. Do you involved in Security Testing?

Ans.:- Yes I have involved in role based access Security system.

 It is classified in to various categories:

a) Authorization
b) Access control (Authentication)
c) Encryption and Decryption
 a) Authorization
 To check whether user is valid or not, to access the application.

b) Access control (Authentication)

 A valid user has the permission for a specific application or not is called Access control
(Authentication).
e.g. Naukri.com

4.Performance Testing:---This check the speed of processing and ability of system how it handle load.
This issue only solved by automation testing

c) Load testing
d) Stress testing
e) Storage testing
f) Data volume testing
g) Endurance testing

a) Load Testing:----
 “The execution of our application is under customer expected configuration and
customer expected Load, to estimate the performance, is called as load testing.”
b) Stress testing
 Stress defines maximum load.
(Stress = Maximum Load)
 "During this stress testing, the execution of over application under customer
expected Configuration and customer expected load and universal load (peak
out) to estimate the performance is called as stress testing.”
c) Storage testing
 “During this test the execution of our application under the huge amount of
resources, to estimate the storage limitation of our application is called
storage testing."
E.g. Pen drive of 2 GB max data

d) Data volume testing

 “The execution of our application under customer expected configuration, to
estimate the peak limit of data, is called as Data volume Testing."
i.e. No. of records.

e) Endurance testing
 “During this test we check whether our application bear(carry) the customer
expected load for a specific time period to ensure application is normal or any
abnormal behavior.”
Load: This Testing satisfies the customer.
Endurance: This testing satisfies the customer for specific time period.
Q. What is difference between functionality and non-functionality?

Parameter Functional Non functional

Execution It is performed before non It is performed after functional

functional testing testing

Focus Area It is based on customer It is focus on customer

requirement expectation

Requirement It is easy to functional It is difficult to define for non

requirement functional

Usage Help to validate the behaviors Help to validate the

of the application performance of the application

Manual Testing It is easy to execute by manual It is hard to manual

Functionality It describe what the product It describe the how to product

does work

Example Check login functionality The dashboard should load in

2 seconds

Q. Which backend you are using?

Q. Which database utility tool you are using?

Q. Where you write query?

Ans.:- SQL Developer (Version) [This is Oracle’s product] Toad

(Version) [This is Dell’s product]
SQL Developer is database utility tool.

Q. What is normalization?
Ans.:- It checks redundancy.

 Backend Testing / Database Testing:

 In this we test impact of content operation.
1. Data manipulation
2. Data Validation
 3. Table structure Validation

 During database testing we are going to check impact of content operation i.e. we have to check
impact in database with respect to user front end operation.

1.Data Manipulation:
 Two different databases but having parameters, attributes, features.

 Suppose we want to find no of females working in Capgemini, whose branches

are in Pune and Chennai.
In Pune branch database female denoted as ‘F’ and in Chennai branch database female
denoted as ‘Female’
 Table Structure Validation:
 In this we test- Data Type,Data Type Size,Mandatory,Null,Range,Flag

Testing Terminology:

1) Monkey Testing:
 It is also called as Gorilla, Chimpanji, speed testing.
 “During this test we validate conduct test on basic or core functionalities of the
application w.r.t customer requirement” i.e. we have to concentrate on high
priority test cases.
 Practically maximum no. of text cases need to be execute & w.r.t minimum time
period through which we cover all core functionalities.

Q. If you have pro test cases needs to be executed and tomorrow is delivery. What will
be your approach?

Ans.:- Yes. I think we need to execute high priority test cases to cover the core functionality .

*B mandatory

*C mandatory

High priority

D
 High priority
cancel Transaction

2) Exploratory testing:
 Level by level functionality coverage is called as exploratory testing.
 E.g. Study unknown project step by step and performance the testing.

Q. If you act aware about functionality or application, what is your approach?

Ans.:- Yes in this situation we have to cover one by one functionality coverage, i.e. we can call it
exploratory testing.
E.g. If you have experience in telecom domain and how you are working banking domain then
exploratory testing is used.

3) Adhoc testing:

Q. If you are aware about functionality but you don’t have into about test data then what
will be your approach?

Ans.:- As I am aware about functionality and with the help of my past experience, I am going to test the
application functionality.

Q. Difference between exploratory and adhoc testing.

4) Big Bang Testing

 (I never got a chance in this test.)
 Big bang means one big test i.e. during big bang testing we concentrate on a
major functionality from start to end.
 After completion of entire software development, testing team concentrate on a
single stage instead of multiple Stages.
 It is also called as informal testing
Q. what is inspection / walkthrough / Informal test / big bang Test?
Ans.:- Practical example:
Customer registration A/C
view
ADD beneficiary
Transaction

 In this we only test major functionality i.e. transaction, no need to test customer requirement,
account view, add beneficiary as these functionality are dependent
i.e. transaction is working fine then all other functionality are also working.
5) Defect Seeding/Debugging
 Defect seeding is the process in which one group of the project inject the defects in the product
while other group test the product to remove them. It is also known as debugging.
 It is a reliability measurement for release of the software product.
 The purpose of this method is that while finding the known seeded defects, the unseeded
defects can also be found. Defects which are seeded are similar to real defects. Therefore they
are not very obvious and easy to detect.
 Defect seeding act as a method to check the efficiency of the testing process. It serve as a
confidence measure to know the percentage of defect removal rates.
 The total number of latent defects can be identified in a work product by following
formula:

Total Latent Defects = (Total seeded defects / Defects seeded found)* Original defects found

 When a group knows that there are seeded defects in the system, it become as a challenge for
them to find as many of them as possible. It add as a new energy into their testing process.
 In case of manual testing defect are seeded before the start of the testing process.
When the tests are automated, defects can be seeded at any time.
 In defect seeding we should take care of following points:
 All seeded defects should be removed before release of the product
 Code for defects should be written in such a way that errors can be easily identified
 Number of lines should be minimum to seed defects so that efforts during defect removal
becomes less.
 We should estimate the effort required for defect clean up and identification.
 Static Testing Vs Dynamic Testing

 Static testing is verification testing technique where we test the requirement doc and
design doc prior to software being developed i.e. testing without giving any i/p.
 Testing is done before code developed.
 This done during analysis and design phase using reviews techniques.
 It is about prevention.
 Main objective of Static testing is to improve the quality of software product by finding
errors in early stages of development cycle.
 Also known as ‘Non execution testing’ or ‘Verification Testing’.

 Dynamic testing is validation testing where we test the developed software i.e. testing
with i/p and checking the expected results.
 Testing is done after code developed.
 This testing done by white box testing or black box testing.
 It is about Cure.
 Main Objective Dynamic testing Software product work as per business requirements.
 Also known as ‘Execution Testing’ or ‘Validation Testing’.

Verification and Validation

 These both testing techniques are to check that software product is meeting the
customer requirements.
• Static Testing ---> Verification
• Dynamic Testing ---> Validation
• Verification + Validation ---> SDLC
• Verification ---> Quality Assurance (QA)
• Validation ---> Quality Control (QC)

Q. Difference between Static and Dynamic Testing

Static Testing Dynamic Testing

Def- BA will check Documents, Designer Def- Tester will check system & functional
will check design, developer will check code of application/ software/ build
these processes called Static Testing
Static Testing called as Verification Dynamic Testing called as Validation
In Static Testing we can change quality In Dynamic Testing we can change quality
control of application assurance
Static Testing involved BA, Designer, Dynamic Testing involved Tester
Developer
In Static Testing called In Progress Testing Dynamic Testing is also called end Testing
Q. Difference between Verification and Validation

Verification Validation

The verifying process includes checking documents It is a dynamic mechanism of testing and
,design ,code and program validating the actual product

It does not involve executing the code It always involve executing the code

Verification uses method like And in this Black box and white box and non
review,walkthrough,inspection etc functional

Weather the software confirm to specification is Weather the software meets the requirement
checked and expectations of the cutomer

It finds early in the development cycle It can find bugs that the verification process can
not catch
Target is appliacation and software Target is an actual product
architecture ,complete design high,low ,database
design

Q. Difference Between STLC and SDLC?

PARAMETER SDLC STLC

Origin Development life cycle Testing life cycle
Objective The main object in this is the to The objective of this phase is
complete the successful testing only
development of the software
including twsting and other
phases
Requirement gathering In SDLC the BA gather the In STLC QA team analyze the
requirement and development requirement document like
plan functional and non functional
document and create system
test plan
High and Low level design In this Development team create In this team analyst create the
high and low level design plan iteration test plan
Coding The real code is developed and The testing team prepare the
actual work takes place as per rest enviorement and execute
the design documents them
Maintainance Inclueds post deployement Tester execute regression
support and update suites ,usually automation script
to check maintainance code
deployed
 Q. Difference between WBT and BBT

WBT Testing BBT Testing

WBT (white box testing) testing BBT- black box testing
WBT will be performed by Developer BBT will be performed by Tester
WBT types BBT types-
1. Unit Testing 1. Sanity testing/ smoke testing
2. Integration testing 2. Functional testing
3. Re-testing/ Regression testing, etc
WBT performed/ check- loop coverage, BBT performed/ check- Functionality
Logic testing, branches coverage, code coverage, Behavioral coverage, etc
coverage, etc
WBT is also called code level testing BBT also called system & functional testing

Q. Difference between functionality & Non- functionality testing?

Functionality Non- functionality
Internal feature we are testing External feature we are testing
In functionality testing, we are checking In Non-functionality testing, we are checking
functional feature for increasing performance feature for increasing
In functionality testing we performed - In Non- functionality testing we performed -
BIEBSC RSSIISPG
In functionality testing, checking will be defied In Non-functionality testing, checking will not
in US/ requirements be defied in US/ requirements

Q. What is Grey Box Testing?

 Grey box testing is the combination of WBT and BBT

 Tester need Some programming knowledge
 Tester should know the some coding of internal system
 Software Development life cycle models
1. Waterfall Model
2. V Model
3. Agile

A) Waterfall Model
 There are seven phases in waterfall model
1. Requirements Gathering
2. Requirement Analysis
3. System Design
4. Coding/Implementation
5. Testing
6. Deployment
7. Maintenance

 In a waterfall model, each phase must be completed fully before the next phase starts.
 The Waterfall Model was first Process Model to be introduced. It is also referred to as a
linear-sequential life cycle model.
 It works as ‘Locking Process’ means when BRS completed then starts SRS stage starts
and so on.
 It is very simple to understand and use.
 This type of model is basically used for the project which is small and there are no
uncertain requirements

Requirement Gathering

Requirement Analysis

System Design

Implementations

Testing

Deployment

Maintenance

 Advantages of waterfall model:

 This model is simple and easy to understand and use.
 It is easy to manage due to the strictness of the model
 In this model phases are processed and completed one at a time.
  Disadvantages of waterfall model:
 Once an application is in the testing stage, it is very difficult to go back and change in coding.
 Time Consuming
 High amounts of risk
 Not a good model for complex and object-oriented projects.
 Poor model for long and ongoing projects.
 When to use the waterfall model:
 This model is used only when the requirements are very well known, clear and fixed.
 The project is short.

B) V Model
 V stands for Verification & Validation.
 This model defines the conceptual mapping in between Development stages & test
i.e. in this model all development phases can be integrated with testing phases.
 Testing of the product is planned in parallel with a corresponding phase of development
stages.
 Multiple stages of Testing avoids defects multiplication.

 Development Phases Integration with Testing Phases : -

a) User Requirements Vs Acceptance Testing:-
 Business Analyst category people gather requirements and the document the
requirements, after documentation Reviews, Meetings like verification will take
place in order get correct & Complete Requirements.
 End Users conduct Acceptance Testing using Business / User Requirements.

b) Software Requirements Vs System Testing : -

 Development Manager/Tech Manager converts User Requirements as Software
Requirements and Reviews, Meetings like verification methods will be
performed on Software Requirements, after Verification Project manager
provides Approval.
 Independent testers create test cases from Software Requirements in order to
perform System Testing
 c) Design Vs Integration Testing : -
 System Architect / senior developer creates Global design, Informal Review/
Walk through / Technical Review / Inspection like Verification methods will be
applied on Design documents.
 Developers perform Integration Testing based on Software Global Design.

d) Coding Vs Unit / WBT : -

 Developers perform Unit /Component Testing based on Software Detailed
Design

 Advantages of V Model : -
 Tester role will take place in the requirement phase itself.
 Multiple stages of Testing available so that Defects multiplication can be reduced.
 Can be used for any type of requirements
 Due to Multiple stages of Testing and Multiple teams involvement Quality can be
improved.
 Disadvantages of V Model : -
 It an expensive model than Waterfall model, needs lot of resources, budget
and time.
 Co-ordination and Maintenance are difficult.
 Adoption of changes in Requirements and Adding New Requirements at
middle of the process are difficult.
 It needs an established process for proper implementation

LCD (Life cycle development) LCT (Life cycle testing)

Information gath. (BRS) Assessment of dev plane

Analysis (SRS) Prepare test plane

Requirements Testing

Design – HDL, LLD Design phase testing

Coding - Developer Program Phase testing (WBT)
Test case design (TCD)

Install Build System & fun. testing (BBT) - Pune

User acceptance testing (UAT)- Client
Knowledge transfer (KT)
Maintains DRE (defect removable efficiency)
/Support / CR (change request)/ RFC
 Agile Model/Methodology
In all models the customer requirements are predefined. If the customer wants to change any
requirement, you have to take that requirement in maintenance and extra charge will be applied. But in
the agile model, requirement come at any stage of development. That is not plan driven, its value driven.

The main agile methodologies are:-

 Scrum
 Kanban
 XP (Extreme Programming)
 FDD (Feature Driven Development)
 AUP (Agile Unified Process)

Q. Who are the responsible persons in agile?

Ans: - 1) Product Owner (Business Analyst) (Requirement Gathering & Requirement Analysis)

2) Scrum Master (Project Manager) (Manage Project & Monitor Project)

3) Stories (Use Cases/Test Scenario/SRS)

4) Event (Meetings)

5) Solution Owner (Client)

6) Product Backlogs (Requirement for overall Project)

7) Sprint Backlogs (Requirement for Specific Release/Sprint)

Scrum Architecture
Solution Owner(client): - Defines the Cost of the Production.
Product Owner(BA): - Responsible for collecting the Requirement of Project.
Product Backlog: - List of the requirement collected by Product Owner(BA) for overall project(list of
overall requirement of the product/project collected by BA)
Sprint Backlog: - From product backlogs, product owner will be going to select same requirement
that will be deliver in specific sprint. (Client will select specific requirement from product backlog
that will be deliver in specific sprint)
 Stories: - After Sprint backlog get analysed, product owner will define stories. Stories are nothing
but used cases/SRS. (After analysing sprint backlog, BA will define stories)
One Product Backlog contain more than One Sprint Backlogs. One Sprint Backlog contains multiple
Stories. Stories divided into Test Scenario and Test Scenario after divided into Test Cases

One Product Backlog - more than One Sprint Backlogs

One Sprint Backlog - multiple Stories

Stories - Test Scenario

Test Scenario - Test Cases

Solution Owner (Client)

Product Owner (Business analyst)

Product

Sprint Planning Meeting

Duration of 1 Sprint = 2 to 4 Weeks (We will tell 2 or 4
weeks)

Sprint Backlogs

(Requirement in one module)

Sprint backlogs divided into Stories (BRS)
Stories divided into Test Cases (SRS)

4 Weeks

Scrum Master(PM)

Scrum Meeting
o Sprint Planning Meeting
o Daily Standup Meeting
o Sprint Review
o Sprint Retrospective

1 week – 2 meetings 4 hours for 2 week

Of 1-1 hours (8 hours for 4 week)

1. Sprint Planning Meeting

(Focus on what to deliver & how we are going to deliver)
Responsible Person – Scrum Master (Project
Manager)

(Attendee – Product Owner, Scrum Master, Development Team, Testing Team, Technical
people of client).
(Attendee – Product Owner (BA), Scrum Master (PM), Development Team,
Testing Team, Technical people of client).

Discussion in Meeting

 Product backlog

 Time Discussion

 How many Sprints are there?

 How many Sprints needs to create?

2. Daily Standup Meeting

Everyday 15 min Meeting Responsible Person – Scrum Master (Pro manager)

 (Attendee – Product Owner, Scrum Master, Development Team, Testing Team).

Whoever involved in Sprint, they all are present in Scrum Meeting.

According to our Client daily Standup Meeting will be scheduled.

Discussion in Meeting

1. What we did yesterday to achieve sprint goal?

2. What we are going to do today to achieve sprint goal?

3. Sprint Review
This Meeting takes place at the end of Sprint.

(1 month = 4 hours) Duration 2 weeks = 2 hours

(Attendee – Product Owner (BA), Scrum Master (PM), Development Team, Testing Team, Technical
Team of Client)

Discussion in Meeting

1. What has done in the sprint?

2. Product Owner explain how many product backlogs are completed & how many are remaining.

4. Sprint Retrospective (Agile Grooming)

This meeting takes place after Sprint Review/after releasing first Sprint and before next sprint planning meeting.
 Discussion in Meeting

 We will collect all learnings.

 We will identify what goes well with this Sprint & What did not goes well with this sprint.
According to that we will improve our progress

For this improvement one plan is made for next Sprint

 The work which will be performed in sprint is planned in Sprint Planning Meeting. Attendee are
going to attend meeting, Purpose of meeting – have they completed all responsibility.
 Objective of Sprint Planning: - To obtain feedback from client for further progress.
 Product Backlog: It is a list of all requirements from clients that are needed in the product and
should be accomplished before the end of the project.
 Sprint Backlog: It is a list of all finalized user stories, bug fixes, work items, etc., that are completed
and selected by scrum to be completed during the current sprint.
 Sprint Planning Meeting: In this meeting, the discussion takes place about features and product
backlog items (user stories) that are important to the team. This meeting is usually attended by the
product owner, Scrum Master and Scrum Team. It is a weekly meeting and usually lasts for about an
hour.
 Sprint Review Meeting: In this meeting, the Scrum team gives a demonstration of the product.
After this, the product owner determines which items completed and which are not completed. He
also adds some additional items to the product backlog on the basis of feedback from customers or
Clients. Its main aim is to inspect the product being created in the sprint and modify it if required.
 Sprint Retrospective Meeting: This meeting takes place after the Sprint planning meeting. In this
meeting, the Scrum team meets again to inspect itself and discuss the past mistakes, potential
issues and methods to resolve them. Main aim of this meeting is to improve the development
process. This meeting lasts for about 2-3 hours.

Q. Which kind of meeting you have attended in Agile/Scrum?

Ans.:- 1. Sprint Planning Meeting

2. Daily Standup Meeting
3. Sprint Review
 4. Sprint Retrospective
Q. How many weeks in your Sprint?
Ans.:- 2 weeks or 4 weeks

Zero Sprint: It generally refers to the first step or pre-preparation step that comes just before the first
sprint. It includes all activities such as setting a development environment, preparing backlog, etc.

Principles of Agile Testing

 Continuous Testing
 Continuous Feedback
 Team Work or collective work
 Clean Code
 Less Documentation
 Test-Driven
 Customer Satisfaction

Estimation/Transformation Process in Agile:-

 When product backlog is converted/transform into sprint backlog w. r. t. its sprint is called as
Estimation Process in Agile.
 Product Backlog ---> Sprint Backlog ---> Stories ---> Test Scenario ---> Test Cases

Q. Who is involved in estimation process?

Ans.:- Product Owner, Development Team Lead, Testing Team Lead

e.g.
 If we have 100 product backlogs to deliver within 5 months then we need to release 5 sprints. Each
sprint will contain 20 sprint backlogs. Duration of each sprint is 4 weeks.
 If sprint 1 we have to deliver in 4 weeks but it will completed within 3 weeks then we will go for
next sprint 2.
 If we are not able to deliver sprint 1 within 4 weeks then client will understand scenario that agile is
flexible & we can fix it in next sprint 2.

 Agile Velocity:-
 Velocity in agile means the average amount of work a team can complete in one Sprint.
 It is a guessing technique.

Agile Velocity = No of Sprint backlog delivered in 1 Sprint * Total number of Sprints

Burndown Chart:-

 It is important for scrum master.

 Burndown chart is created in Jira for how much work required and how much pending.
  The burndown is a chart that shows how quickly you and your team are burning through your
customer's user stories.
 It shows the total effort against the amount of work we deliver each iteration.
 It is a graphical representation of remaining work to do vs time.

 Different Types of meeting

Meeting Purpose/ Use Involved in meeting
1. Grooming - Requirement /User Story understand or 1hr- BA, Development
meeting clear the doubt Team, Testing Team,
(first day of current Designer,
sprint) PM(optional)

2. Sprint planning - Current sprint how much US we can 30min- PM, BA,
meeting add/kept (decided by PM, BA, Designer) Designer,
(First day of sprint) - Estimation (time span) Development Team,
 Ex. 1US Estimation/ Story point = Tester team
Design 2 hr +Dev 14hr + Tester 8hr= 22hr
3. Scrum meeting/ work Progress of Developer & tester 15min- PM, Designer,
Daily stand up 1. What you have yesterday Development Team,
meeting 2. What are doing toady Tester team, BA
(Every day in sprint) 3. Issue/roadblock are facing
(10 to 10.15 am)
4. Sprint Review - Tester  current sprint US works 1hr- Client/ BA, PM,
meeting Demo/ Review Designer,
(Last day of sprint) Development Team,
Tester team
5. Sprint - Currant sprint what good & what bad 30min- PM, BA,
retrospective we have done Designer,
meeting (Bad work so it don’t go to next sprint) Development Team,
(Last day of sprint) Tester team

Interview Question-
1. What is Agile & what is Sprint?
2. What is your, daily routine in your company? OR How agile process following in your organization?
3. What is agile methodology?
4. What is Burn down Chart, Burn UP Chart, Velocity, and EPIC?
5. What is estimation/story point? How you are deciding?
6. What are different types of meeting OR what are agile carmines?
7. What things you have discuses in last Retrospective meeting?
Answer-
1. Last Retrospective meeting- In current sprint what good and what bad has been be happens that
has been discussed.
2. In last Retrospective meeting, I have given suggestion about; developer will add/ mentation
date of every build that will be related to testing.
3. In last sprint I have found more defects due to deployment process (Dev environment to SIT
environment), Developer will check the deployment process
4. In last sprint I have found more defects due to developer not doing the Unit Testing documents.
Suggestion I have given, developer will do unit testing properly.

Software Testing Levels

a) Unit Testing
b) Integration Testing
c) System Testing
d) Acceptance Testing
a) Unit Testing
 In Unit Testing level individual units/ components of a software are tested.
  The purpose is to validate that each unit of the software works as designed.
 Developers conduct Unit Testing using White Box Test Design Techniques

b) Integration Testing-
 In Integration Testing Level, individual units are combined and tested as a group. The
purpose of this level of testing is to expose faults in the interaction between
integrated units.
 Independent Testers conduct this level of Testing
 After completion of WBT and its review, developers integrate all the dependent
modules to form an application/system with respect to HLD and LLD.
 Developers and testers both will be involved in IT.
 Developers do integration of all the modules and testers perform testing on that
integrated application.
 There are 3 approaches of Integration testing
1. Top-Down Approach
2. Bottom-Up Approach
3. Hybrid Approach

1) Top down Approach

 The interconnection of the main program & some sub-programs is called the Top-
Down Approach.
 Programmers use temporary programs called stubs instead of sub- programs,
which are under construction.
 The other name for stubs is ‘Called Programs’.
 In this Approach first Parent Modules are developed after that Child Modules are
developed then interconnect Parent & Child Modules.

Main

Stub 1 Stub

Stub 2 (Under process)

Submodule 1(IBM)

Stub 1

Main Module (TCS) Stub2 Submodule2(Infosys)

 Stub3

Submodule3(Accenture)

 In this Approach, sub modules are not present with us.

 Either they are with other organization or under construction.
 For above conditions, to test the interdependent module we need to use ‘Stub’.
 Stub is temporary program to test the main module while sub module is in under
construction or it’s with other org.
 It is developed by Developers. Mostly it is in XML format.
 We call it as WSDL file --- Web service description language

2) Bottom Up Approach
 The interconnection of internal sub-programs without using main programs is
called the bottom up approach.
 In this approach, programmers use a temporary program instead of main
program, which is under construction.
 The temporary program is called Driver or Calling Program
 In this approach first Child Modules are developed. After that parent modules are
developed. Then interconnect Child Modules with Parent Modules.
 In the interconnection Process is there any main module is under construction
then the developers create temporary program that is called Driver.

Main(Under construction)

Stub 1 Driver

Stub 2

Submodule 1(IBM)

Driver 1
Main Module (TCS) Dri 2 Submodule2(Infosys)

Driver3

Submodule3(Accenture)
  In this Approach, Mani modules are not present with us. Either they are with
other organization or under construction.
 For above conditions, to test the interdependent module we need to use
‘Driver’.
 Driver is temporary program to test the Sub module while main module is in
under construction or it’s with us.
 It is developed by Developers. Mostly it is in XML format.
 We call it as WSDL file---Web service description language

3..Hybrid Approach:
 Also known as Sandwich approach, this is a combination of the Process Top-
Down Approach & Bottom-Up Approaches.

Main (Under construction)

Driver

Stub 1

Stub 2 Stub

Stub 3 (Under construction)

Q….Difference Between Stub And Driver

STUB DRIVER

Temparory program is used instead of sub program Temporary program is used instead of main
which are under construction. program which are under construction.

Used in top down approach Used in Bottom up approch

Other name is “called program” Other name is “Calling program”

Return control to the main pogram

 c) System Testing
 In System Testing level a complete and integrated software is tested. The purpose of
this test is to evaluate the system’s compliance with the specified software
requirements
 After completion of integration testing, a separate testing team receives a software
build from the development team. This team a set of block box testing techniques to
validate that software build.
 Independent Testers conduct System Testing using Block Box Test Design
Techniques

d) Acceptance Testing-
 In Acceptance Testing level a software system is tested for acceptability. The
purpose of this test is to evaluate the system’s compliance with the business
requirements
 Here, Acceptance basically two types,
1) Internal Acceptance Testing (Alpha Testing):
 It is conducted by members of the development organization who are not directly
involved in the project, usually it is the members of Product Management, Sales
and/or Customer Support people.
2) External Acceptance Testing / User Acceptance Testing (Beta Testing):
 It is conducted by the end users of the software.

 Note: Acceptance Testing environment and System Testing environment almost all
same, but Unit Test Environment and integration Test environment are different.

 Entry Criteria and Exit Criteria

a) Unit testing
 Entry criteria of Unit testing --- Complete the coding
 Exit criteria for Unit testing --- Unit testing should be completed

b) Integration testing
 Entry criteria --- Unit Testing Completed
 Exit criteria --- Integration testing is completed

c) System Testing
 Entry criteria --- Integration Testing Completed
 Exit criteria --- System testing is completed

d) Acceptance Testing
 Entry criteria --- System Testing Completed
 Exit criteria --- Acceptance testing is completed
  The entry and exit criteria for the test are closely related to the purpose and
expected results for the test.
 The entry criteria describes the conditions that must be met before you can start the
test.
 The exit criteria describes the conditions that must be met before the test is
completed.

Test Design Techniques

 It is also called ‘Test Case Design Technique’ or ‘Test Data Design Technique’.
 It is used to prepare data for testing.

 Types of test design technique

1) Equivalent Class Partitioning (ECP)
2) Boundary Value Analysis (BVA)
3) Decision Table Based Testing
4) State Transition
5) Error Guessing

1) Equivalent Class Partitioning

 It can be applied at any level of testing (Unit, Integration, System and Acceptance
Testing)
 Equivalence Partitions/Classes can be found for both valid data and invalid data.
 In this we divide/partition the Data into various classes and we can select data according
to class then test.
 It reduces the number of test cases and saves the time for testing.
E.g. User Name field accept only Alphabets

Example 1 (Data Type): Mostly Used technique in ECP

• Customer Identification Number field in a CRM system accepts only numbers.
Partition 1 Partition 2 Partition 3 Partition 4 Partition 5 Partition 6
Alpha bytes Numbers Special Characters Alpha-numeric Blank Decimal
(Invalid) (Valid) (Invalid) (Invalid) Invalid Invalid

Example 2 (Others)
A Payment management system accepts credit card payments only
Partition 1 Partition 2 Partition 3
Credit card Net Banking Cash on Delivery
(Valid) (Invalid) (Invalid).

2) Boundary Value Analysis (BVA)

• The maximum and minimum values of a partition are its boundary values.
• Behavior at edge of each equivalence partition is more likely to be incorrect than behavior within
the partition.
• Boundary value analysis can be applied at all Test levels(Unit, Integration, System and Acceptance
Testing).
Example 1: Partition 1 Partition 2 Partition 3
11 to 99
Min-11---Pass/Valid
Max-99—Pass/Valid
Min+1-12----Pass/Valid
Max-1-98---Pass/Valid
Min-1-10---Failed/Invalid---Defect
Max+1-100– Failed/Invalid---Defect
Example 3 (Data Size)
Phone Number filed accepts 10 digits number only
Partition 1 Partition 2 Partition 3
Below 10 10 Above 10
(Invalid) (Valid) (Invalid)
Min-10
Max-10
Min-1-9
Max+1-11
Max-1=9--
Min+1--11
Example: User Id field accepts 10 to 20 characters and it should accepts alphaNum values.
ECP
Albhabetes---Valid/Pass
Numbers—Valid
Alpha+Numbers—Pass
Special char—Invalid
Alpha+Special Char---Invalid
Numbers+Special Char--- Invalid
Alpha+Numbers+Special Char - Invalid
Blank---Invalid
BVA
Min- 10
Max-20
Min-1-9
Max-1-19
Min+1- 11
Max+1- 21

1) Decision Table Based Testing

 It is also called as Cause-Effect Table Technique.
  This Technique will be used if we have more conditions and corresponding actions.
 In this technique we deal with combinations of inputs.
 If we have more number of Conditions/Actions then we use decision table technique.

2) State Transition
 This testing technique allows the tester to test the behavior of an AUT/application.
 The tester can perform this action by entering various input conditions in a sequence.
 In this technique, testing team provides positive as well as negative input test values for
evaluating the system behavior.
E.g. Consider the Login Module

2) Error Guessing
 It is used to find the bugs in a software application based on tester’s prior experience.
 In this technique we don’t follow any specific rules.
 It depends on Tester Analytical skill and experience.
E.g. 1) Submitting a form without entering the values.
2) Entering invalid parameters.
3) Uploading files that exceeds the maximum limit.

Real time interview question-

Q. What role & responsibility?

 Requirement / US analysis (grooming meeting)
 Test scenario identify
 Test cases design
 Test cases review (internal/ external review)
 Test cases execution – Test proof
 Defect report
 Test summary report (help to test lead)
 Client interaction (Sprint review meeting)
 Daily stand up / Scrum meeting attend
Q. When you know that testing is completed?
 All test cases need to execution
 All defects need/ should to fixed
  Traceability matrix need to be completed

Q. How many test cases per day you will write & how may test cases you will execute per day?
 It totally depends on complicity US
 An average I am writing (TCD) per day/ US 25 to 30 test cases.
 TCE, it totally depends on complicity of testing OR complicity of functionality
 An average I am executing (TCE) per day 15 to 20 test cases.
 In Automation, we are automating 4 to 5 test scripts

Q. How many defects you have raised per day?

 It totally depends on complicity of US
 If developer has done wrong coding, then I will get more defects
 If developer has done properly coding then I will get less defects
 An average, I am creating/ raising 4 to 5 defects per US.

Q. When developer is not accepting your defects then what is your approach?
 When I found defects, I will rise to the developer & with defects I am attaching screenshot.
 But still developer is not accepting, then we will take call with developer à I will share my screen
and show cases defects.
 But still developer is not accepting, I will mail to Test Lead, PM, designer & all developer
 Same things we will point out in daily stand up meeting

Q. If defect is found in last day of sprint OR if we found defects in last moments, then what is your
approaches?
 Tester – High priority defects will be informed to the developer & fix ASAP
 If developer is fixing defects à so we will extend you work
 If developer is not fixed all defects à So we will work in Saturday & Sunday
 If developer is not fixed all defects à So we will work in Saturday & Sunday
 If developer is not fixed all defects in Saturday & Sunday à So in next sprint we will prepare a US
with name “Carried over Bug” (PM, BA)

Q. If we have found a defect related to environments problems so what is your approaches?

 When I found defects, I will rise to the developer & with defects I am attaching screenshot.
 But still developer is not accepting, then we will take call/ meeting with developer à I will share my
screen and show cases defects.
 We will tell to the developer kindly check deployment process. (Dev environment & SIT
environment)
 Tester will do hard refresh OR I will clear all cashes & cookies and we will test application
 But, still there is a problem then we will inform to PM, Test Lead & developers
  Same things we will discuss with Scrum meeting/ Daily stand up

Q. What problems you have faced in your carrier Or What challenges you have faced in testing?

 If we have lack of knowledge about domain/ project

 If we have less test data
 If we have less resources in the project
 If developer is not communicated properly
 If we have problem in environments
 If we have problem in deployments
 Frequent changes in requirement

Q. In Regression suite how many test cases are present?

 Project  Module (Rent payment)
 Initial developments (20 US)  Manual Testing (1 US= 25 to 30 TCD)
 Regression suite test cases (1 US= 5 to 7 TCD)
 In Module (Rent payment)  Regression suite will contains (50 to 60) Automation Testing

Q. Difference between functionality & Non- functionality testing?

Functionality Non- functionality
Internal feature we are testing External feature we are testing
In functionality testing, we are checking In Non-functionality testing, we are checking
functional feature for increasing performance feature for increasing
In functionality testing we performed - In Non- functionality testing we performed -
BIEBSC RSSIISPG
In functionality testing, checking will be defied In Non-functionality testing, checking will not
in US/ requirements be defied in US/ requirements

Q. Difference between User story & Use cases?

Use cases User story
Use cases will be driver from SRS User story will be derived from Use cases
Use cases defines in-depth knowledge Or all Use story defines short knowledge Or all short
details about the requirement about the requirement
Ex. Only valid cancellation types will be listed Ex. 1. For Saving a/c – 5 drop down option
on the cancellation tab 2. For current a/c – 7 drop down option

Q. What is ready & done state?

 Ready- US all task (development, Testing) is completed then US status will be ready
 Done- If US is deployed to Client then US status will be done

Q. When the deployment will be in your project?

 At Saturday (next day of end sprint). 2 week Monday to Friday
  All deployment will be done by developer

Interview question-

1. What is team size in last project?

2. What is the tester in your project?
Answer- In my last we have 4 testers. In which I am working a Manual Tester, Test lead working as
Manual/Automation/API testing. 2 Tester- 1 work manual testing & 1 automation testing
3. What is size of developer in your project?
4. In which team you have worked?
5. What is SDLC process?
6. What is the difference in SDLC & STLC?
7. What are SRS documents & have you see SRS documents?
8. When are we starting the testing?
Answer- Whenever we got SRS documents from BA throw Mail, then we are ready / understand
SRS documents. If we have doubts in SRS, then we are conducting the meeting with BA. When we
have cleared the doubt in SRS documents, we start TCD & TCE
9. What are SRS documents will contain?

Environment-
 In my project we have total 4 environments  Dev, SIT, UAT & Prod/Live
 Developer will the coding on Dev environments then developer will sent us a Build  Sent us a Mail
(Project management tool- JIRA/ HPALM)  Unit testing + URL
 Tester will do testing in SIT environments  TCD, TCE
 In TCE, if we found a defects then we raised/ create (Project management tool- JIRA/ HPALM) to
developer  Mail to developer (Project management tool- JIRA/ HPALM)
 Tester will inform to UAT team for testing Mail (Project management tool- JIRA/ HPALM)  Sent Test
proof to UAT team

Dev SIT FinalUAT Prod/Live

environment Environment (Developer + Environment
Regression
(Developer) (Tester) Tester)

DB/Server-172.20.10.122 DB/Server-172.10.22.134 DB/Server-172.30.16.104 www/https

Pune – Wipro Client – USA (HSBC)

Interview question-

1. Which technologies is used in your project

2. How many environments are present in your project?
3. How to get the Build?
 Answer- When developer will complete coding then sent build. In these we got Mail form
developer, these mail will contains Unit testing document & URL
 URL= 172.10.22.134:8080/paytm.com

4. What is URL of your project?

 Answer- SIT environment project/ Build URL- 172.10.22.134:8080/paytm.com

Testing-
Dev Environment-
1. Unit Testing
2. Integration Testing

SIT Environment-
1. Sanity Testing/ Smoke testing
2. BBT – Functionality & non functionality
3. Retesting Testing
4. Regression Testing

UAT Testing-
1. Alpha testing
2. Beta Testing

Dev Environment-
 In Dev environment, developer is working
 When developer will done the coding, then Developer will perform WBT (white box testing)
 WBT 2 type
1. Unit testing
2. Integration Testing

SIT Environment-

 What is XYZ testing?, Why we are doing these testing?, Are we preparing any documents? (TCD,
defects, TCE, etc), after these testing any documentation/ email/ inform to Test Lead, PM, BA, etc?
 In SIT environment, tester is working
  Tester will do TCD, TCE, defects raised/ inform to developer, Review/ demo, etc
 SIT environment different testing
1. Sanity Testing/ Smoke testing
2. BBT – Functionality & non functionality
3. Retesting Testing
4. Regression Testing

Sanity Testing-
 Sanity testing – it is first testing is SIT environment
 first testing is SIT environment it is called Level Zero Testing/ Build Verification testing / Tester
acceptance testing
 Whenever developer will sent US a new build then tester will check either the build is stable for
testing or not
 Stability of the Build – For testing either these build is stable or not
 Stability of application in sanity testing check or validation–
1. Validating Core functionality ex. Paytm- Recharge – recharge for every mobile
2. Validating the GUI/UI of application
3. Validation of link
4. Validating the Tab/Pages
5. Validating the Navigation

 In Sanity testing, tester are not writing the Test case

 When we are randomly application in sanity testing, if we found a defects then we will reject the
build. Defected can’t be created in project management tool (JIRA/ HPALM)
 If we will reject the build then we will inform to developer inform throw Mail (JIRA/HPALM)
 Ex. Developer has sent the new build – V9.0  Tester New Build then Sanity Testing  In Sanity
Testing if found defects  Mail to developer and reject the Build (V9.0)  developer will fix
defect and prepared a new version/ new build (V9.1)  Testing will do Sanity Testing
 In Sanity Testing what types issue found- Core functionality not work, Pop or link is not changing,
SIT Environments problem, System hang out, Run time problem
 In Sanity testing, we required 2 to 3 hr
 In Sanity testing performed by tester only.

Smoke Testing-
 Smoke testing  it is a advance version of sanity testing
 Smoke testing  If developer will sent us a build then test the build for testing, if we found a
defects then tester will provide the root cause of defects.
 Smoke Testing = Sanity Testing + Troubleshooting  Done by Tester
 Smoke Testing = Sanity Testing + Package validation  Done by developer
 In Smoke Testing, TCD is not happens
 In Smoke Testing, if we found a defect, then we will reject the build & we will give root clause of
the defects. Defected can’t be created in project management tool (JIRA/ HPALM)
 In Smoke Testing we required 2 to 3 hr
  Smoke Testing will be performed by Tester & developer

 In my Origination we performed only Smoke Testing.

Interview Question-

1. What is Sanity Testing & Smoke Testing

2. Which testing you have performed in your Origination
 Answer- In my Origination we performed Smoke testing only.
 In Smoke Testing, we are checking or validating stability of the build.
 In Smoke Testing, we will check Core functionality, Tab/Page, link validation, GUI/UI,
navigation validation, etc
 In Smoke Testing we required 2 to 3 hr
 If we found defects in smoke testing, then we will reject the build and we will provide the
root clause if defects.
 We will send us a mail to developer.
3. What is sanity Testing & Smoke Testing & which you performed?
4. Which is types defects you have found in Smoke Testing
5. If we found defects in smoke Testing then what is your approaches?
 Answer- When we are randomly application in smoke testing.
 If we found defects then we will reject the build.
 Defected can’t be created in project management tool (JIRA/ HPALM) & inform to
developer throw the Mail

Retesting-
 Retesting defines test the same feature in application / software with multiple test data.
 Multiple Test data we will get form database (SQL Server)
 If test data is depend on another company or data in not present in database then BA is collect data
from other company.
 Ex. Paytm – Login page validation- Mobile no. / Email id- Test data Mobile no –Idea, Vodafone,
JIO, BSNL, etc

Regression Testing-
 If we are doing System & testing Or Retesting and we found defects
 While doing testing if we found a defect then we perform regression testing
 We will raised defect to developer then developer will fix the defect and he will modify the build
 Regression testing – Re- execution of testing on modified build to ensure defects / bug will work
properly & there is no side impact on interconnect module.
 Regression testing= Regret + Action
 Ex. Paytm – Recharge module- Prepared functionality – Build
 Mobile no- VI, BSNL, Airtel, MTNL but for all JIO it is not working- Tester will raised the defect
– sent to developer the developer will fix the defect – Modified build tester will test regression
testing-
1. Check JIO mobile no. - Recharge module- Prepared functionality working- Multiple JIO
mobile no. / Multiple test data- Retesting
2. Check for another mobile no. - no side impact on interconnect module- 2 to 3 VI, BSNL,
Airtel, MTNL mobile no

 In Regression testing we are prepping regression suite (multiple test cases)

1. Failed test cases (Ex. JIO mobile no.)
2. High priority test cases/ Core functionality test cases ( ex. 2 to 3 mobile no, VI, BSNL, Airtel,
MTNL)
3. Extra feature test cases (Ex. +91- mobile no., +91 feature test cases)
4. If Time permits, remains test cases we will consider

 Regression testing are 2 time we can performed

1. Whenever we found a defects
2. Whenever build is moving from SIT/ UAT environment into prod environment then we
performed Final regression testing(End to End testing)
 In Regression testing, we are 2 to 3hr

UAT (User acceptance testing)-

 After completed testing in SIT environment, then we performed UAT testing
 When tester will do testing in SIT environment then we will prepared Test proof documents and
sent a mail (JIRA/HPALM) to UAT
 In Mail we will attached Test proof documents
 In UAT testing, system & Function testing with 3 to 4hr (becz they will validate your test proof &
some test cases they will execute)
 UAT 2 type
 1. Alpha Testing
2. Beta testing

Alpha Testing Beta testing

Alpha testing performed for service level Beta testing performed for product based
application application
Ex. Paytm, Flipkart, Phonepay, SBI, etc Ex. Adobe reader, Khatabook, etc
In Alpha testing both developer & Tester are In Bets testing both developer & Tester are
available not available
Issue/ defects immediately fix Issue/ defects immediately not fix – (new
version/ Build)
Client interaction is more (HSBC peoples) End user interaction is more

 I (tester), also I have performed the UAT testing

 In both environment SIT & UAT we can’t work

Priority & Severity-

 Priority & severity term will define/ creating for defects
 Priority term defines defects will impact on client business
 In Priority we have – Very High, High, Medium, Low
 Severity term defines defects will impact on functionality of application
 In Severity we have – Critical, High, Medium, Low

 Ex. High Priority & High Severity

1. Defects- In application Login page is not working
2. Defects- In Paytm mobile no. is not accepting

 Ex. High Priority & Low Severity-

1. Defects – If logo is not present in the application/ Build
2. Defects- In Home page spelling error in logo or in Focus world spelling mistake

 Ex. Low Priority & High Severity-

 1. Defect- Rarely used feature/functionality are not working
2. Defect – In payment promo code – Medical/ Travel promo code is not working

 Ex. Low Priority & Low Severity-

1. Defects- In Thank message, spelling is wrong –“Thank you” = “Thanks you!”
2. Defects- Some of button, World as “Submit” but spelling “OK”

 Severity – we will be decide by tester

 Priority – Initial we will decide Priority while creating defects, but in stand up I will inform
to PM, BA and they will decide