MANUAL TESTING NOTES

1. What is Software Testing?

Software Testing is the process of executing a program or system with the intent of finding errors. Software
testing is any activity aimed at evaluating an attribute or capability of a program or system and determining that
it meets its required results.
Purpose:
 The purpose of testing can be quality assurance, verification and validation, or reliability estimation.
Testing can be used as a generic metric as well. Correctness testing and reliability testing are two major
areas of testing. Software testing is a trade-off between budget, time and quality.
 The main course of testing is to check for the existence of defects or errors in a program or project or
product, based up on some predefined instructions or conditions.( It can be a scope document or
HLDD)
 To improve the quality of the product.
 The Purpose of Testing is to Analyze that the Product is according to Requirements

Outcome
In a layman Testing is the Final Process or a Parallel Process which determines the quality of the
Product and create a customer satisfaction . Any product with 0 % testing is considered to be 0 % in quality.

Need
The good reasons of testing are
 Quality Assurance.
 Verification and Validating the product/application before it goes live in the market.
 Defect free and user friendly.
 Meets the requirements.

2. What is verification?
 It is a discipline approach to evaluate whether software product will full fill the requirement.
 It is done by systematically reading the content of software document with the intension of detecting
defects.
 It is static testing method.
 It helps in find the defect and its location as well.
 It included in all process of SDLC
The standard definition of Verification goes like this: "Are we building the product RIGHT?" i.e.
Verification is a process that makes it sure that the software product is developed the right way. The software
should confirm to its predefined specifications, as the product development goes through different stages, an
analysis is done to ensure that all required specifications are met.
It typically involves reviews and meetings to evaluate documents, plans, code, requirements and specifications;
this can be done with checklists, issues lists, and walk-through and inspection meetings. (Every phase of
Verification is a phase of the Testing Life Cycle)

Manual Testing Notes Page 2

Few terms involved in Verification:
Inspection:
Inspection involves a team of about 3-6 people, led by a leader, which formally reviews the documents
and work product during various phases of the product development life cycle. The work product and related
documents are presented in front of the inspection team, the member of which carry different interpretations
of the presentation. The bugs that are detected during the inspection are communicated to the next level in
order to take care of them.

Walk-Through:
Walk-through can be considered same as inspection without formal preparation (of any presentation or
documentations). During the walk-through meeting, the presenter/author introduces the material to all the
participants in order to make them familiar with it. Even when the walk-throughs can help in finding potential
bugs, they are used for knowledge sharing or communication purpose.

Buddy Checks:
This is the simplest type of review activity used to find out bugs in a work product during the
verification. In buddy check, one person goes through the documents prepared by another person in order to
find out if that person has made mistake(s) i.e. to find out bugs which the author couldn’t find previously.

The activities involved in Verification process are: Requirement Specification verification, Functional design
verification, internal/system design verification and code verification (these phases can also subdivided further).
Each activity makes it sure that the product is developed right way and every requirement, every specification,
design code etc. is verified!

3. What is validation?
 It is a discipline approach to evaluate whether as build software product will behave its intendent use.
 It is done by executing the software product with the intension of finding defects.
 It is Dynamic testing method.
 It helps in find the defect but not its location.

Validation is a process of finding out if the product being built is right?

i.e. whatever the software product is being developed, it should do what the user expects it to do. The software
product should functionally do what it is supposed to, it should satisfy all the functional requirements set by the
user. Validation is done during or at the end of the development process in order to determine whether the
product satisfies specified requirements.
Validation ensures that functionality, as defined in requirements, is the intended behavior of the product;
validation typically involves actual testing and takes place after verifications are completed.

4. What is the Difference between Verification and Validation?

Verification takes place before validation and not vice versa.
Verification evaluates documents, plans, code, requirements and specifications.
Validation evaluates the product itself.
The inputs of verification are check-lists, issues lists, walk-through and inspection meetings, reviews and
meetings.

Manual Testing Notes Page 3

The input of validation is the actual testing of an actual product.
The output of verification is a nearly perfect set of documents, plans, specifications, and requirements
document. The output of validation, on the other hand, is a nearly perfect, actual product.

5. What is difference between QA, QC and Software Testing?

Quality Assurance (QA): QA refers to the planned and systematic way of monitoring the quality of process
which is followed to produce a quality product. QA tracks the outcomes and adjusts the process to meet the
expectation.

Quality Control (QC): Concern with the quality of the product. QC finds the defects and suggests
improvements. The process set by QA is implemented by QC. The QC is the responsibility of the tester.

Software Testing: It is the process of ensuring that product which is developed by the developer meets the user
requirement. The motive to perform testing is to find the bugs and make sure that they get fixed.

6. What is Quality Assurance (QA)?

Quality assurance is the process of verifying or determining whether products or services meet or exceed
customer expectations. Quality assurance is a process-driven approach with specific steps to help define and
attain goals. This process considers design, development, production and service.

7. What is the Difference between Quality Assurance and Quality Control?

QC : Finding the bugs. It measures the quality of the product. It is Product Oriented,
QA : Prevention the bugs, It measures the quality of processes involved in creating a quality product. It is
Process Oriented.
Testing is basically quality control. It's a subset of quality assurance. Quality assurance is policies that make sure
the organization delivers its services to its clients with pre-accepted standards.
8. Distinguish between QA and QC responsibilities
Quality Assurance:
1) A planned and systematic set of activities necessary to provide adequate confidence that requirements are
properly established and products or services confirm to specified requirements.
2) An activity that establishes and evaluates the processes to produces.
3) Helps establish processes.
4) Sets up measurements programs to evaluate processes.
5) Identifies weaknesses in processes and improves them.
6) QA is the responsibility of the entire team.
7) Prevents the introduction of issues or defects
Quality Control: (QC)
Quality control is used in developing systems to ensure products or application meet or exceed customer
requirements.
1) The process by which product quality is compared with applicable standards; and the action taken when non-
conformance is detected.
2) An activity which verifies if the product meets pre-defined standards.
3) Implements the process.
4) Verifies if specific attribute(s) are in a specific product or service.
5) Identifies defects for the primary purpose of correcting defects.
Manual Testing Notes Page 4
6) QC is the responsibility of the tester.
7) Detects, reports and corrects defects

9. What are the entry & Exit criteria in testing?

Testing starts at the requirement phase itself and testing ends after getting sign-off from the client. Till that,
testing continues...

Entry Criteria:
1. All code of application, unit tested.
2. Test plan, Test cases reviewed and approved.
3. QA/Tester gets significant knowledge of application.
4. Test environment / Test ware get prepared.
5. After getting application build.

Exit Criteria:
1. Deadlines (release deadlines, testing deadlines, etc.)
2. All the test cases should be executed. Test cases completed with certain percentage passed
3. Test budget depleted
4. Coverage of code/functionality/requirements reaches at specified point
5. Bug rate falls below a certain level
6. Beta or alpha testing period ends
7. All the planned requirements must be met
8. All the high Priority bugs should be closed
9. Test manager must sign off the release

10. What are the Difference types of testing Type & Techniques?

Testing Types
Testing types refer to difference approaches towards testing a program, system or product. The two
types of testing are Black box testing and White box testing, another type, termed as Gray box testing or
Hybrid testing is evolving presently and it combines the features of the two types.

Testing Techniques
Testing techniques refer to different methods of testing particular features a computer program,
system or product. Each testing type has its own testing techniques while some techniques combine the feature
of both types.

Black box testing techniques:

 Decision table testing.
Manual Testing Notes Page 5
  All-pairs testing.
 Equivalence partitioning.
 Boundary value analysis.
 Cause–effect graph.
 Error guessing.

White box testing techniques:

* Basis Path Testing
* Flow Graph Notation
* Cyclomatic Complexity
* Graph Matrices
* Control Structure Testing
* Loop Testing
11. Boundary value analysis and Equivalence partitioning, explained with simple example: BVA
Boundary value analysis and equivalence partitioning both are test case design strategies in black box
testing.

Equivalence Partitioning: In this method the input domain data is divided into different equivalence data
classes. This method is typically used to reduce the total number of test cases to a finite set of testable test
cases, still covering maximum requirements. In short it is the process of taking all possible test cases and
placing them into classes. One test value is picked from each class while testing.
E.g.: If you are testing for an input box accepting numbers from 1 to 1000 then there is no use in writing
thousand test cases for all 1000 valid input numbers plus other test cases for invalid data.
Using equivalence partitioning method above test cases can be divided into three sets of input data called as
classes. Each test case is a representative of respective class.
So in above example we can divide our test cases into three equivalence classes of some valid and invalid
inputs.
Test cases for input box accepting numbers between 1 and 1000 using Equivalence Partitioning:
1) One input data class with all valid inputs. Pick a single value from range 1 to 1000 as a valid test case. If you
select other values between 1 and 1000 then result is going to be same. So one test case for valid input data
should be sufficient.
2) Input data class with all values below lower limit. I.e. any value below 1, as a invalid input data test case.
3) Input data with any value greater than 1000 to represent third invalid input class.
So using equivalence partitioning you have categorized all possible test cases into three classes. Test cases with
other values from any class should give you the same result.
We have selected one representative from every input class to design our test cases. Test case values are
selected in such a way that largest number of attributes of equivalence class can be exercised.
Equivalence partitioning uses fewest test cases to cover maximum requirements.

Boundary value analysis:

It’s widely recognized that input values at the extreme ends of input domain cause more errors in system. More

Manual Testing Notes Page 6

application errors occur at the boundaries of input domain. ‘Boundary value analysis’ testing technique is used
to identify errors at boundaries rather than finding those exist in center of input domain.
Boundary value analysis is a next part of Equivalence partitioning for designing test cases where test cases are
selected at the edges of the equivalence classes.
Test cases for input box accepting numbers between 1 and 1000 using Boundary value analysis:

1) Test cases with test data exactly as the input boundaries of input domain i.e. values 1 and
1000 in our case.
2) Test data with values just below the extreme edges of input domains i.e. values 0 and 999.
3) Test data with values just above the extreme edges of input domain i.e. values 2 and 1001.

Boundary value analysis is often called as a part of stress and negative testing.
Note: There is no hard-and-fast rule to test only one value from each equivalence class you created for input
domains. You can select multiple valid and invalid values from each equivalence class according to your needs
and previous judgments.
E.g. if you divided 1 to 1000 input values in valid data equivalence class, then you can select test case values
like: 1, 11, 100, 950 etc. Same case for other test cases having invalid data classes.

12. What are the difference types of test case techniques?

Difference types of test case techniques derived from test techniques.
The test case techniques which are used in Software Testing is from Black box, white Box, Incremental and
Thread testing.
1. Equivalent Class Partitioning
2. Boundary Value Analysis
3. Error Guessing or Probability Class Partitioning
4. Decision Table
5. Special Values
6. Error Based
7. I/O Domain
8. Flow Chart

13. What is Error Guessing?

Error guessing is a test case technique to check the application with invalid data, whether it is accepting the
data or not.

14. What is Orthogonal array testing?

Orthogonal Array Testing to my understanding is not exactly a testing type but a technique to reduce the testing

Manual Testing Notes Page 7

effort by reducing the Test cases, identifying the repetition of pairwise combination.

15. What are the risks & risk involved in testing?

A risk is a potential for loss or damage to an Organization from materialized threats. Risk Analysis
attempts to identify all the risks and then quantify the severity of the risks. A threat as we have seen is a
possible damaging event. If it occurs, it exploits vulnerability in the security of a computer based system.
Risks involved testing:-
1. Lack of documents(BRS,SRS, Use Cases)
2. Lack of resources (HW, SW, & Human)
3. Lack of time
4. Lack of domain knowledge
5. Lack of tester on bench

16. What is Requirement Traceability Matrix?

The Requirements Traceability Matrix (RTM) is a tool to make sure that project requirement remain same
throughout the whole development process. RTM is used in the development process because of following
reasons:

• To determine whether the developed project is meet the requirements of the user.
• To determine all the requirements given by the user.
• To make sure the application requirement can be fulfilled in the verification process.

17. What is Test Metrics?

IT is a table which contains different modules to be tested as rows and types of testing techniques to be
conducted as columns. Test Matrix is also called as Test responsibility matrix

A test matrix is simply a spreadsheet that suggests test and captures test results by laying them out in
the form of a table. A test matrix can be used for a number of purposes:

 To record a consistent set of tests;

 To document a desired level of test coverage based on an intersection of two criteria and, when filled
out, to be used as evidence that the desired amount of testing has been done;
 As a quick visual indication of how much testing has been done on those criteria;
 To help to identify and refine the specific environments in which a defect occurs;
 When it is completely filled out, as a checklist to assure that some exhaustive task has been completed.
The objective of Test Metrics is to capture the planned and actual quantities the effort, time and
resources required to complete all the phases of Testing of the SW Project.
Test metrics accomplish in analyzing the current level of maturity in testing and give a projection on how to go
about testing activities by allowing us to set goals and predict future trends.
A Test Metric is a standard means of measuring some attribute of the software testing process. They are
a means of establishing test progress against the test schedule and may be an indicator of expected future
results. Metrics are produced in two forms – Base Metrics and Derived Metrics.

Example of Base Metrics:

Manual Testing Notes Page 8

 # Test Cases
# New Test Cases
# Test Cases Executed
# Test Cases Un-executed
# Test Cases Re-executed
# Passes
# Fails
# Test Cases Under Investigation
# Test Cases Blocked
# 1st Run Fails Test Case Execution Time
# Testers
Example of Derived Metrics:
% Test Cases Complete
% Test Cases Passed
% Test Cases Failed
% Test Cases Blocked
% Test Defects Corrected

18. Why do you go for White box testing, when Black box testing is available?
First of all there are two test design techniques. One is black box and another is white box. These
testing techniques are totally difference from each other. The white box is for unit and Integration and black box
is used for system and user acceptance testing. By combining these total testing of a product or application can
be achieved. So that's why both are necessary because they have significance advantages difference to each
other.

19. List down the important test carried out of security testing of an application?
- SQL Injection
- Password cracking
- URL Manipulation
- Cross site scripting

20. What is Security Testing?

Security testing is one of the most important types of software testing that intended to find the weakness of
the software application. The main objective of security testing is to find the vulnerabilities of system &
determine that its data and resources are protected from possible intruder. Security testing allows us to identify
the confidential data stays confidential or not.

Now a day’s online transaction are rapidly increasing, so security testing on web application is one of the most
important thing to be carried out while testing web applications. The security testing is to be carried out once
the system is developed & installed. To identify the vulnerabilities the network security testing should be
performed periodically.

There are “Seven attributes of Security Testing” as follows, for more details check here:

 Authentication
 Authorization

Manual Testing Notes Page 9

  Confidentiality
 Availability
 Integrity
 Non-repudiation
 Resilience

In the pie-chart below, created by the Web Hacking Incident Database for 2011 (WHID) clearly shows that whilst
many different attack methods exist, SQL injection and XSS are the most popular.

Security Testing Analysis Report

6 basics terms used in Security Testing

Here are the useful terms frequently used in severity testing:

21. Penetration Testing?

Penetration testing is a type of security testing process to identify security weakness /vulnerabilities in an
application by evaluating the system or network with various malicious techniques. The main purpose of this
testing is to protect the identified vulnerabilities & secure the important data from unknown user who do not
have the access to the system like hackers. The penetration testing can be carried out after the cautious
consideration, notification, and planning.

There are two types of penetration testing, White box testing & Black box testing. In White box testing is all

Manual Testing Notes Page 10

information is with tester prior start testing like IP Address, Code & Infrastructure diagram & based on available
information tester will perform the testing. In Black box testing, tester do not has any information of system
under test. This is more accurate testing method as we are simulating the testing with real hackers which they
do not having the information of existing system.

22. What is Password cracking?

Password Cracking - Security Testing
In security testing of a web application Password cracking programs can be used to identify weak passwords. It
can be start using guessing the common username and password or use of password cracking tool. Password
cracking confirms that users are making use of adequately strong passwords.

In the system password are generally stored in the encrypted format like hash, so once the use try to login using
login credentials then hash is created for newly entered password & compared with the original stored hash,
once the stored hash matches then user is authenticated. Automated Password cracking is basically generates
the random hashes unless and until match is not found. The most commonly used password cracking is the use
of Dictionary attack. In this case automated tool is try all words from dictionary.

It would be easier if the password does not asking for complex passwords like password must having at least
one digit one character and one special characters etc. Sometimes the passwords are stored on cookies, if such
login credentials information stored without encryption in cookies then hacker can use different methods to get
the username & password information.

23. What is “Vulnerability”?

The Vulnerability is a weakness in a system under test which may cause the malicious attaches by unauthorized
users. The vulnerability can be increase due to bugs in the software, lacking of Security testing or viruses etc.
These security vulnerabilities require patches, or fixes, in order to prevent the potential for compromised
integrity by hackers or malware.

24. What is “URL manipulation”?

URL Manipulation is very much interesting and most common type of attack by hackers. In this attack the
hackers manipulate the website URL query strings & capture the important information.

This happens when the application uses the HTTP GET method to pass information between the client and the
server. The information is passed in parameters in the query string. The tester can modify a parameter value in
the query string to check if the server accepts it.

Via HTTP GET request user information is passed to server for authentication or fetching data. Attacker can
manipulate every input variable passed from this GET request to server in order to get the required information
or to corrupt the data. In such conditions any unusual behavior by application or web server is the doorway for
the attacker to get into the application.

So while security testing the URL manipulation test cases should be considered to make sure that using URL
manipulation unauthorized user is not able to access the important information or not corrupting the database
records.

25. What is “SQL injection”?

SQL Injection is one of the most common application layer attack techniques used by hackers. SQL Injection is
one of the several web attack mechanisms used by hackers to steal data from organizations. SQL injection
Manual Testing Notes Page 11
attacks are very critical as attacker can get vital information from server database. It is a type of attack which
takes the advantage of loop holes present in implementation of web application that allows hacker to hack the
system like passing sql queries into all input fields and tries to hack the system.

Hackers try to query database with SQL injection statements or part of SQL statement as user input & pull out
the vital information from system or crash the system & from the error displayed on browser can get the
required information what they are looking for.

To check the sql injection we have to take care of the input fields like text boxes, comments etc. The Special
characters should be either properly handled or skipped from the input.

26. Cross Site Scripting (XSS)

Cross-site scripting (also known as XSS or CSS) is a type of computer security vulnerability typically found in web
applications. Cross Site Scripting is one of the most common application layer hacking techniques. Cross Site
Scripting is vulnerability in web application that allows an attacker to inject HTML and JAVASCRIPT code into a
web page. This type of attacks are injecting malicious scripts into victim’ web browsers. These malicious scripts
are used to steal the vital information stored in the cookies.

Types of testing to perform while Security Testing

Let’s discuss what all steps to prepare while preparing and planning for Security testing:

The first step is to understand the business requirement, security goals and objective in terms of security
compliance of the organization. The test planning should consider all security factors like Organization might
have planned to achieve PCI compliance etc.
Understand and analyze the requirements of the application under test.
Collect all system setup information used for development of Software and Network like Operating Systems,
technology, hardware.
Make out the list of Vulnerabilities and Security Risks.
Based on above step prepare Threat profile.
Based on identified Threat, Vulnerabilities and Security Risks prepare test plan to address these issues.
For each identified Threat, Vulnerabilities and Security Risks prepare Traceability Matrix.
All security testing cannot possible to execute manually, so identify the tool to execute the all security test cases
faster & more reliable.
Prepare the Security tests case document.
Perform the Security Test cases execution and retest the defect fixes.
Execute the Regression Test cases.
Prepare detailed report of Security Testing which contains Vulnerabilities and Threats contained, detailing risks,
and still open issues etc.

27. What are the typical problem in web testing?

- Functional problem
- user interface problem

Manual Testing Notes Page 12

- Performance related problem
- Database related problem
- OS compatibility problem
- Browser compatibility problem
- Security problem
- Load related problem
- Navigation problem

[Link] PLAN Fundamentals?

TEST PLAN DEFINITION

A Software Test Plan is a document describing the testing scope and activities. It is the basis for formally testing
any software/product in a project.

ISTQB Definition

 Test Plan: A document describing the scope, approach, resources and schedule of intended test activi-
ties. It identifies amongst others test items, the features to be tested, the testing tasks, who will do
each task, degree of tester independence, the test environment, the test design techniques and entry
and exit criteria to be used, and the rationale for their choice,and any risks requiring contingency plan-
ning. It is a record of the test planning process.

 master test plan: A test plan that typically addresses multiple test levels.

 phase test plan: A test plan that typically addresses one test phase.

TEST PLAN TYPES

One can have the following types of test plans:

 Master Test Plan: A single high-level test plan for a project/product that unifies all other test plans.

 Testing Level Specific Test Plans: Plans for each level of testing.

o Unit Test Plan

o Integration Test Plan

o System Test Plan

o Acceptance Test Plan

 Testing Type Specific Test Plans: Plans for major types of testing like Performance Test Plan and Security
Test Plan.

TEST PLAN TEMPLATE

The format and content of a software test plan vary depending on the processes, standards, and test
management tools being implemented. Nevertheless, the following format, which is based on IEEE standard for
software test documentation, provides a summary of what a test plan can/should contain.

Test Plan Identifier:

Manual Testing Notes Page 13

  Provide a unique identifier for the document. (Adhere to the Configuration Management System if you
have one.)

Introduction:

 Provide an overview of the test plan.

 Specify the goals/objectives.

 Specify any constraints.

References:

 List the related documents, with links to them if available, including the following:

o Project Plan

o Configuration Management Plan

Test Items:

 List the test items (software/products) and their versions.

Features to be Tested:

 List the features of the software/product to be tested.

 Provide references to the Requirements and/or Design specifications of the features to be tested

Features Not to Be Tested:

 List the features of the software/product which will not be tested.

 Specify the reasons these features won’t be tested.

Approach:

 Mention the overall approach to testing.

 Specify the testing levels [if it’s a Master Test Plan], the testing types, and the testing methods
[Manual/Automated; White Box/Black Box/Gray Box]

Item Pass/Fail Criteria:

 Specify the criteria that will be used to determine whether each test item (software/product) has
passed or failed testing.

Suspension Criteria and Resumption Requirements:

 Specify criteria to be used to suspend the testing activity.

 Specify testing activities which must be redone when testing is resumed.

Test Deliverables:

 List test deliverables, and links to them if available, including the following:
Manual Testing Notes Page 14
 o Test Plan (this document itself)

o Test Cases

o Test Scripts

o Defect/Enhancement Logs

o Test Reports

Test Environment:

 Specify the properties of test environment: hardware, software, network etc.

 List any testing or related tools.

Estimate:

 Provide a summary of test estimates (cost or effort) and/or provide a link to the detailed estimation.

Schedule:

 Provide a summary of the schedule, specifying key test milestones, and/or provide a link to the detailed
schedule.

Staffing and Training Needs:

 Specify staffing needs by role and required skills.

 Identify training that is necessary to provide those skills, if not already acquired.

Responsibilities:

 List the responsibilities of each team/role/individual.

Risks:

 List the risks that have been identified.

 Specify the mitigation plan and the contingency plan for each risk.

Assumptions and Dependencies:

 List the assumptions that have been made during the preparation of this plan.

 List the dependencies.

Approvals:

 Specify the names and roles of all persons who must approve the plan.

 Provide space for signatures and dates. (If the document is to be printed.)

Manual Testing Notes Page 15

TEST PLAN GUIDELINES

 Make the plan concise. Avoid redundancy and superfluousness. If you think you do not need a section
that has been mentioned in the template above, go ahead and delete that section in your test plan.

 Be specific. For example, when you specify an operating system as a property of a test environment,
mention the OS Edition/Version as well, not just the OS Name.

 Make use of lists and tables wherever possible. Avoid lengthy paragraphs.

 Have the test plan reviewed a number of times prior to baselining it or sending it for approval. The
quality of your test plan speaks volumes about the quality of the testing you or your team is going to
perform.

 Update the plan as and when necessary. An out-dated and unused document stinks and is worse than
not having the document in the first place.

29. IEEE 829 test plan structure?

IEEE 829-2008, also known as the 829 Standard for Software Test Documentation, is an IEEE standard that
specifies the form of a set of documents for use in defined stages of software testing, each stage potentially
producing its own separate type of document.
1. Test plan identifier
2. Introduction
3. Test items
4. Features to be tested
5. Features not to be tested
6. Approach
7. Item pass/fail criteria
8. Suspension criteria and resumption requirements
9. Test deliverables
10. Testing tasks
11. Environmental needs
12. Responsibilities
13. Staffing and training needs
14. Schedule
15. Risks and contingencies
16. Approvals

30. Software Estimation Techniques - Common Test Estimation Techniques used in SDLC?

In order to successful software project & proper execution of task, the Estimation Techniques plays vital role in
software development life cycle. The technique which is used to calculate the time required to accomplish a
particular task is called Estimation Techniques. To estimate a task different effective Software Estimation Tech-
niques can be used to get the better estimation.

Before moving forward let’s ask some basic questions like What is use of this? or Why this is needed? or Who
will do this? So in this article I am discussing all your queries regarding ESTIMATION.

Manual Testing Notes Page 16

[Link] is Estimation?

“Estimation is the process of finding an estimate, or approximation, which is a value that is usable for some
purpose even if input data may be incomplete, uncertain, or unstable.” [Wiki Definition]

Software Estimation Techniques

The Estimate is prediction or a rough idea to determine how much effort would take to complete a defined
task. Here the effort could be time or cost. An estimate is a forecast or prediction and approximate of what it
would Cost. A rough idea how long a task would take to complete. An estimate is especially an approximate
computation of the probable cost of a piece of work.

The calculation of test estimation techniques is based on:

 Past Data/Past experience

 Available documents/Knowledge

 Assumptions

 Calculated risks

Before starting one common question arises in the testers mind is that “Why do we estimate?” The answer to
this question is pretty simple, it is to avoid the exceeding timescales and overshooting budgets for testing activ-
ities we estimate the task.

Few points need to be considered before estimating testing activities:

 Check if all requirements are finalize or not.

 If it not then how frequently they are going to be changed.

 All responsibilities and dependencies are clear.

 Check if required infrastructure is ready for testing or not.

Manual Testing Notes Page 17

  Check if before estimating task is all assumptions and risks are documented.

32. Software Estimation Techniques

There are different Software Testing Estimation Techniques which can be used for estimating a task.

1) Delphi Technique
2) Work Breakdown Structure (WBS)
3) Three Point Estimation
4) Functional Point Method

1) Delphi Technique:

Delphi technique – This is one of the widely used software testing estimation technique.

In the Delphi Method is based on surveys and basically collects the information from participants who are ex-
perts. In this estimation technique, each task is assigned to each team member & over multiple rounds surveys
are conduct unless & until a final estimation of task is not finalized. In each round the thought about task are
gathered & feedback is provided. By using this method, you can get quantitative and qualitative results.

In overall techniques this technique gives good confidence in the estimation. This technique can be used with
the combination of the other techniques.

2) Work Breakdown Structure (WBS):

A big project is made manageable by first breaking it down into individual components in a hierarchical struc-
ture, known as the Work breakdown structure, or the WBS.

The WBS helps to project manager and the team to create the task scheduling, detailed cost estimation of the
project. By using the WBS motions, the project manager and team will have a pretty good idea whether or
not they’ve captured all the necessary tasks, based on the project requirements, which are going to need to
happen to get the job done.

In this technique the complex project is divided into smaller pieces. The modules are divided into smaller sub-
modules. Each sub-modules are further divided into functionality. And each functionality can be divided into
sub-functionalities. After breakdown the work all functionality should review to check whether each & every
functionality is covered in the WBS.

Using this you can easily figure out the what all task needs to completed & they are breakdown into details task
so estimation to details task would be more easier than estimating overall Complex project at one shot.

Work Breakdown Structure has four key benefits:

 Work Breakdown Structure forces the team to create detailed steps:

In The WBS all steps required to build or deliver the service are divided into detailed task by Project
manager, Team and customer. It helps to raise the critical issues early on, narrow down the scope of the
project and create a dialogue which will help make clear bring out assumptions, ambiguities, narrow
the scope of the project, and raise critical issues early on.

Manual Testing Notes Page 18

  Work Breakdown Structure help to improve the schedule and budget.
WBS enables you to make an effective schedule and good budget plans. As all tasks are already avail-
able so it helps in generating a meaningful schedule and makes scheming a reliable budget easier.

 Work Breakdown Structure creates accountability

The level of details task breakdown helps to assign particular module task to individual, which makes
easier to hold person accountable to complete the task. Also the detailed task in WBS, people cannot
allow hiding under the “cover of broadness.”

 Work Breakdown Structure creation breeds commitment

The process of developing and completing a WBS breed excitement and commitment. Although the
project manager will often develop the high-level WBS, he will seek the participation of his core team
to flesh out the extreme detail of the WBS. This participation will spark involvement in the project.

3) Three Point Estimation:

Three point estimation is the estimation method is based on statistical data. It is very much similar to WBS
technique, tasks are broken down into subtasks & three types of estimation are done on this sub pieces.

Optimistic Estimate (Best case scenario in which nothing goes wrong and all conditions are optimal.) = A

Most Likely Estimate (most likely duration and there may be some problem but most of the things will go right.)
=M

Pessimistic Estimate (worst case scenario which everything goes wrong.) = B

Formula to find Value for Estimate (E) = A + (4*M) + B / 6

Standard Deviation (SD) = = (B – A)/6

Now a days, planning poker and Delphi estimates are most popular testing test estimation techniques.

4) Functional Point Method:

Functional Point is measured from a functional, or user, point of view.

It is independent of computer language, capability, technology or development methodology of the team. It is

based on available documents like SRS, Design etc.

In this FP technique we have to give weightage to each functional point. Prior to start actual estimating tasks
functional points are divided into three groups like Complex, Medium & Simple. Based on similar projects & Or-
ganization standards we have to define estimate per function points.

Total Effort Estimate = Total Function Points * Estimate defined per Functional Point

Manual Testing Notes Page 19

Let’s take a simple example to get clearer:

Weightage Function Points Total

Complex 5 5 25
Medium 3 20 60
Simple 1 35 35

Function Total Points 120

Estimate defined per point 4.15

Total Estimated Effort (Person Hours): 498

Advantages of the Functional Point Method:

 In pre-project stage the estimates can be prepared.

 Based on requirement specification documents the method’s reliability is relatively high.

Disadvantages of Software Estimation Techniques:

 Due to hidden factors can be over or under estimated

 Not really accurate

 It is basd on thinking

 Involved Risk

 May give false result

 Bare to losing

 Sometimes cannot trust in estimate

Software Estimation Techniques Conclusion:

There may be different other methods also which can be effectively used for the project test estimation tech-
niques, in this article we have seen most popular Software Estimation Techniques used in project estimation.
There can’t be a sole hard and fast rule for estimating the testing effort for a project. It is recommended to add
on to the possible knowledge base of test estimation methods and estimation templates constantly revised
based upon new findings.
- See more at: [Link]

Describe how to perform Risk analysis during software testing?

Risk analysis is the process of identifying risk in the application and prioritizing them to test. Following are some
of the risks:

Manual Testing Notes Page 20

1. New Hardware.
2. New Technology.
3. New Automation Tool.
4. Sequence of code delivery.
5. Availability of application test resources.

We prioritize them into three categories these are:

• High magnitude: Impact of the bug on the other functionality of the application.
• Medium: it can be tolerable in the application but not desirable.
• Low: it can be tolerable. This type of risk has no impact on the company business.

33. What is difference between Pilot and Beta testing?

The differences between these two are listed below:

• A beta test when the product is about to release to the end user whereas pilot testing take place in the earlier
phase of the development cycle.
• In beta testing application is given to a few user to make sure that application meet the user requirement and
does not contain any showstopper whereas in case of pilot testing team member give their feedback to
improve the quality of the application.

34. What is Gray Box Testing?

Grey box testing is the hybrid of black box and white box testing. In gray box testing, test engineer has the
knowledge of coding section of the component and designs test cases or test data based on system knowledge.
In this tester has knowledge of code, but this is less than the knowledge of white box testing. Based on this
knowledge the test cases are designed and the software application under test treats as a black box & tester
test the application from outside.

35. What is Integration Testing?

Integration testing is black box testing. Integration testing focuses on the interfaces between units, to ensure
that units work together to complete a specify task. The purpose of integration testing is to confirm that
different components of the application interact with each other. Test cases are developed with the purpose of
exercising the interfaces between the components. Integration testing is considered complete, when actual
results and expected results are same. Integration testing is done after unit testing. There are mainly three
approaches to do integration testing:

• Top-down Approach tests the components by integrating from top to bottom.

• Bottom-up approach It takes place from the bottom of the control flow to the higher level components
• Big bang approach In this are different module are joined together to form a complete system and then
testing is performed on it.

36. What is Scalability Testing?

Scalability testing is testing performed in order to enhanced and improve the functional and performance
capabilities of the application. So that, application can meets requirements of the end users. The scalability
measurements is done by doing the evaluating the application performance in load and stress conditions. Now
depending upon this evaluation we improve and enhanced the capabilities of the application.

Manual Testing Notes Page 21

37. What is Software Requirements Specification?

• A software requirements specification is a document which acts as a contract between the customer and the
supplier.
• This SRS contain all the requirement of the end user regarding that application. SRS can be used as a
communication medium between the customer and the supplier.
• The developer and tester prepare and examine the application based on the requirements written in the SRS
document.
• The SRS documented is prepared by the Business Analyst by taking all the requirements for the customer.

38. What is Storage Testing?

In Storage Testing we test those functionalities of the application which is responsible for storing the data into
database. The data entered by the end user in GUI or front end, is the same data which is stored in the
database. The storage testing determines that the data taken from the front end of the application is stored in
correct place and in correct manner in the database.

39. What is Stress Testing?

Stress testing tests the software with a motive to check that the application do not crashes if we increase the
stress on the application by increasing the large number of user working on the application. We can also apply
the stress on the application firing the lots of process which cannot be handled by the application. We perform
the stress testing on the application evaluate the application capabilities at or beyond the limits of its specified
requirements to determine. Generally, this is a type of performance testing performed in a very high level of
load and stress condition.

40. What is Test Harness?

A test harness is a collection of software and test data required to test the application by running it in different
testing condition like stress, load, data- driven, and monitoring its behavior and outputs. Test Harness contains
two main parts:

• Test execution engine

• Test script repository

Automation testing is the use of a tool to control the execution of tests and compare the actual results with the
expected results. It also involves the setting up of test pre-conditions.

41. Can you define test driver and test stub?

Types of integration testing:
1. Top down
2. Bottom up
Top down:
Testing hierarchy starts from higher level to lower level. If suppose testers don't get the lower modules for
testing (consider the lower modules are under development) what the testers will do they will place dummy
modules and integrate these dummy modules with the higher level modules. In top down approach the dummy
modules r called Stubs.

Manual Testing Notes Page 22

Stubs: Stubs are the dummy modules that simulate the low level modules.
Bottom up: In this the dummy modules are called drivers.
Drivers: drivers are the dummy modules that simulate the high level modules.

We need test stub and test driver because of following reason:

• Suppose we want to test the interface between modules A and B and we have developed only module A. So
we cannot test module A but if a dummy module is prepare, using that we can test module A.
• Now module B cannot send or receive data from module A directly so, in these cases we have to transfer data
from one module to another module by some external features. This external feature used is called Driver.

42. What makes a good QA or Test manager?

A good QA or Test manager should have following characteristics:

• Knowledge about Software development process

• Improve the teamwork to increase productivity
• Improve cooperation between software, test, and QA engineers
• To improvements the QA processes.
• Communication skills.
• Able to conduct meetings and keep them focused

43. What is Fuzz testing, backward compatibility testing and assertion testing?

Fuzz Testing: testing application by entering invalid, unexpected, or random data to the application this testing
is performed to ensure that application is not crashing when entering incorrect and unformatted data.

Backward Compatibility Testing: Testing method which examines performance of latest software with older
versions of the test environment.
Assertion Testing: Type of testing consisting in verifying if the conditions confirm the product requirements.

44. What is Baseline document, Can you say any two?

Documents that are approved by the client and will not have any more changes are baseline docs. Service Level
Agreement (SLA), Business Requirement Docs(BRD)

45. After completing testing, what would you deliver to the client?
After completion of testing we will give client to user manual and product, Test Trace-ability Matrix Test Plan
Testing Strategy, Test Cases, Test Scenarios, Test Scripts, Test Data, Test Results, Test Summary Report, and
Release Notes Tested Build.

46. What is a Test Bed?

Test bed is the environment where the testing is supposed to be done. Setting up the hardware and software
requirements before starting testing is known as test Bed.
An execution environment configured for testing. May consist of specific hardware OS network topology
configuration of the product under test other application or system software etc. The Test Plan for a project
should enumerated the test beds(s) to be used.

Manual Testing Notes Page 23

47. Why do you go for Test Bed?
Expected results are predefined in test bed.
The requirements needed for the testing like
Software needed for testing (Like O.S, Browser. etc)
Hardware needed for testing
Network needed for testing
Test Bed means:
 The Testing Life cycle
 Re-usable Tests
 Test Harnesses
 Equipment
 Automation tools
 Test databases
 Configuration control
 Regression testing
 Data conversions

48. What is Severity and Priority and who will decide what?
1. Severity is the complexity of the bug and its impact on the application.
2. Priority is how immediately the bug needs to be fixed.
3. Severity means how severe the bug is? And priority means which bug should be given resolved. Severity is
decided by testing team and priority is decided by development team.

49. What is a test case?

Test cases are a sequence of steps to test the correct behavior, functionality/feature of an application. A
test case should have an input description, Test Sequence and an Expected Behavior.
A test case in software engineering is a set of conditions or variables under which a tester will
determine whether an application or software system is working correctly or not. The mechanism for
determining whether a software program passed or failed such a test is known as a test oracle. In some settings
an oracle could be a requirement or use case. It may take many test cases to determine that a software
program or system is functioning correctly. Test cases are often referred to as test scripts, particularly when
written. Written test cases are usually collected into test suites.
A test case is usually a single step, or occasionally a sequence of steps, to test the correct
behavior/functionalities, features of an application. An expected result or expected outcome is usually given.
Additional information that may be included:

Manual Testing Notes Page 24

  Test case ID
 Test case description
 Test step or order of execution number
 Related requirement(s)
 Depth
 Test category
 Author
 Check boxes for whether the test is automate and have been automated.

Additional fields that may be included and completed when the tests are executed:
 pass/fail
 remarks
Larger test cases may also contain prerequisite states or steps, and descriptions. A written test case should also
contain a place for the actual result. These steps can be stored in a word processor document, spreadsheet,
database or other common repository.
In a database system, you may also be able to see past test results and who generated the results and the
system configuration used to generate those results. These past results would usually be stored in a separate
table.
Test suites often also contain
 Test summary
 Configuration
Besides a description of the functionality to be tested, and the preparation required to ensure that the test can
be conducted, the most time consuming part in the test case is creating the tests and modifying them when the
system changes.
50. What is a test condition?
Breaking the functionality into sublime parts and analyzing each part and deriving conditions to test it
can be called as a test condition.
In some instances a condition can have multiple scenarios. In some a condition can be a subset of a scenario.
Ranking is based on the seriousness of the feature to be tested and it's impact on the overall functionality.

51. What is the test script?

A test script in software testing is a set of instructions that will be performed on the system under test to test
that the system functions as expected. These steps can be executed manually or automatically.
There are various means for executing test scripts.
 Manually
 Automated
A test script is a short program written in a programming language used to test part of the functionality of a

Manual Testing Notes Page 25

software system. A written set of steps that should be performed automatically can also be called a test script;
however this is more correctly called a test case.

52. What is the test data?

Test Data are data which have been specifically identified for use in tests, typically of a computer
program. Some data may be used in a confirmatory way, typically to verify that a given set of input to a given
function produces some expected result. Other data may be used in order to challenge the ability of the
program to respond to unusual, extreme, exceptional, or unexpected input. Test data may be produced in a
focused or systematic way (as is typically the case in domain testing), or by using other, less-focused approaches
(as is typically the case in high-volume randomized automated tests). Test data may be produced by the tester,
or by a program or function that aids the tester. Test data may be recorded for re-use, or used once and then
forgotten.

53. What is an Inconsistent bug?

The inconsistent bug is a bug which is not appearing during the retesting process. That means it may appear or
may not appear. This is very difficult to reproduce. Which is not reproducible always?

54. What is the Difference between Re-testing and Regression testing?

Regression Test: It is a process of checking that any changed module introduce new error in unchanged
module or not. We will test all the modules ones we make any change in the application. Just make sure
whether the added functionality have been affected the existing functionalist or not.
Re-Testing: Where as in Retesting we will test only particular module in which you made changes.

55. What are the various levels of testing?

There are two levels of testing:

1. Static Testing: Static testing typically reviews and meetings to evaluate the documents, plans, code,
requirements and specification.

2. Dynamic Testing:
 Unit Testing: To test a single program, basic component, module, or unit of code.
 Integration Testing: To test related programs, modules or units of code are interfaced properly or not
validates that multiple parts of the system interact according to the system design.
 System Testing: To test an entire computer system with respect to functionality & performance.
 User Acceptance Testing: The end user tests the application to check whether it is as per customers
requirements or not.

56. Difference Test bed and Test Environment?

Test bed is the environment where the testing is supposed to be done. Setting up the hardware and software
requirements before starting testing is known as testbed.
In this test environment, we can test hardware, operating systems, or applications designed to run together

Manual Testing Notes Page 26

before introducing them into your production environment.
Test Harness = Test Bad + Test Environment
Test Environment: It means that the surroundings in which we execute tests. This environment contains
hardware components and the software environment in which we executes tests as well as any other software
with which test interacts during testing. Here hardware environment means size of the ram, Processor speed,
and other things like this.
Test Bed: Test bed refers to the environment configured for testing.
This environment may contain specific hardware, operating system, network topology and any other
application which is under the environment configured for testing. When we develop a test plan then we
mention the test bed in details. So it will be not difficult for a software tester to choose the environment to
execute test cases. In test bed, we configure the environment for running test. As we configure environment,
then it means that we select the hardware and software according to our requirements or you can say
according to our wish. This is the Difference between test bed and test environment. However they are very
much similar to each other.

Test harness or Automated Test Framework

Test harness or automated test framework is a collection of software and test data configured to test a
program unit by running it under varying conditions and monitoring its behavior and outputs. It has two main
parts: the Test execution engine and the Test script repository.
Test harnesses allow for the automation of tests. They can call functions with supplied parameters and print out
and compare the results to the desired value. The test harness is a hook to the developed code, which can be
tested using an automation framework.
A test harness should allow specific tests to run (this helps in optimizing), orchestrate a runtime environment,
and provide a capability to analyses results.
The typical objectives of a test harness are to:
 Automate the testing process.
 Execute test suites of test cases.
 Generate associated test reports.
A test harness may provide some of the following benefits:
 Increased productivity due to automation of the testing process.
 Increased probability that regression testing will occur.
 Increased quality of software components and application.

57. What is the difference between Error, Defect, Fault, Bug, Failure?
 Error : Programmatically mistake leads to error. A discrepancy (An event that departs from
expectations) between a computed, observed or measured value or condition and the true, specified,
or theoretically correct value or condition. See: anomaly, bug, defect, exception, and fault.
 Defect: Mismatch between the requirements. Problem in algorithm leads to failure. Variance between
Expected and Actual Result.
 Fault: An incorrect step, process or data definition in a computer program which causes the program to
perform in an unintended or unanticipated manner. See: bug, defect, error, exception.

Manual Testing Notes Page 27

  Bug: Deviation from the expected result. A fault in a program which causes the program to perform in
an unintended or unanticipated manner. See: anomaly, defect, error, exception, fault.
 Failure: Result of any of the above. The inability of a system or component to perform its required
functions within specified performance requirements. See: bug, crash, exception, fault.
And in ability of a system to perform the Functionality according to its Requirements.

57. What is the difference between White & Black Box Testing?
Black box testing also called as Functional testing or Data driven testing or closed box testing or behavioral
testing. Tester views the program as a black box. Tester is completely unconcerned about the internal behavior
or structure of the program.
White box testing also called as Logic driven testing or structured testing or Glass box testing. Tester is
permitted to examine the internal structure of the program. It is internal view of the software or project.

58. What is the difference between Testing and debugging?

Debugging is mainly done by programmer means initially programmer checks the code once again
before running the code but testing means once programmer sent to production team there they tested the
code based on client requirements but initially the programmer also done some primary testing that called as
unit testing.
Debugging done in the development phase by the developers but testing is conducted by the testers in testing
phase.
In development phase developer fixes the bug (i.e.) called debugging but in testing phase tester will finds the
bug (i.e) called testing to improve the quality of the product.

59. What is the Difference between bug and defect?

Bug: Which is found before application goes into production (release).
Defect: Which is found after application goes into production (release).
Bug is nothing but found in RUN TIME but Defect is nothing but found in application.

60. What is the difference between functional spec. and Business requirement specification?
BRS: BRS contains the basic requirements of customer that are to be developed as software project cost,
schedule, target dates.
SRS: SRS is implemented form of BRS. SRS is often referred as parent document of project management
document such as design specifications statements of works software architecture specifications testing and
validation plans and documentation plans. The basic issues of SRS is what is the functionality (what is the s/w
supposed to do) what are the external interfaces (how does the software interact with the user other hardware
and other system software) performance (What is the speed of application recovery time response time
availability of various software functions) attributes (what is the portability security correctness etc) design
constraints (OS environments implementation of languages database integrity and resource limits)
SRS contains the functional and non functional requirements only.

Manual Testing Notes Page 28

61. What is the difference between unit testing and integration testing?
Unit Testing: In computer programming, unit testing is a procedure used to validate that individual units
of source code are working properly. A unit is the smallest testable part of an application.
Integration Testing: Integration Testing is the phase of software testing in which individual software
modules are combined and tested as a group and verify proper communication between the modules and
assure that there no problem in interaction and interface in between of the modules.
Interface Testing: Interface Testing is not focused on what the components are doing but on how they
communicate with each other, as specified in the "System Design". The tests are organized to check all the
interfaces, until all the components have been built and interfaced to each other producing the whole system

62. What is the difference between Volume, Load & Stress?

Load Testing: To check the performance of an application based on increasing no. of users. In this testing an
application tested with maximum no. of users and resources. Load testing is used to check the application's
performance when it is accessed simultaneously by various users
Stress Testing : In software testing, stress test refers to tests that put a greater emphasis on robustness,
availability, and error handling under a heavy load, rather than on what would be considered correct behavior
under normal circumstances. In particular, the goals of such tests may be to ensure the software doesn't crash
in conditions of insufficient computational resources (such as memory or disk space), unusually high
concurrency, or denial of service attacks.
In other words, stress testing helps find out the level of robustness and consistent or satisfactory performance
even when the limits for normal operation for the system (software/hardware) is crossed.
In it Testing an application with more than maximum no. of users and less resources. Stress testing is a
form of testing that is used to determine the stability of a given system or entity. It involves testing beyond
normal operational capacity, often to a breaking point, in order to observe the results. Stress testing may have a
more specific meaning in certain industries.
Performance Testing : To check whether our application is giving response within the expected time or not.
Volume Testing : Testing the build under huze volume of data.

63. What is the difference between Two Tier & Three tier Architecture?
Two tier architecture is client server and three tier architecture is web based application.
Two Tier Architecture: It is nothing but client server Architecture, where client will hit request directly to server
and client will get response directly from server.

Three tier Architecture: It is nothing but Web Based application, here in between client and server middle ware
will be there, if client hits a request it will go to the middle ware and middle ware will send to server and vise-
versa.

64. What is the Difference between Client Server & Web Based Testing?
Client server application is 2 tier applications and web application is n tier application.

Manual Testing Notes Page 29

Client server is the single user application and the web application is the multi User application.

Client server Technology:

1. Number of clients is predicted or known.
2. Client and server are the entities to be tested.
3. Both server and client locations are fixed and known to the user.
4. Server to server interaction is prohibited.
5. Low multimedia type of data transaction.
6. Designed and implemented on intranet environment.
7. Application is loaded at the server. In every client machine an exe is loaded to call this
application.

Web based Technology

1. Number of clients is difficult to predict (millions of clients).
2. Client Server and network are the entities to be tested.
3. Server location is certain client locations are not certain.
4. Server to server interaction is normal.
5. Rich multimedia type of data transaction..
6. Designed and implemented on Internet environment.
7. Application is loaded at the server but No exe is installed at the client machine. We have to
call the application through browser.

65. What is the difference between Integration & System Testing?

Integration testing is performed to test the interaction of 2 or more modules. System testing is a
complete end to end test approach which is used to test real-life cases.

66. What is the Difference between Code Walk through & Code Review?
Walk-through is usually performed by "following" the code. The author should explain what the code is
supposed to do from line to line, procedure call to procedure call etc. etc.
Code Walkthrough: A formal testing technique where source code is traced by a group with a small set of test
cases while the state of program variables is manually monitored to analyze the programmer's logic and
assumptions.
Code Review: A meeting at which software code is presented to project personnel managers users customers
or other interested parties for comment or approval.
Inspections and reviews are basically the same, i.e. you have a meeting where people give their remarks of the
code that they have gathered when they were reading it through (before the meeting). You can compare this to
a review of any kind of document.
At our company reviews are more formal and must be documented in a review record. Inspections might be
less formal and not documented.
In our development process we demand code reviews for all software components.

67. What is the Difference between walk through and inspection?

Walk through is an informal meeting for evaluation. No preparation is required

Manual Testing Notes Page 30

Inspection is a method that deserves careful consideration by an organization concerned with the quality of the
product. It is conducted by quality control members.

68. What is the Difference between SIT & IST?

System Integration Testing is a testing process that shakes down source code developed and fixes any variance
before proceeding to the next testing phase. To complete (or exit) SIT there must be fewer variances than can
be tolerated.
SIT is similar to Unit Test
Interconnect Stress Test (IST) is an accelerated stress test method used to evaluate the integrity of the Printed
Circuit Board (PCB) interconnect structure. It's an objective test whose results are timely repeatable
reproducible and unique.
Systems integration testing mainly deals with testing how integration of various modules work. You check if very
module is working as per its spec after integration. You also check that functionality that require modules to
interact with each other.

Under System testing you will do, functionality test, load/stress test, performance test, compatibility test etc

69. What is the Difference between static and dynamic Testing?

1: Static testing is about prevention, dynamic testing is about cure.
2: The static tools offer greater marginal benefits.
3: Static testing is many times more cost-effective than dynamic testing.
4: Static testing beats dynamic testing by a wide margin.
5: Static testing is more effective!
6: Static testing gives you comprehensive diagnostics for your code.
7: Static testing achieves 100% statement coverage in a relatively short time, while dynamic testing
often achieves less than 50% statement coverage, because dynamic testing finds bugs only in parts
of the code that are actually executed.

8: Dynamic testing usually takes longer than static testing. Dynamic testing may involve running
several test cases, each of which may take longer than compilation.

9: Dynamic testing finds fewer bugs than static testing.

10: Static testing can be done before compilation, while dynamic testing can take place only after
compilation and linking.

11: Static testing can find all of the followings that dynamic testing cannot find: syntax errors, code
that is hard to maintain, code that is hard to test, code that does not conform to coding standards,
and ANSI violations.

70. What is the Difference between alpha testing and beta testing?
Alpha Testing: Testing a software product which is not the final version. This software does not have to
necessarily contain the full functionality required for an application however core functionality to accept input
and generate output is required.

Manual Testing Notes Page 31

 Beta Testing: Beta Testing is last stage of testing where a product is sent outside the company or offer
the product for free trial download.

71. What are the Minimum requirements to start testing?

 Build project
 Test Cases
 Text environment
72. What is Smoke Testing?
Smoke testing is test whether the build is installed properly or not and is ready for further major testing.

73. What is Sanity Testing?

Sanity testing is carried after smoke testing to check whether the major functionality is working properly or not
to proceed further testing.

74. What is Smoke Testing & when it will be done?

Smoke Testing: Testing the application to know whether the application is eligible to test is called
smoke testing. It means there should some piece of code should be working for the testers to test and proceed
further. This testing is done many times to check does the application meet acceptance criteria to start testing.
Ex: There might be a case "dll not found error" seen when you launch the application after installing. What
testing can you do when you cannot launch the application?
Sanity test is called as Test Acceptance test and it will be done to check whether the application coming for
testing is full filling basic functionality which it supposed to have.
Smoke test is conducted after sanity test the purpose is whether there is any danger or smoke if we accept the
application for test. Sanity test is done in Positive perception and smoke is done in terms of negative
perception.

75. What is Ad hoc Testing? When it can be done?

Ad-hoc testing doesn't have proper plan, probably it may carried out at the end of testing where all the
test cases are executed. The main aim is to check the application randomly.
It is mostly done when the application has lesser delivery time.
76. What is security testing?
The Process to determine that an Information System protects data and maintains functionality as intended.
The six basic security concepts that need to be covered by security testing are: confidentiality, integrity,
authentication, authorization, availability and non-repudiation.

 Confidentiality
 Integrity
 Authentication
 Authorization

Manual Testing Notes Page 32

  Availability
 Non-repudiation

77. What is database testing?

Data base testing basically include the following.
1. Data validity testing
2. Data Integrity testing
3. Performance related to database
4. Testing of Procedure, triggers and functions

78. How do you go about testing a project? You test

It’s clear that for testing any application, one should be clear about the requirements and specification
documents. For testing Web application, the tester should know what the web application deals with. For
Testing Web application, the test cases written should be in two different types,
1) The Test cases related to the Look and Feel of the Web pages and navigation and
2) The test cases related to the functionality of the web application. Make sure, whether the web
application is connected to the Database for the inputs. Write Test cases based on the Database and
write test cases for the back-end testing as well if there is any database. The web application should be
tested for the server response time for displaying the web pages, Make sure the web pages under load
as well. For load testing, the tools are very much useful for simulating the many users.

79. What is the Initial Stage of testing?

The initial stage of testing starts with the study phase..i.e.
1. Understanding the scope of the project. In this phase you clear your assumptions and questions with
developer. This is very important.
Note: Not only the project knowledge but the other 3rd party products involved (for ex. your product may
interact with MS Share point or exchange Server so that knowledge is also necessary).
[Link] understanding the scope of the project you need to write test Plan.
3. In parallel develop Test outline → Test scenarios → Test cases.
[Link] the Test Plan and Test Cases (Peer review) and do the rework if any.
5. Freeze the Test Plan and Test Cases. If you have any repository like TD or QC then upload your Test Cases.
6. Map your Test Cases with Requirements you already fed in the repository.
7. Prepare the Test Environment Setup and Data Setup.
8. Prepare your documents need from testing like Trackers,etc..,
9. Start Testing.

Manual Testing Notes Page 33

80. Why do we prepare test condition, test cases, test script (Before Starting Testing)?
1. These are test design document which are used to execute actual testing, without these document it is
impossible to test. So finally testing is done to find the bugs to be fixed.
2. Test case, Test script and test condition are prepared in order to trace the requirement with respect to SRS.

81. What are the things, you prefer & Prepare before starting Testing?
Before start the testing i prepared following documents
1. Test plan
2. Test cases
3. Build
4. Environment set up like hardware configuration, software configuration
5. Resources are ready
6. Unit test is completed (white box testing)

82. What is Incremental Integration Testing?

Incremental Integration testing is the testing of the application by adding new functionalities to an
application. It is a continuous testing activity in which the application is tested by adding new functionalities.
This type of testing is performed by programmer, software engineer, test engineers.

83. What is meant by System Testing?

System testing is performed on the entire system in the context of a Functional Requirement
Specification(s) (FRS) and/or a System Requirement Specification (SRS). System testing is an investigatory testing
phase, where the focus is to have almost a destructive attitude [citation needed] and tests not only the design,
but also the behavior and even the believed expectations of the customer. It is also intended to test up to and
beyond the bounds defined in the software/hardware requirements specification(s). System testing includes the
Load testing and Stress testing. Once the Load testing and Stress testing is completed successfully, the next level
of Alpha Testing or beta Testing will go ahead.
The following examples are different types of testing that should be considered during System testing:
 GUI software testing
 Usability testing
 Performance testing
 Compatibility testing
 Error handling testing
 Load testing
 Volume testing
 Stress testing

Manual Testing Notes Page 34

  User help testing
 Security testing
 Scalability testing
 Capacity testing
 Sanity testing
 Smoke testing
 Exploratory testing
 Ad hoc testing
 Regression testing
 Reliability testing
 Recovery testing
 Installation testing
 Idempotency testing
 Maintenance testing
 Accessibility testing

84. What is the difference between Test life cycle and Bug life cycle?
Test life cycle is complete life cycle in testing. i.e. Test planning execution defect raising and fixing. Typically
includes all type of tests.

Test Life Cycle: TLC

1. Prepare the test strategy.
2. Prepare the test plan.
3. Prepare the test cases.
4. Execute the test cases.
5. Analyze the result.
6. Do the regression testing.
7. Submit the bug free build (application).

Defect Life Cycle: DLC

1. If the bug is new then open it.
2. Assign it to developer.
3. Retest it.
4. If still have not resolved reassign it.
5. Retest it.
6. after resolving close it.

Manual Testing Notes Page 35

TEST PLAN Fundamentals

TEST PLAN DEFINITION

A Software Test Plan is a document describing the testing scope and activities. It is the basis for formally testing
any software/product in a project.

ISTQB Definition

Test Plan: A document describing the scope, approach, resources and schedule of intended test activities. It
identifies amongst others test items, the features to be tested, the testing tasks, who will do each task, degree
of tester independence, the test environment, the test design techniques and entry and exit criteria to be used,
and the rationale for their choice, and any risks requiring contingency planning. It is a record of the test
planning process.

Master test plan: A test plan that typically addresses multiple test levels.

Phase test plan: A test plan that typically addresses one test phase.

TEST PLAN TYPES

One can have the following types of test plans:

Master Test Plan: A single high-level test plan for a project/product that unifies all other test plans.

 Testing Level Specific Test Plans: Plans for each level of testing.

o Unit Test Plan

o Integration Test Plan

o System Test Plan

o Acceptance Test Plan

 Testing Type Specific Test Plans: Plans for major types of testing like Performance Test Plan and Security
Test Plan.

TEST PLAN TEMPLATE

The format and content of a software test plan vary depending on the processes, standards, and test
management tools being implemented. Nevertheless, the following format, which is based on IEEE standard for
software test documentation, provides a summary of what a test plan can/should contain.

Test Plan Identifier:

 Provide a unique identifier for the document. (Adhere to the Configuration Management System if you
have one.)

Manual Testing Notes Page 36

Introduction:

 Provide an overview of the test plan.

 Specify the goals/objectives.

 Specify any constraints.

References:

 List the related documents, with links to them if available, including the following:

o Project Plan

o Configuration Management Plan

Test Items:

 List the test items (software/products) and their versions.

Features to be Tested:

 List the features of the software/product to be tested.

 Provide references to the Requirements and/or Design specifications of the features to be tested

Features Not to Be Tested:

 List the features of the software/product which will not be tested.

 Specify the reasons these features won’t be tested.

Approach:

 Mention the overall approach to testing.

 Specify the testing levels [if it’s a Master Test Plan], the testing types, and the testing methods
[Manual/Automated; White Box/Black Box/Gray Box]

Item Pass/Fail Criteria:

 Specify the criteria that will be used to determine whether each test item (software/product) has
passed or failed testing.

Suspension Criteria and Resumption Requirements:

 Specify criteria to be used to suspend the testing activity.

 Specify testing activities which must be redone when testing is resumed.

Test Deliverables:

 List test deliverables, and links to them if available, including the following:

o Test Plan (this document itself)

Manual Testing Notes Page 37

 o Test Cases

o Test Scripts

o Defect/Enhancement Logs

o Test Reports

Test Environment:

 Specify the properties of test environment: hardware, software, network etc.

 List any testing or related tools.

Estimate:

 Provide a summary of test estimates (cost or effort) and/or provide a link to the detailed estimation.

Schedule:

 Provide a summary of the schedule, specifying key test milestones, and/or provide a link to the detailed
schedule.

Staffing and Training Needs:

 Specify staffing needs by role and required skills.

 Identify training that is necessary to provide those skills, if not already acquired.

Responsibilities:

 List the responsibilities of each team/role/individual.

Risks:

 List the risks that have been identified.

 Specify the mitigation plan and the contingency plan for each risk.

Assumptions and Dependencies:

 List the assumptions that have been made during the preparation of this plan.

 List the dependencies.

Approvals:

 Specify the names and roles of all persons who must approve the plan.

 Provide space for signatures and dates. (If the document is to be printed.)

Manual Testing Notes Page 38

85. What is difference between Master Test Plan and Test Plan.

The differences between Master Plan and Test Plan are given below:

• Master Test Plan contains all the testing and risk involved area of the application where as Test case document
contains test cases.
• Master Test plan contain all the details of each and every individual tests to be run during the overall
development of application whereas test plan describe the scope, approach, resources and schedule of
performing test.
• Master Test plan contain the description of every tests that is going to be performed on the application
whereas test plan only contain the description of few test cases. during the testing cycle like Unit test, System
test, beta test etc
• Master Test Plan is created for all large projects but when it is created for the small project then we called it
as test plan.

86. What is Testing life cycle? tlc

Life Cycle of Testing Process

1. Requirement Stage
2. Test Plan
3. Test Design
4. Design Review
5. Code Review
6. Test Cases Preparation
7. Test Execution
8. Test Report
9. Bug Reporting
10. Reworking on patches
11. Release to production

1. Requirements Stage
Normally in many companies, developers itself take part in the requirements stage. Especially for
product-based companies, a tester should also be involved in this stage. Since a tester thinks from the user side
whereas a developer can’t. A separate panel should be formed for each module comprising a developer, a
tester and a user. Panel meetings should be scheduled in order to gather everyone’s view. All the requirements
should be documented properly for further use and this document is called “Software Requirements
Specifications”.

2. Test Plan
Without a good plan, no work is a success. A successful work always contains a good plan. The testing
process of software should also require good plan. Test plan document is the most important document that

Manual Testing Notes Page 39

brings in a process – oriented approach. A test plan document should be prepared after the requirements of
the project are confirmed. The test plan document must consist of the following information:
• Total number of features to be tested.
• Testing approaches to be followed.
• The testing methodologies.
• Number of man-hours required.
• Resources required for the whole testing process.
• The testing tools that are to be used.
• The test cases, etc

3. Test Design
Test Design is done based on the requirements of the project. Test has to be designed based on
whether manual or automated testing is done. For automation testing, the different paths for testing are to be
identified first. An end to end checklist has to be prepared covering all the features of the project.

The test design is represented pictographically. The test design involves various stages. These stages can be
summarized as follows:

• The different modules of the software are identified first.

• Next, the paths connecting all the modules are identified.

Then the design is drawn. The test design is the most critical one, which decides the test case preparation. So
the test design assesses the quality of testing process.

4. Test Cases Preparation

Test cases should be prepared based on the following scenarios:

• Positive scenarios
• Negative scenarios
• Boundary conditions and
• Real World scenarios
5. Design Reviews

The software design is done in systematical manner or using the UML language. The tester can do the
reviews over the design and can suggest the ideas and the modifications needed.

6. Code Reviews
Code reviews are similar to unit testing. Once the code is ready for release, the tester should be ready
to do unit testing for the code. He must be ready with his own unit test cases. Though a developer does the unit
testing, a tester must also do it. The developers may oversee some of the minute mistakes in the code, which a
tester may find out.

Manual Testing Notes Page 40

7. Test Execution and Bugs Reporting
Once the unit testing is completed and the code is released to QA, the functional testing is done. A top-
level testing is done at the beginning of the testing to find out the top-level failures. If any top-level failures
occur, the bugs should be reported to the developer immediately to get the required workaround.

The test reports should be documented properly and the bugs have to be reported to the developer after the
testing is completed.

8. Release to Production
Once the bugs are fixed, another release is given to the QA with the modified changes. Regression
testing is executed. Once the QA assures the software, the software is released to production. Before releasing
to production, another round of top-level testing is done.

The testing process is an iterative process. Once the bugs are fixed, the testing has to be done repeatedly. Thus
the testing process is an unending process.

87. What is Grey box testing?

Testing Types - System Knowledge

Grey box testing is the combination of black box and white box testing. Intention of this testing is to find
out defects related to bad design or bad implementation of the system.
In gray box testing, test engineer is equipped with the knowledge of system and designs test cases or test data
based on system knowledge.
For example, consider a hypothetical case wherein you have to test a web application. Functionality of this web
application is very simple, you just need to enter your personal details like email and field of interest on the
web form and submit this form. Server will get these details, and based on the field of interest pick some
articles and mail it to the given email. Email validation is happening at the client side using Java Scripts.
In this case, in the absence of implementation detail, you might test web form with valid/invalid mail IDs and
different field of interests to make sure that functionality is intact.

But, if you know the implementation detail, you know that system is making following assumptions
 Server will never get invalid mail ID
 Server will never send mail to invalid ID
 Server will never receive failure notification for this mail.

So as part of gray box testing, in the above example you will have a test case on clients where Java Scripts are
disabled. It could happen due to any reason and if it happens, validation can not happen at the client site. In
this case, assumptions made by the system are violated and
 Server will get invalid mail ID
 Server will send mail to invalid mail ID
 Server will receive failure notification

Manual Testing Notes Page 41

Hope you understood the concept of gray box testing and how it can be used to create different test cases or
data points based on the implementation details of the system.

88. What is V-Model ? vm

The V Model (or VEE model) is a systems development model designed to simplify the understanding of
the complexity associated with developing systems. In systems engineering it is used to define a uniform
procedure for product or project development.
The V-model is a software development model which can be presumed to be the extension of the
waterfall model. Instead of moving down in a linear way, the process steps are bent upwards after the coding
phase, to form the typical V shape. The V-Model demonstrates the relationships between each phase of the
development life cycle and its associated phase of testing

Manual Testing Notes Page 42

89. HOW TO WRITE THE SCENARIO FOR ATM MACHINE AND COFFEE MACHINE ? URGENT

[Link] verify ATM card Insertion

[Link] verify ATM card Insertion in wrong angle
[Link] verify invalid ATM card Insertion
[Link] verify Language selection
[Link] verify Pin entry
[Link] verify invalid Pin entry
[Link] verify invalid Pin entry 3 times
[Link] verify Account Type selection
[Link] verify Invalid Account Type selection with respective to inserted card
[Link] withdrawal option selection
[Link] Amount entry
[Link] Amount entry with wrong denominations(fr eg:999Rs)
[Link] withdrawal success operation
[Link] operation when our entered amount is greater than possible balance
[Link] operation when our entered amount is greater than day limit
[Link] when our ATM have lack of Amount
[Link] when our ATM have network problem
[Link] Current transaction no. exceeded than day limit
[Link] operation with exceeded delay in between operations in ATM
[Link] Cancel after insert card
[Link] Cancel after Language selection
[Link] Cancel after Pin entry
[Link] Cancel after Amount type selection
[Link] Cancel after withdrawal operation
[Link] Cancel after Amount entrr
[Link] correction of Amount during entry
[Link] after successful transaction If customer doesn't take the money

90. What do you mean by High Level and Low Level Scenarios explain using an Example?
High level: Is like the overview of any test/ scenario, in which you define the major parts of your scenario.
Exp: Suppose you are given with a module, for coding. In that case first you will decide the major things like
Language, Database, System Configuration. etc... then proceed further.

Manual Testing Notes Page 43

Low level: It's like "Exploratory Testing" in which you study the whole thing in detail.
Ex: If you take the same example... After the major thing. Now you are ready for [Link] here you will decide
some variable names and use some std's for coding. so that any one can understand , what have you done.

91. What is Usability Testing?

Usability testing refers to evaluating a product or service by testing it with representative users. Typically, dur-
ing a test, participants will try to complete typical tasks while observers watch, listen and takes notes. The goal
is to identify any usability problems, collect qualitative and quantitative data and determine the participant's
satisfaction with the product.

To run an effective usability test, you need to develop a solid test plan, recruit participants , and then analyze
and report your findings.
Benefits of Usability Testing
Usability testing lets the design and development teams identify problems before they are coded. The earlier
issues are identified and fixed, the less expensive the fixes will be in terms of both staff time and possible im-
pact to the schedule. During a usability test, you will:

 Learn if participants are able to complete specified tasks successfully and

 Identify how long it takes to complete specified tasks
 Find out how satisfied participants are with your Web site or other product
 Identify changes required to improve user performance and satisfaction
 And analyze the performance to see if it meets your usability objectives

92. What is Thin and Thick client?

Thick clients, also called heavy clients, are full-featured computers that are connected to a network. Unlike Thin
clients, which lack hard drives and other features, thick clients are functional whether they are connected to a
network or not.

While a thick client is fully functional without a network connection, it is only a "client" when it is connected to
a server. The server may provide the thick client with programs and files that are not stored on the local
machine's hard drive. It is not uncommon for workplaces to provide thick clients to their employees. This
enables them to access files on a local server or use the computers offline. When a thick client is disconnected
from the network, it is often referred to as a workstation.

Web application:
================
any application which resides on a server, but meant for use by humans, which uses web pages as the
presentation layer. All user interactivity (the GUI) is done through web pages, but all data is stored and (mostly)
manipulated on the server.

Web service:

Manual Testing Notes Page 44

===========
server-based application (as above) which may be accessed over the web via HTTP, but is meant primarily for
interaction with other programs. Thus, it will have a clearly-defined API which consists of providing responses
to HTTP GET and POST requests made by a remote application. Now, this doesn't mean you can't access a web
service from your browser, but it means that the application won't necessarily have a GUI user interface. You
will most likely, for example, receive all results of GET and POST requests as strings of XML, which requires a
client-side parser.

Boundary Value testing

a) Boundary value Analysis: - A process of selecting test cases/data by identifying the boundaries that separate
valid and invalid conditions. Tests are constructed to test the inside and outside edges of these boundaries, in
addition to the actual boundary points. or A selection technique in which test data are chosen to lie along
“boundaries” of the input domain [or output range] classes, data structures, procedure parameters, etc.
Choices often include maximum, minimum, and trivial values or parameters.
E.g. - Input data 1 to 10 (boundary value)
Test input data 0, 1, 2 to 9, 10, 11

b. Equivalence testing
Equivalence testing: - The input domain of the system is partitioned into classes of representative values, so
that the no. of test cases can be limited to one-per-class, which represents the minimum no. of test cases that
must be executed.
E.g.- valid data range: 1-10
Test set:-2; 5; 14

c. Error Guessing
Error guessing: - Test data selection technique. The selection criterion is to pick values that seem likely to cause
errors Error guessing is based mostly upon experience, with some assistance from other techniques such as
boundary value analysis. Based on experience, the test designer guesses the types of errors that could occur in
a particular type of software and designs test cases to uncover them.
E.g. - For example, if any type of resource is allocated dynamically, a good place to look for errors is in the de-
allocation of resources. Are all resources correctly deallocated, or are some lost as the software executes?

d. Desk checking
Desk checking: - Desk checking is conducted by the developer of the system or program. The process involves
reviewing the complete product to ensure that it is structurally sound and that the standards and requirements
have been met. This is the most traditional means for analyzing a system or program.

e. Control Flow analysis

Control Flow Analysis: - It is based upon graphical representation of the program process. In control flow
analysis; the program graphs has nodes which represent a statement or segment possibly ending in an

Manual Testing Notes Page 45

unresolved branch. The graph illustrates the flow of program control from one segment to another as illustrated
through branches .the objective of control flow analysis is to determine the potential problems in logic
branches that might result in a loop condition or improper processing.

93. What risks you would include in the Test plan. Explain each risk factor that would be a part of your test
plan?
Web-Based Application primary risk factors:-
A) Security: anything related to the security of the application.
B) Performance:- The amount of computing resources and code required by the system to perform its stated
functions.
C) Correctness:-Data entered, processed, and outputted in the system is accurate and complete
D) Access Control:-Assurance that the application system resources will be protected
E) Continuity of processing:-The ability to sustain processing in the event problem occurs
F) Audit Trail:-The capability to substantiate the processing that has occurred.
G) Authorization:-Assurance that the data is processed in accordance with the intents of the management.
General risk or secondary risk’s:-
A) Complex - anything disproportionately large, intricate or convoluted.
B) New - anything that has no history in the product.
C) Changed - anything that has been tampered with or “improved”.
D) Upstream Dependency - anything whose failure will cause cascading failure in the rest of the system.
E) Downstream Dependency - anything that is especially sensitive to failures in the rest of the system.
F) Critical - anything whose failure could cause substantial damage.
G) Precise - anything that must meet its requirements exactly.
H) Popular - anything that will be used a lot.
I) Strategic - anything that has special importance to your business, such as a feature that sets you apart from
the competition.
J) Third-party - anything used in the product, but developed outside the project.
K) Distributed - anything spread out in time or space, yet whose elements must work together.
l) Buggy - anything known to have a lot of problems.
M) Recent Failure - anything with a recent history of failure.

94. Indicate the key roles you feel that the user should play during acceptance stage. Also indicate the
categories into which the acceptance requirements should fall ?
1) Ensure user involvement in developing systems requirement and acceptance criteria.
2) Identify interim and final products for acceptance their acceptance criteria and schedule.
3) Plan how and by whom each acceptance activity will be performed.
4) Plan resources for providing information.
5) Schedule adequate time for buyer staff to receive and examine the products and evaluation prior to
acceptance review.
6) Prepare the acceptance plan.
7) Respond to the analysis of project entitles before accepting and rejecting.
8 ) Approve the various interim software products.
9) Perform the final acceptance activities, including the formal acceptance testing at delivery.
10) Make an acceptance decision for each product.

Manual Testing Notes Page 46

95. What is parallel testing and when do we use parallel testing? Explain with example?
Testing a new or an altered data processing system with the same source data that is used in another system.
The other system is considered as the standard of comparison. OR we can say that parallel testing requires the
same input data be run through two versions of the same application.
Parallel testing should be used when there is uncertainty regarding the correctness of processing of the new
application. And old and new versions of the applications are same.
E.g.-
1) Operate the old and new version of the payroll system to determine that the paychecks from both systems
are reconcilable.
2) Run the old version of the application system to ensure that the operational status of the old system has
been maintained in the event that problems are encountered in the new application.
96. What is the difference between testing Techniques and tools? Give examples ?
Testing technique: - Is a process for ensuring that some aspects of the application system or unit functions
properly there may be few techniques but many tools.
Tools: - Is a vehicle for performing a test process. The tool is a resource to the tester, but itself is insufficient to
conduct testing
97. Differentiate between Transaction flow modeling, Finite state modeling, Data flow modeling and Timing
modeling?
Transaction Flow modeling: -The nodes represent the steps in transactions. The links
represent the logical connection between steps.
Finite state modeling:-The nodes represent the different user observable states of the software. The links
represent the transitions that occur to move from state to state.
Data flow modeling:-The nodes represent the data objects. The links represent the transformations that occur
to translate one data object to another.
Timing Modeling:-The nodes are Program Objects. The links are sequential connections between the program
objects. The link weights are used to specify the required execution times as program executes.

98. What is Negative Testing?

Testing the system in a negative way i.e. checking that whether system is doing what it is not supposed to do.

Top 10 Negative Test Cases

Negative test cases are designed to test the software in ways it was not intended to be used, and should be a
part of your testing effort. Below are the top 10 negative test cases you should consider when designing your
test effort:
1. Embedded Single Quote - Most SQL based database systems have issues when users store information
that contains a single quote (e.g. John's car). For each screen that accepts alphanumeric data entry, try
entering text that contains one or more single quotes.
2. Required Data Entry - Your functional specification should clearly indicate fields that require data entry
on screens. Test each field on the screen that has been indicated as being required to ensure it forces
you to enter data in the field.
3. Field Type Test - Your functional specification should clearly indicate fields that require specific data
entry requirements (date fields, numeric fields, phone numbers, zip codes, etc). Test each field on the
screen that has been indicated as having special types to ensure it forces you to enter data in the

Manual Testing Notes Page 47

 correct format based on the field type (numeric fields should not allow alphabetic or special characters,
date fields should require a valid date, etc).
4. Field Size Test - Your functional specification should clearly indicate the number of characters you can
enter into a field (for example, the first name must be 50 or less characters). Write test cases to ensure
that you can only enter the specified number of characters. Preventing the user from entering more
characters than is allowed is more elegant than giving an error message after they have already entered
too many characters.
5. Numeric Bounds Test - For numeric fields, it is important to test for lower and upper bounds. For
example, if you are calculating interest charged to an account, you would never have a negative interest
amount applied to an account that earns interest, therefore, you should try testing it with a negative
number. Likewise, if your functional specification requires that a field be in a specific range (e.g. from
10 to 50), you should try entering 9 or 51, it should fail with a graceful message.
6. Numeric Limits Test - Most database systems and programming languages allow numeric items to be
identified as integers or long integers. Normally, an integer has a range of -32,767 to 32,767 and long
integers can range from
-2,147,483,648 to 2,147,483,647. For numeric data entry that do not have specified bounds limits,
work with these limits to ensure that it does not get an numeric overflow error.
7. Date Bounds Test - For date fields, it is important to test for lower and upper bounds. For example, if
you are checking a birth date field, it is probably a good bet that the person's birth date is no older than
150 years ago. Likewise, their birth date should not be a date in the future.
8. Date Validity - For date fields, it is important to ensure that invalid dates are not allowed (04/31/2007 is
an invalid date). Your test cases should also check for leap years (every 4th and 400th year is a leap
year).
9. Web Session Testing - Many web applications rely on the browser session to keep track of the person
logged in, settings for the application, etc. Most screens in a web application are not designed to be
launched without first logging in. Create test cases to launch web pages within the application without
first logging in. The web application should ensure it has a valid logged in session before rendering
pages within the application.
10. Performance Changes - As you release new versions of your product, you should have a set of
performance tests that you run that identify the speed of your screens (screens that list information,
screens that add/update/delete data, etc). Your test suite should include test cases that compare the
prior release performance statistics to the current release. This can aid in identifying potential
performance problems that will be manifested with code changes to the current release.
99. Difference between Quality Assurance and Quality Control ?

Quality Assurance (QA) Quality Control (QC)

 It is a procedure that focuses on providing assurance that It is a procedure that focuses on fulfill-
quality request will be achieved ing the quality request
 QA aims to prevent the defect  QC aims to identify and fix defects
 It is a method to verify the quality-Val-
 It is a method to manage the quality- Verification
idation
 It does not involve executing the program  It always involves executing a program
 It's a Preventive technique  It's a Corrective technique

100. Difference between Test Scenario and Test Condition?

Manual Testing Notes Page 48
 Test Scenario Test Condition
 Test scenario is a possible ways to test an ap-  Test condition is the constraint that you should
plication. Example: For testing you have so many follow to test an application. Example: When User
ways like positive testing, negative testing, BVA Name and Password are valid then application will
etc. move forward
 Test condition can be a piece of functionality or
 Test scenario can be a single or a group of
anything you want to verify. In simple terms the goal
test cases
of a test cases
 It is important when time is less and most  It is an item or event of a system that could be
team members understand the details from one verified by one or more test cases. Eg; transaction,
line scenario function, structural element etc.

100. Difference between Test Harness and Test

automation frame work?

Test Harness Test Automation Framework

 A test harness is composed of drivers and  It is a set of processes, procedures, abstract con-
stubs, which are small dummy programs that inter- cept and environment in which automated tests are
act with the software under test designed and implemented
 You can not "Record & Playback" script in Test  Tester can manually "Record & Playback" script
Harness in this framework
 Test harness contains all the information
 Test automation framework contains informa-
needed to compile and run a test like test cases,
tion like test library, testing tools, automated testing
target deployment port(TDP), source file under
practices, testing platform, etc.
test, stubs, etc.
 Automation framework is categorized as
o Data driven testing
o Keyword driven testing
 Test harness is categorized into
o Modularity driven testing
o Automation testing
o Hybrid testing
o Integration testing
o Model based testing
o Code driven testing
o Behavior driven testing
101. Difference between Test Plan and Test Strategy?

Test Plan Test Strategy

Manual Testing Notes Page 49

 A test plan for software project can be defined as a Test strategy is a set of guidelines that ex-
document that defines the scope, objective, approach plains test design and determines how testing
and emphasis on a software testing effort needs to be done
 Components of Test plan include- Test plan id, fea-  Components of Test strategy includes- ob-
tures to be tested, test techniques, testing tasks, fea- jectives and scope, documentation formats, test
tures pass or fail criteria, test deliverables, responsibili- processes, team reporting structure, client com-
ties, and schedule, etc. munication strategy, etc.
 Test plan is carried out by a testing manager or  A test strategy is carried out by the project
lead that describes how to test, when to test, who will manager. It says what type of technique to fol-
test and what to test low and which module to test
 Test strategy narrates about the general ap-
 Test plan narrates about the specification
proaches
 Test plan can change  Test strategy cannot be changed
 It is a long-term plan of action. You can ab-
 Test planning is done to determine possible issues
stract information that is not project specific and
and dependencies in order to identify the risks.
put it into test approach

102. Difference between Defect Priority and Defect Severity?

Defect Priority Defect Severity

 Priority defines the order in which the developer  It is defined as the degree of impact that a
should resolve a defect defect has on the operation of the product
 Severity are categorized into five types
 Priority is categorized into three types o Critical
o Low o Major
o Medium o Moderate
o High o Minor
o Cosmetic
 Severity is associated with functionality or
 Priority is associated with scheduling
standards
 Severity indicates the seriousness of the
 Priority indicates how soon the bug should be fixed
defect on the product functionality
 Priority of defects is decided in consultation with the QA engineer determines the severity level
manager/client of the defect

Manual Testing Notes Page 50

101. Difference between Regression and Re-testing?

Regression Testing Re-testing

 Regression testing is carried out to confirm whether a Re-testing is carried out to confirm the
recent program or code change has not adversely affected test cases that failed in the final execution are
existing features passing after the defects are fixed
 The purpose of regression testing is that new code
 Re-testing is done on the basis of the de-
changes should not have any side effects to existing func-
fect fixes
tionalities
 Defect verification is not the part of regression test-
 Defect verification is the part of re-testing
ing
 Priority of re-testing is higher than regres-
 Based on the project and availability of resources, re-
sion testing, so it is carried out before regres-
gression testing can be carried out parallel with Re-testing
sion testing
 You can do automation for regression testing, manual You cannot automate the test cases for
testing could be expensive and time consuming Retesting

102. What is Cyclomatic Complexity?

Cyclomatic complexity is a software metric used to measure the complexity of a program. These metric,
measures independent paths through program source code.

Independent path is defined as a path that has atleast one edge which has not been traversed before in any
other paths.

Cyclomatic complexity can be calculated with respect to functions, modules, methods or classes within a
program

Manual Testing Notes Page 51

103. What is Agile Testing ? Explain the Agile life cycle ?
Introduction:
This is the guide for software developers and testers to understand and start working on the very famous Agile
SCRUM methodology for software development and testing. Learn the basic but important terminologies used
in Agile Scrum process along with a real example of the complete process.
SCRUM is a process in agile methodology which is a combination of Iterative model and incremental model.

One of the major handicaps of the traditional water-fall model was that – until first phase is complete, the
application does not move to the other phase. And if by chance there are some changes in the later stage of the
cycle, it becomes very challenging to implement those changes, as it would involve revisiting the earlier phases
and redoing the changes.

Some of the key characteristics of SCRUM include:

 Self-organized and focused team
 No huge requirement documents, rather have very precise and to the point stories.
 Cross functional team works together as a single unit.
 Close communication with the user representative to understand the features.
 Has definite time line of max 1 month.
 Instead of doing the entire “thing” at a time, Scrum does a little of everything at a given interval
 Resources capability and availability are considered before committing any thing.
To understand this methodology well, it’s important to understand the key terminologies in SCRUM.

Important SCRUM Terminologies:

1. Scrum Team
Scrum team is a team comprising of 7 with + or – two members. These members are a mixture of competencies
and comprise of developers, testers, data base people, support people etc. along with the product owner and a
scrum master. All these members work together in close collaboration for a recursive and definite interval, to
develop and implement the said features.

2. Sprint
Sprint is a predefined interval or the time frame in which the work has to be completed and make it ready for
review or ready for production deployment. This time box usually lies between 2 weeks to 1 month. In our day

Manual Testing Notes Page 52

to day life when we say that we follow 1 month Sprint cycle, it simply means that we work for one month on
the tasks and make it ready for review by the end of that month.

3. Product Owner
Product owner is the key stakeholder or the lead user of the application to be developed.

Product owner is the person who represents the customer side. He / she have the final authority and should
always be available for the team. He / she should be reachable in case any one has any doubts that need
clarification. It is important for the product owner to understand and not to assign any new requirement in the
middle of the sprint or when the sprint has already started.

4. Scrum Master
Scrum Master is the facilitator of the scrum team. He / she make sure that the scrum team is productive and
progressive. In case of any impediments, scrum master follows up and resolves them for the team.

5. User Story
User stories are nothing but the requirements or feature which has to be implemented. In scrum, we don’t
have those huge requirements documents, rather the requirements are defined in a single paragraph, typically
having the format as:

As a <User / type of user>

I want to <Some achievable goal / target>
To achieve <some result or reason of doing the thing>
For example:
As an Admin I want to have a password lock in case user enters incorrect password for consecutive 3 times to
restrict unauthorized access.

There are some characteristics of user stories which should be adhered. The user stories should be short,
realistic, could be estimated, complete, negotiable and testable.

Every user story has an acceptance criterion which should be well defined and understood by the team.
Acceptance criteria details down the user story, provides the supported documents. It helps to further refine
the user story. Anybody from the team can write down the acceptance criteria. Testing team base their test
cases / conditions on these acceptance criteria.

Manual Testing Notes Page 53

6. Epics
Epics are equivocal user stories or we can say these are the user stories which are not defined and are kept for
future sprints. Just try to relate it with life, imagine you are going for a vacation. Since you are going next week,
you have everything in place like your hotel bookings, sightseeing, travelers check etc. But what about your
vacation plan for next year? You have only a vague idea that you may go to XYZ place, but you have no detailed
plan.

An Epic is just like you next year’s vacation plan, where you just know that you may want to go , but where,
when, with whom, all these details you have no idea at this point of time.

In a similar way there are features which required to be implemented in future whose details are not yet
known. Mostly feature begins with an Epic and then broken down to stories which could be implemented.

7. Product Backlog
Product backlog is a kind of bucket or source where all the user stories are kept. This is maintained by Product
owner. Product backlog can be imagined as a wish list of the product owner who prioritizes it as per business
needs. During planning meeting (see next section), one user story is taken from the product backlog, team does
the brainstorming, understands it and refine it and collectively decides which user stories to take, with the
intervention of the product owner.

8. Sprint Backlog
Based on the priority, user stories are taken from the Product Backlog one at a time. The Scrum team
brainstorms on it, determines the feasibility and decides on the stories to work on a particular sprint. The
collective list of all the user stories which the scrum team works on a particular sprint is called s Sprint backlog.

Manual Testing Notes Page 54

9. Story Points:
Story points are quantitative indication of the complexity of a user story. Based on the story point, estimation
and efforts for a story is determined. Story point is relative and is not absolute. To make sure that our estimate
and efforts are correct, it’s important to check that the user stories are not big. Precise and smaller is the user
story, accurate will be the estimation.

Each and every user story is assigned a story point based on the Fibonacci series (1, 2, 3, 5, 8, 13&21). Higher is
the number, complex is the story.

To be precise
 If you give 1 / 2 / 3 story point it means the story is small and of low complexity.
 If you give points as 5 / 8, it is a medium complex and
 13 and 21 are highly complex.
Here complexity consists of both development plus testing effort

To decide a story point, brainstorming happens with in the scrum team and the team collectively decides a
story point. It may happen that development team gives a story point of 3 to a particular story, because for
them it may be 3 lines of code change, but testing team gives 8 story point because they feel this code change
will affect larger modules so testing effort would be larger. Whatever story point you are giving, you have to
justify it. So in this situation, brainstorming happens and the team collectively agrees to one story point.

Manual Testing Notes Page 55

Whenever you are deciding on a story point, keep the below factors in mind:

 Dependency of the story with other application / module,

 Skill set of the resource
 Complexity of the story
 Historical learning,
 Acceptance criteria of the user story
If you are not aware of a particular story, don’t size it.
If you see that the story point is very high, further decompose it to smaller stories.
10. Burn down chart
Burn down chart is a graph which shows the estimated v/s actual effort of the scrum tasks.

It is a tracking mechanism by which for a particular sprint; day to day tasks are tracked to check whether the
stories are progressing towards the completion of the committed story points or not.

Example: To understand this, check the below figure:

I have assumed:
 2 weeks Sprint ( 10 days)
 2 resources actual working on the sprint.
“Story”-> Column shows the user stories taken for the sprint.
“Task” -> Column shows the list of task associated to the user story.
“Effort” -> Column shows the effort. Now; this measure is the total effort to complete the task. It does not
depict the effort put in by any specific individual.
“Day 1 – Day 10” -> – Column(s) shows the hours which are left to complete the story. Please see that the hour
is NOT the hour which is already done BUT the hours which are still left.
“Estimated Effort” -> is the total of the effort. For the “Start” it is simply the sum of the entire individual task:
SUM (C5: C15)

Manual Testing Notes Page 56

Total number of effort that has to be completed in 1 day is 70 / 10 = 7. So at the end of day 1, the effort should
reduce to 70 – 7 = 63. In a similar way it is calculated for all the days till day 10, when estimated effort should be
0 (Row 16)

“Actual Effort Left” -> as the name suggests, is the effort actually left to complete the story. It may also happen
that the actual efforts increases or decreases than the estimated one.
You can use the in build functions and Chart in Excel to create this burn down chart.

Burn Down Chart steps would be:

1. Enter all the stories ( Column A5 – A15)
2. Enter all the Tasks ( Column B5 – B15)
3. Enter the Days ( Day 1 – Day 10 )
4. Enter the starting efforts (Sum the tasks C5 – C15 )
5. Apply formula to calculate the “Estimated Efforts” for each day (Day 1 to Day 10). Enter the formula at
D15 (C16-$C$16/10) and drag it for all the days.
6. For each day, enter the actual efforts. Enter the formula at D17 (SUM (D5:D15)) for summing up the ac-
tual efforts left, and drag it for all the other days.
7. Select it and create the chart as follows:

11. Velocity
Total number of story point which a scrum team archives in a sprint, is called Velocity. The Scrum team is judged
or referenced by its velocity. Having said that, it should be kept in mind that the objective here is NOT achieving
the maximum story points, but to have quality deliverable, respecting scrum team’s comfort level.

For example: For a particular sprint: total number of user stories are 8 having story points as

Manual Testing Notes Page 57

So here the velocity will be the sum of the story points = 30

12. Definition of Done:

A story is DONE in Scrum, only when it is development and QA complete and the feature is eligible to be
shipped to production.

Activities done in SCRUM Methodology:

#1: Planning meeting
Planning meeting is the starting point of SCRUM. It is the meeting where the entire scrum team gather, the
product owner selects a user story based on the priority from the product back log and the team brain storms
on it. Based on the discussion, the scrum team decides the complexity of the story and sizes it as per the
Fibonacci series. Team identifies the tasks along with the efforts (in hours) which would be done to complete
the implementation the user story.

Many a time planning meeting is preceded by a “Pre-Planning meeting”. It’s just like a home work which the
scrum team does before they sit for the formal planning meet. Team tries to write down the dependencies or
other factors which they would like to discuss in the planning meet.

#2: Execution of sprint tasks

As the name suggests, these are the actual work done by the scrum team to accomplish their task and take the
user story into the “Done” state.

#3: Daily scrum meeting (call)

During the sprint cycle, every day the scrum team meets for, not more than 15 minutes (could be a stand up
call, recommended to have during the beginning of the day) and state 3 points:

Manual Testing Notes Page 58

 1. What did the team member did yesterday
2. What did the team member plan to do today
3. Any impediments (roadblocks)
It is the Scrum master who facilitates this meeting. In case, any team member is facing any kind of difficulties,
the scrum master follows up to get it resolved.

#4: Review meeting

At the end of every sprint cycle, the SCRUM team meets again and demonstrates implemented user stories to
the product owner. The product owner may cross verify the stories as per its acceptance criteria. It’s again the
responsibility of the Scrum master to preside over this meeting.

#5: Retrospective meeting

Retrospective meeting happens after the review meeting. The SCRUM team meets and discusses & document
the following points:

1. What went well during the Sprint (Best practices)

2. What did not went well in the Sprint
3. Lessons learnt
4. Action Items.
The Scrum team should continue to follow the best practice, ignore the “not best practices” and implement the
lessons learnt during the consequent sprints. The retrospective meeting helps to implement the continuous
improvement of the SCRUM process.

How the Process is done? An example!

Having read about the technical jargons of SCRUM; let me try to demonstrate the whole process with an
example.

Step #1: Let’s have a SCRUM team of 9 people comprising of 1 product owner, 1 Scrum master, 2 testers, 4
developers and 1 DBA.
Step #2: The Sprint is decided to follow 4 weeks cycle. So we have 1 month Sprint starting 5th June to 4th of July.
Step #3: The Product owner has the prioritized list of user stories in the product backlog.

Manual Testing Notes Page 59

Step #4: The team decides to meet on 4th June for the “Pre Planning” meeting.
 The product owner takes 1 story from the product backlog, describes it and leaves it to the team to
brainstorm on it.
 The entire team discusses and communicates directly to the product owner to have clear understood of
the user story.
 In a similar way various other user stories are taken. If possible team can go ahead and size the stories
as well.
After all the discussion, Individual team member go back to their work stations and

 Identify their individual tasks for each story.

 Calculate the exact number of hours on which they will be working. How the member concludes these
hours; let’s check that
Total number of working hours = 9
Minus 1 hour for break, minus 1 hour for meetings, minus 1 hour for mails, discussions, troubleshooting etc.
So the actual working hours = 6
Total number of working days during the Sprint = 21 days.
Total number of hours available = 21*6 = 126
The member is on leave for 2 days = 12 hours (This varies for each member, some may take leave and some may
not.)
Number of actual hours = 126 – 12 = 114 hours.
This means that the member will actually available for 114 hours for this sprint. So he will break down his
individual sprint task in such a way that total of 114 hours is reached.

Step #5: On 5th of June the entire Scrum team meets for the “Planning Meeting”.
 Final verdict of the user story from the product backlog is done and the story is moved to the Sprint
back log.
 For each story, each team member declares their identified tasks, if required can have a discussion on
those tasks, can size or resize it (remember the Fibonacci series!!).
 The Scrum master or the team enter their individual tasks along with their hours for each story in a
tool.
 After all the stories are completed, Scrum master notes the initial Velocity and formally starts the
Sprint.
Step #6: Once the Sprint has started, based on the tasks assigned, each team member starts working on those
tasks.
Step #7: The team meets daily for 15 minutes and discusses 3 things:
 What did they do yesterday?
Manual Testing Notes Page 60
  What they plan to do today
 Any impediments (roadblocks)?
Step #8: The scrum master tracks the progress on daily basis with the help of “Burn down chart”
Step #9: In case of any impediments, the Scrum master follows up to resolve those.
Step #10: On 4th July, the team meets again for the review meeting. A member demonstrates the implemented
user story to the product owner.
Step #11: On 5th July, Team meets again for the Retrospective, where they discuss
 What went well?
 What did not went well
 Action Items.
Step #12: On 6th July, Team again meets for the pre-planning meeting for the next sprint and the cycle
continues.
(Click to enlarge image)

Tools that can be used for SCRUM activities:

There are many tools available which can be used extensively for tracking the scrum activities. Some of them

Manual Testing Notes Page 61

include:

 Jira
 XPlanner
 VersionOne
 Sprintometer
 ScrumNinja

104. What is Important Software Test Metrics and Measurements – Explained with Examples and Graphs?

In software projects, it is most important to measure the quality, cost and effectiveness of the project and the
processes. Without measuring these, project can’t be completed successfully.

In today’s article we will learn with examples and graphs – Software test metrics and measurements and how
to use these in software testing process.
There is a famous statement: “We can’t control things which we can’t measure”.
Here controlling the projects means, how a project manager/lead can identify the deviations from the test plan
ASAP in order to react in the perfect time. Generation of test metrics based on the project needs is very much
important to achieve the quality of the software being tested.

Manual Testing Notes Page 62

105. What are Software Testing Metrics?

A Metric is a quantitative measure of the degree to which a system, system component, or process possesses a
given attribute.
Metrics can be defined as “STANDARDS OF MEASUREMENT”.
Software Metrics are used to measure the quality of the project. Simply, Metric is a unit used for describing an
attribute. Metric is a scale for measurement.

Suppose, in general, “Kilogram” is a metric for measuring the attribute “Weight”. Similarly, in software, “How
many issues are found in thousand lines of code?”, here No. of issues is one measurement & No. of lines of code
is another measurement. Metric is defined from these two measurements.
Test metrics example:
 How many defects are existed within the module?
 How many test cases are executed per person?
 What is the Test coverage %?

Manual Testing Notes Page 63

106. What is Software Test Measurement?

Measurement is the quantitative indication of extent, amount, dimension, capacity, or size of some attribute of
a product or process.
Test measurement example: Total number of defects.
Please refer below diagram for clear understanding of the difference between Measurement & Metrics.

107. Why Test Metrics?

Generation of Software Test Metrics is the most important responsibility of the Software Test Lead/Manager.

Test Metrics are used to,

1. Take the decision for next phase of activities such as, estimate the cost & schedule of future projects.
2. Understand the kind of improvement required to success the project
3. Take decision on process or technology to be modified etc.
Importance of Software Testing Metrics:
As explained above, Test Metrics are the most important to measure the quality of the software.

Now, how can we measure the quality of the software by using Metrics?
Suppose, if a project does not have any metrics, then how the quality of the work done by a Test analyst will be
measured?

For Example: A Test Analyst has to,

1. Design the test cases for 5 requirements
2. Execute the designed test cases
3. Log the defects & need to fail the related test cases

Manual Testing Notes Page 64

 4. After the defect is resolved, need to re-test the defect & re-execute the corresponding failed test case.
In above scenario, if metrics are not followed, then the work completed by the test analyst will be subjective
i.e. the test reportwill not have the proper information to know the status of his work/project.
If Metrics are involved in the project, then the exact status of his/her work with proper numbers/data can be
published.

I.e. in the Test report, we can publish:

1. How many test cases have been designed per requirement?
2. How many test cases are yet to design?
3. How many test cases are executed?
4. How many test cases are passed/failed/blocked?
5. How many test cases are not yet executed?
6. How many defects are identified & what is the severity of those defects?
7. How many test cases are failed due to one particular defect? etc.
Based on the project needs we can have more metrics than above mentioned list, to know the status of the
project in detail.

Based on the above metrics, test lead/manager will get the understanding of the below mentioned key
points.
a) %ge of work completed
b) %ge of work yet to be completed
c) Time to complete the remaining work
d) Whether the project is going as per the schedule or lagging? etc.
Based on the metrics, if the project is not going to complete as per the schedule, then the manager will raise the
alarm to the client and other stake holders by providing the reasons for lagging to avoid the last minute sur-
prises.

Manual Testing Notes Page 65

Metrics Life Cycle:

Types of Manual Test Metrics:

Testing Metrics are mainly divided into 2 categories.

1. Base Metrics
2. Calculated Metrics
Base Metrics:
Base Metrics are the Metrics which are derived from the data gathered by the Test Analyst during the test case
development and execution.
This data will be tracked throughout the Test Life cycle. I.e. collecting the data like, Total no. of test cases de-
veloped for a project (or) no. of test cases need to be executed (or) no. of test cases passed/failed/blocked etc.

Calculated Metrics:
Calculated Metrics are derived from the data gathered in Base Metrics. These Metrics are generally tracked by
the test lead/manager for Test Reporting purpose.

Examples of Software Testing Metrics:

Let’s take an example to calculate various test metrics used in software test reports:

Below is the table format for the data retrieved from the test analyst who is actually involved in testing:

Manual Testing Notes Page 66

Definitions and Formulas for Calculating Metrics:
#1) %ge Test cases Executed: This metric is used to obtain the execution status of the test cases in terms of
%ge.
%ge Test cases Executed = (No. of Test cases executed / Total no. of Test cases written) * 100.
So, from the above data,
%ge Test cases Executed = (65 / 100) * 100 = 65%
#2) %ge Test cases not executed: This metric is used to obtain the pending execution status of the test cases in
terms of %ge.
%ge Test cases not executed = (No. of Test cases not executed / Total no. of Test cases written) * 100.
So, from the above data,
%ge Test cases Blocked = (35 / 100) * 100 = 35%
------------

Manual Testing Notes Page 67

#3) %ge Test cases Passed: This metric is used to obtain the Pass %ge of the executed test cases.
%ge Test cases Passed = (No. of Test cases Passed / Total no. of Test cases Executed) * 100.
So, from the above data,
%ge Test cases Passed = (30 / 65) * 100 = 46%
#4) %ge Test cases Failed: This metric is used to obtain the Fail %ge of the executed test cases.
%ge Test cases Failed = (No. of Test cases Failed / Total no. of Test cases Executed) * 100.
So, from the above data,
%ge Test cases Passed = (26 / 65) * 100 = 40%
#5) %ge Test cases Blocked: This metric is used to obtain the blocked %ge of the executed test cases. A de-
tailed report can be submitted by specifying the actual reason of blocking the test cases.
%ge Test cases Blocked = (No. of Test cases Blocked / Total no. of Test cases Executed) * 100.
So, from the above data,
%ge Test cases Blocked = (9 / 65) * 100 = 14%

Manual Testing Notes Page 68

#6) Defect Density = No. of Defects identified / size
(Here “Size” is considered as requirement. Hence here the Defect Density is calculated as number of defects
identified per requirement. Similarly, Defect Density can be calculated as number of Defects identified per 100
lines of code [OR] No. of defects identified per module etc.)
So, from the above data,
Defect Density = (30 / 5) = 6
#7) Defect Removal Efficiency (DRE) = (No. of Defects found during QA testing / (No. of Defects found during
QA testing +No. of Defects found by End user)) * 100
DRE is used to identify the test effectiveness of the system.
Suppose, During Development & QA testing, we have identified 100 defects.
After the QA testing, during Alpha & Beta testing, end user / client identified 40 defects, which could have been
identified during QA testing phase.
Now, The DRE will be calculated as,
DRE = [100 / (100 + 40)] * 100 = [100 /140] * 100 = 71%

Manual Testing Notes Page 69

$8) Defect Leakage: Defect Leakage is the Metric which is used to identify the efficiency of the QA testing i.e.,
how many defects are missed / slipped during the QA testing.
Defect Leakage = (No. of Defects found in UAT / No. of Defects found in QA testing.) * 100
Suppose, During Development & QA testing, we have identified 100 defects.
After the QA testing, during Alpha & Beta testing, end user / client identified 40 defects, which could have been
identified during QA testing phase.
Defect Leakage = (40 /100) * 100 = 40%

#9) Defects by Priority: This metric is used to identify the no. of defects identified based on the Severity / Prior-
ity of the defect which is used to decide the quality of the software.
%ge Critical Defects = No. of Critical Defects identified / Total no. of Defects identified * 100
From the data available in the above table,
%ge Critical Defects = 6/ 30 * 100 = 20%
%ge High Defects = No. of High Defects identified / Total no. of Defects identified * 100
From the data available in the above table,
%ge High Defects = 10/ 30 * 100 = 33.33%
%ge Medium Defects = No. of Medium Defects identified / Total no. of Defects identified * 100
From the data available in the above table,
%ge Medium Defects = 6/ 30 * 100 = 20%
%ge Low Defects = No. of Low Defects identified / Total no. of Defects identified * 100
From the data available in the above table,
%ge Low Defects = 8/ 30 * 100 = 27%

Manual Testing Notes Page 70

108. What is Baseline document, Can you say any two?
Documents that are approved by the client and will not have any more changes are baseline docs. Service Level
Agreement (SLA), Business Requirement Docs(BRD).
109. What is a Test Bed?
Test bed is the environment where the testing is supposed to be done. Setting up the hardware and software
requirements before starting testing is known as test Bed.
An execution environment configured for testing. May consist of specific hardware OS network topology
configuration of the product under test other application or system software etc. The Test Plan for a project
should enumerated the test beds(s) to be used.

110. What is the difference between Volume, Load & Stress?

Load Testing : To check the performance of an application based on increasing no. of users. In it testing an
application with maximum no. of users and resources. Load testing is used to check the application's
performance when it is accessed simultaneously by various users
Stress Testing : In software testing, stress test refers to tests that put a greater emphasis on robustness,
availability, and error handling under a heavy load, rather than on what would be considered correct behavior
under normal circumstances. In particular, the goals of such tests may be to ensure the software doesn't crash
in conditions of insufficient computational resources (such as memory or disk space), unusually high
concurrency, or denial of service attacks.
In other words, stress testing helps find out the level of robustness and consistent or satisfactory performance
even when the limits for normal operation for the system (software/hardware) is crossed.
In it Testing an application with more than maximum no. of users and less resources. Stress testing is a
form of testing that is used to determine the stability of a given system or entity. It involves testing beyond
normal operational capacity, often to a breaking point, in order to observe the results. Stress testing may have a
more specific meaning in certain industries.
Performance Testing : To check whether our application is giving response with in the expected time or not.
Volume Testing : Testing the build under huze volume of data.

111. What is the difference between Two Tier & Three tier Architecture?
Two tier architecture is client server and three tier architecture is web based application.
Two Tier Architecture: It is nothing but client server Architecture, where client will hit request directly to server
and client will get response directly from server.
Three tier Architecture: It is nothing but Web Based application, here in between client and server middle ware
will be there, if client hits a request it will go to the middle ware and middle ware will send to server and vise-
versa.
112. What is the Difference between Client Server & Web Based Testing?
Client server application is 2 tier application and web application is n tier application.
Client server is the single user application and the web application is the multi User application.

Client server Technology:

1. Number of clients is predicted or known
2. Client and server are the entities to be tested
3. Both server and client locations are fixed and known to the user
4. Server to server interaction is prohibited
5. Low multimedia type of data transaction
6. Designed and implemented on intranet environment
7. Application is loaded at the server. In every client machine an exe is loaded to call this application.

Manual Testing Notes Page 71

Web based Technology
1. Number of clients is difficult to predict (millions of clients)
2. Client Server and network are the entities to be tested
3. Server location is certain client locations are not certain
4. Server to server interaction is normal
5. Rich multimedia type of data transaction
6. Designed and implemented on Internet environment
7. Application is loaded at the server but No exe is installed at the client machine. We have to call the
application through browser.

113. What is the Difference between Code Walk through & Code Review?
Walk-through is usually performed by "following" the code. The author should explain what the code is
supposed to do from line to line, procedure call to procedure call etc. etc.
Code Walkthrough: A formal testing technique where source code is traced by a group with a small set of test
cases while the state of program variables is manually monitored to analyze the programmer's logic and
assumptions.
Code Review: A meeting at which software code is presented to project personnel managers users customers or
other interested parties for comment or approval.

114. What is Testing life cycle?

Life Cycle of Testing Process

12. Requirement Stage
13. Test Plan
14. Test Design
15. Design Review
16. Code Review
17. Test Cases Preparation
18. Test Execution
19. Test Report
20. Bug Reporting
21. Reworking on patches
22. Release to production

115. What is Boundary value analysis and Equivalence partitioning, explained with simple example?
Boundary value analysis and equivalence partitioning both are test case design strategies in black box testing.
Equivalence Partitioning: In this method the input domain data is divided into different equivalence data
classes. This method is typically used to reduce the total number of test cases to a finite set of testable test
cases, still covering maximum requirements. In short it is the process of taking all possible test cases and
placing them into classes. One test value is picked from each class while testing.
E.g.: If you are testing for an input box accepting numbers from 1 to 1000 then there is no use in writing
thousand test cases for all 1000 valid input numbers plus other test cases for invalid data.

Manual Testing Notes Page 72

Using equivalence partitioning method above test cases can be divided into three sets of input data called as
classes. Each test case is a representative of respective class.
So in above example we can divide our test cases into three equivalence classes of some valid and invalid
inputs.
Test cases for input box accepting numbers between 1 and 1000 using Equivalence Partitioning:
1) One input data class with all valid inputs. Pick a single value from range 1 to 1000 as a valid test case. If you
select other values between 1 and 1000 then result is going to be same. So one test case for valid input data
should be sufficient.
2) Input data class with all values below lower limit. I.e. any value below 1, as a invalid input data test case.
3) Input data with any value greater than 1000 to represent third invalid input class.
So using equivalence partitioning you have categorized all possible test cases into three classes. Test cases with
other values from any class should give you the same result.
We have selected one representative from every input class to design our test cases. Test case values are
selected in such a way that largest number of attributes of equivalence class can be exercised.
Equivalence partitioning uses fewest test cases to cover maximum requirements.
Boundary value analysis:
It’s widely recognized that input values at the extreme ends of input domain cause more errors in system. More
application errors occur at the boundaries of input domain. ‘Boundary value analysis’ testing technique is used
to identify errors at boundaries rather than finding those exist in center of input domain.
Boundary value analysis is a next part of Equivalence partitioning for designing test cases where test cases are
selected at the edges of the equivalence classes.
Test cases for input box accepting numbers between 1 and 1000 using Boundary value analysis:
1) Test cases with test data exactly as the input boundaries of input domain i.e. values 1 and 1000 in our
case.
2) Test data with values just below the extreme edges of input domains i.e. values 0 and 999.
3) Test data with values just above the extreme edges of input domain i.e. values 2 and 1001.
Boundary value analysis is often called as a part of stress and negative testing.
Note: There is no hard-and-fast rule to test only one value from each equivalence class you created for input
domains. You can select multiple valid and invalid values from each equivalence class according to your needs
and previous judgments.

116. Differentiate between Transaction flow modeling, Finite state modeling, Data flow modeling and Timing
modeling?
Transaction Flow modeling: -The nodes represent the steps in transactions. The links
represent the logical connection between steps.
Finite state modeling:-The nodes represent the different user observable states of the software. The links
represent the transitions that occur to move from state to state.
Data flow modeling:-The nodes represent the data objects. The links represent the transformations that occur
to translate one data object to another.
Timing Modeling:-The nodes are Program Objects. The links are sequential connections between the program
objects. The link weights are used to specify the required execution times as program executes.

117. What is RAD Model?

RAD is a linear sequential software development process model that emphasis an extremely short development
cycle using a component based construction approach. If the requirements are well understood and defines,
and the project scope is constraint, the RAD process enables a development team to create a fully functional
system with in very short time period.

Manual Testing Notes Page 73

 [Link]-driven development (TDD)?
Test-driven development (TDD) is a development technique where you must first write a test that fails before
you write new functional code.
TDD is being quickly adopted by agile software developers for development of application source code and is
even being adopted by Agile DBAs for database development.

119. What is SaaS Testing?

SaaS Testing refers to the methods used to ensure that applications built using the software as a service model
of development function as designed.
SaaS Testing occurs after a specific iteration of the SaaS Development Process has been brought to closure.
220. What is TaaS Testing?

TaaS or Software Testing as a Service is an outsourcing model, in which testing activities are outsourced to a
third party that specializes in simulating real world testing environments as per client requirements.

221. What is API testing?

API testing is entirely different from GUI testing and mainly concentrates on the business logic layer of
the software architecture. This testing won't concentrate on the look and feel of an application.
Instead of using standard user inputs(keyboard) and outputs, in API Testing, you use software to send
calls to the API, get output, and note down the system's response.
API Testing requires an application to interact with API. In order to test an API, you will need to
Use Testing Tool to drive the API. Write your own code to test the API

Unit Testing API testing

 Developers perform it  Testers perform it

 End to end functionality has been
 Separate functionality is tested
tested
 Developer can access the source
 Testers cannot access the source code
code
 UI testing is also involved  Only API functions are tested
 Only basic functionalities are tested  All functional issues are tested
 Limited in scope  Broader in scope
 Usually ran before check-in  Ran after build is created

222. What is Cookie?

Cookie is small information stored in text file on user’s hard drive by web server. This information is later used
by web browser to retrieve information from that machine. Generally cookie contains personalized user data or
information that is used to communicate between different web pages.

Why Cookies are used?

Manual Testing Notes Page 74

Cookies are nothing but the user’s identity and used to track where the user navigated throughout the web site
pages. The communication between web browser and web server is stateless.
For example if you are accessing domain [Link] then web browser will simply query
to [Link] web server for the page [Link]. Next time if you type page as [Link]
then new request is send to [Link] web server for sending [Link] page and web server don’t know
anything about to whom the previous page [Link] served.

What if you want the previous history of this user communication with the web server? You need to maintain
the user state and interaction between web browser and web server somewhere. This is where cookie comes
into picture. Cookies serve the purpose of maintaining the user interactions with web server.

How cookies work?

The HTTP protocol used to exchange information files on the web is used to maintain the cookies. There are
two types of HTTP protocol. Stateless HTTP and Stateful HTTP protocol. Stateless HTTP protocol does not keep
any record of previously accessed web page history. While Stateful HTTP protocol do keep some history of
previous web browser and web server interactions and this protocol is used by cookies to maintain the user
interactions.
Whenever user visits the site or page that is using cookie, small code inside that HTML page (Generally a call to
some language script to write the cookie like cookies in JAVAScript, PHP, Perl) writes a text file on users machine
called cookie.
Here is one example of the code that is used to write cookie and can be placed inside any HTML page:
Set-Cookie: NAME=VALUE; expires=DATE; path=PATH; domain=DOMAIN_NAME;

When user visits the same page or domain later time this cookie is read from disk and used to identify the
second visit of the same user on that domain. Expiration time is set while writing the cookie. This time is
decided by the application that is going to use the cookie.

Generally two types of cookies are written on user machine.

1) Session cookies: This cookie is active till the browser that invoked the cookie is open. When we close the
browser this session cookie gets deleted. Some time session of say 20 minutes can be set to expire the cookie.
2) Persistent cookies: The cookies that are written permanently on user machine and lasts for months or years.
Where cookies are stored?
When any web page application writes cookie it get saved in a text file on user hard disk drive. The path where
the cookies get stored depends on the browser. Different browsers store cookie in different paths. E.g. Internet
explorer store cookies on path “C:\Documents and Settings\Default User\Cookies”
Manual Testing Notes Page 75
Here the “Default User” can be replaced by the current user you logged in as. Like “Administrator”, or user
name like “Vijay” etc.
The cookie path can be easily found by navigating through the browser options. In Mozilla Firefox browser you
can even see the cookies in browser options itself. Open the Mozila browser, click on Tools->Options->Privacy
and then “Show cookies” button.

How cookies are stored?

Lets take example of cookie written by [Link] on Mozilla Firefox browser:
On Mozilla Firefox browser when you open the page [Link] or login to your rediffmail account, a cookie will
get written on your Hard disk. To view this cookie simply click on “Show cookies” button mentioned on above
path. Click on [Link] site under this cookie list. You can see different cookies written by rediff domain with
different names.
Site: [Link] Cookie name: RMID
Name: RMID (Name of the cookie)
Content: 1d11c8ec44bf49e0… (Encrypted content)
Domain: .[Link]
Path: / (Any path after the domain name)
Send For: Any type of connection
Expires: Thursday, December 31, 2020 11:59:59 PM
Applications where cookies can be used:
1) To implement shopping cart:
Cookies are used for maintaining online ordering system. Cookies remember what user wants to buy. What if
user adds some products in their shopping cart and if due to some reason user don’t want to buy those
products this time and closes the browser window? When next time same user visits the purchase page he can
see all the products he added in shopping cart in his last visit.
2) Personalized sites:
When user visits certain pages they are asked which pages they don’t want to visit or display. User options are
get stored in cookie and till the user is online, those pages are not shown to him.
3) User tracking:
To track number of unique visitors online at particular time.
4) Marketing:
Some companies use cookies to display advertisements on user machines. Cookies control these
advertisements. When and which advertisement should be shown? What is the interest of the user? Which
keywords he searches on the site? All these things can be maintained using cookies.

5) User sessions:
Manual Testing Notes Page 76
Cookies can track user sessions to particular domain using user ID and password.
Drawbacks of cookies:
1) Even writing Cookie is a great way to maintain user interaction, if user has set browser options to warn
before writing any cookie or disabled the cookies completely then site containing cookie will be completely
disabled and can not perform any operation resulting in loss of site traffic.

2) Too many Cookies:

If you are writing too many cookies on every page navigation and if user has turned on option to warn before
writing cookie, this could turn away user from your site.
3) Security issues:
Some times users personal information is stored in cookies and if someone hack the cookie then hacker can get
access to your personal information. Even corrupted cookies can be read by different domains and lead to
security issues.
4) Sensitive information:
Some sites may write and store your sensitive information in cookies, which should not be allowed due to
privacy concerns.
This should be enough to know what cookies are. If you want more cookie info see Cookie Central page.
Some Major Test cases for web application cookie testing:
The first obvious test case is to test if your application is writing cookies properly on disk. You can use
the Cookie Tester applicationalso if you don’t have any web application to test but you want to understand the
cookie concept for testing.
Test cases:
1) As a Cookie privacy policy make sure from your design documents that no personal or sensitive data is
stored in the cookie.
2) If you have no option than saving sensitive data in cookie make sure data stored in cookie is stored in
encrypted format.
3) Make sure that there is no overuse of cookies on your site under test. Overuse of cookies will annoy users if
browser is prompting for cookies more often and this could result in loss of site traffic and eventually loss of
business.
4) Disable the cookies from your browser settings: If you are using cookies on your site, your sites major
functionality will not work by disabling the cookies. Then try to access the web site under test. Navigate
through the site. See if appropriate messages are displayed to user like “For smooth functioning of this site
make sure that cookies are enabled on your browser”. There should not be any page crash due to disabling the
cookies. (Please make sure that you close all browsers, delete all previously written cookies before performing
this test)
5) Accepts/Reject some cookies: The best way to check web site functionality is, not to accept all cookies. If
Manual Testing Notes Page 77
you are writing 10 cookies in your web application then randomly accept some cookies say accept 5 and reject
5 cookies. For executing this test case you can set browser options to prompt whenever cookie is being written
to disk. On this prompt window you can either accept or reject cookie. Try to access major functionality of web
site. See if pages are getting crashed or data is getting corrupted.
6) Delete cookie: Allow site to write the cookies and then close all browsers and manually delete all cookies for
web site under test. Access the web pages and check the behavior of the pages.
7) Corrupt the cookies: Corrupting cookie is easy. You know where cookies are stored. Manually edit the cookie
in notepad and change the parameters to some vague values. Like alter the cookie content, Name of the cookie
or expiry date of the cookie and see the site functionality. In some cases corrupted cookies allow to read the
data inside it for any other domain. This should not happen in case of your web site cookies. Note that the
cookies written by one domain say [Link] can’t be accessed by other domain say [Link] unless and
until the cookies are corrupted and someone trying to hack the cookie data.
8 ) Checking the deletion of cookies from your web application page: Some times cookie written by domain
say [Link] may be deleted by same domain but by different page under that domain. This is the general
case if you are testing some ‘action tracking’ web portal. Action tracking or purchase tracking pixel is placed on
the action web page and when any action or purchase occurs by user the cookie written on disk get deleted to
avoid multiple action logging from same cookie. Check if reaching to your action or purchase page deletes the
cookie properly and no more invalid actions or purchase get logged from same user.
9) Cookie Testing on Multiple browsers: This is the important case to check if your web application page is
writing the cookies properly on different browsers as intended and site works properly using these cookies. You
can test your web application on Major used browsers like Internet explorer (Various versions), Mozilla Firefox,
Netscape, Opera etc.
10) If your web application is using cookies to maintain the logging state of any user then log in to your web
application using some username and password. In many cases you can see the logged in user ID parameter
directly in browser address bar. Change this parameter to different value say if previous user ID is 100 then
make it 101 and press enter. The proper access message should be displayed to user and user should not be
able to see other users account.
These are some Major test cases to be considered while testing website cookies. You can write multiple test
cases from these test cases by performing various combinations. If you have some different application
scenario, you can mention your test cases in

223. What is Web application?

================
any application which resides on a server, but meant for use by humans, which uses web pages as the
presentation layer. All user interactivity (the GUI) is done through web pages, but all data is stored and
(mostly) manipulated on the server.
224. What is Web service?

Manual Testing Notes Page 78

 ===========
server-based application (as above) which may be accessed over the web via HTTP, but is meant primar-
ily for interaction with other programs. Thus, it will have a clearly-defined API which consists of provid-
ing responses to HTTP GET and POST requests made by a remote application. Now, this doesn't mean
you can't access a web service from your browser, but it means that the application won't necessarily
have a GUI user interface. You will most likely, for example, receive all results of GET and POST requests
as strings of XML, which requires a client-side parser.

Manual Testing Notes Page 79

Different Domain Application Testing

1. Banking Application Testing

2. E-commerce Application Testing
3. Payment Gateway Testing
4. Retail Application Testing
5. Insurance Application Testing
6. Healthcare Application Testing
7. Telecom Application Testing

1) Banking Application Testing

Manual Testing Notes Page 80
Banking Applications directly deal with confidential financial data. It is mandatory that all the activities
performed by banking software run smoothly and without any error. Banking software perform vari-
ous functions like transferring and depositing fund, balance inquiry, transaction history, withdrawal
and so on. Testing banking application assures that these activities are not only executed well but also
remain protected from hackers.

In this tutorial, we will learn

 What is Domain in Testing?
 Why Domain Knowledge Matters?
 Introduction to Banking Domain
 Characteristics of a banking application
 Stages of testing banking applications
 Sample Test Case for Net Banking Login Application
 Challenges in testing banking domain & their Mitigation
 Summary
What is Domain in Testing?

Domain is nothing but the industry for which the software testing project is created. When we talk
about software project or development, this term is often referred. For example, Insurance domain,
Banking domain, Retail Domain, Telecom Domain, etc.

Usually, while developing any specific domain project, domain expert help is sought out. Domain ex-
pert are master of the subject, and he may know the inside-out of the product or application.

Why Domain Knowledge Matters?

Domain knowledge is quintessential for testing any software product, and it has its own benefits like

Introduction to Banking Domain

Banking domain is huge, and basically it is sub-characterized into two sectors

1. Traditional banking sector

2. Service based banking sector

Below is the table of the services these two sub-sectors of banking encompass

Manual Testing Notes Page 81

  Core banking
Traditional banking sector  Corporate banking
 Retail banking
 Core
 Corporate
 Retail
 Loan
 Trade finance
Service based banking sector
 Private banking
 Consumer finance
 Islamic banking
 Customer delivery channels/Front end deliv-
ery
Based on the scope of your project you may need to test one or all of the above service offerings. Be-
fore you begin testing, ensure you have enough background on the service being tested.

Characteristics of a Banking Application

Before you begin testing, it's important to note the standard features expected of any banking applic-
ation. So that, you can gear your test efforts to achieve these characteristics.

A standard banking application should meet all these characteristics as mentioned below.
 It should support thousands of concurrent user sessions
 A banking application should integrate with other numerous applications like trading accounts,
Bill pay utility, credit cards, etc.
 It should process fast and secure transactions
 It should include massive storage system.
 To troubleshoot customer issues it should have high auditing capability
 It should handle complex business workflows
 Need to support users on multiple platforms (Mac, Linux, Unix, Windows)
 It should support users from multiple locations
 It should support multi-lingual users
 It should support users on various payment systems (VISA, AMEX, MasterCard)
 It should support multiple service sectors (Loans, Retail banking etc.)
 Foolproof disaster management mechanism

Manual Testing Notes Page 82

Test Phases in Testing Banking Applications

For testing banking applications, different stages of testing include

 Requirement Analysis: It is done by business analyst; requirements for a particular banking ap-
plication are gathered and documented
 Requirement Review: Quality analysts, business analysts, and development leads are involved
in this task. The requirement gathering document is reviewed at this stage, and cross-checked to
ensure that it does not affect the workflow
 Business Requirements Documentation: Business requirements documents are prepared by
quality analysts in which all reviewed business requirements are covered
 Database Testing: It is the most important part of bank application testing. This testing is done
to ensure data integrity, data loading, data migration, stored procedures, and functions validation,
rules testing, etc.
 Integration Testing: Under integration testing all components that are developed are inte-
grated and validated
 Functional Testing: The usual software testing activities like test case preparation, test case re-
view and test case execution is done during this phase
 Security Testing: It ensures that the software does not have any security flaws. During test
preparation, QA team needs to include both negative as well as positive test scenarios so as to
break into the system and report it before any unauthorized individual access it. While to prevent
from hacking, the bank should also implement a multi-layer of access validation like a one-time
password. For security testing, automation tools like IBM AppScan and HPWebInspect are used
while for manual testing tools like Proxy Sniffer, Paros proxy, HTTP watch, etc. are used
 Usability Testing: It ensures that differently able people should be able to use the system as
normal user. For example, ATM with hearing and Braille facility for disabled
 User Acceptance Testing: It is the final stage of testing done by the end users to ensure the
compliance of the application with the real world scenario.
Sample Test Case for Net Banking Login Application

Security is prime for any banking application. Therefore, during test preparation, QA team should in-
clude both negative and positive test scenarios in order to sneak into the system and report for any
vulnerabilities before any unauthorized individual get access to it. It not only involves writing negative
test cases but may also include destructive testing.

Manual Testing Notes Page 83

Following are generic test cases to check any banking application

Sample test cases

For Admin

 Verify Admin login with valid and Invalid data

 verify admin login without data
 verify all admin home links
 verify admin change password with valid and invalid data
 verify admin change password without data
 Verify admin change password with existing data
 verify admin logout
For new Branch

 create a new branch with valid and invalid data

 create a new branch without data
 create a new branch with existing branch data
 verify reset and cancel option
 Update branch with valid and invalid data
 update branch without data
 update branch with existing branch data
 Verify cancel option
 verify branch deletion with and without dependencies
 Verify branch search option
For New Role

 create a new role with valid and invalid data

 create a new role without data
 verify new role with existing data
 verify role description and role types
 Verify cancel and reset option
 Verify role deletion with and without dependency
 verify links in role details page
For customer & Visitors

 Verify all visitor or customer links

 Verify customers login with valid and invalid data

Manual Testing Notes Page 84

  Verify customers login without data
 Verify bankers login without data
 Verify bankers login with valid or invalid data
For New users

 create a new user with valid and invalid data

 create a new user without data
 create a new user with existing branch data
 verify cancel and reset option
 Update user with valid and invalid data
 update user with existing data
 verIFy cancel option
 verify deletion of the user
Challenges in testing Banking domain & their Mitigation

Challenges tester might face during testing banking domain are

Challenge Mitigation
 Ensure that test data meets regulatory
 Getting access to production data and compliances requirements and guidelines
replicating it as test data, for testing is challeng- Maintain the data confidentiality by follow-
ing ing techniques like data masking, synthetic test
data, testing system integration, etc.
 The biggest challenge in testing banking
system is during the migration of the system
from the old system to the new system like  Ensure Data Migration Testing is complete
testing of all the routines, procedures and  Ensure Regression Test cases are executed
plans. Also how the data will be fetched, up- on old and new systems, and the results match.
loaded and transferred to the new system after
migration
 There may be the cases where require-
ments are not documented well and may lead  The test should participate in the project
to functional gaps in test plan right from Requirement Analysis phases and
 Many non-functional requirements are not should actively review the Business Require-
fully documented, and testers do not know ments
whether to test it or not
 The most important point is to check  Compliance or Regulatory Policies testing
Manual Testing Notes Page 85
 whether the said system follows the desired
must be done
policies and procedures
 The scope and the timelines increases as  Ensure Time budget for Integration testing
banking application are integrated with other is accounted if your banking application has
application like internet or mobile banking many external interfaces
Summary

Banking domain is the most vulnerable area for cyber-theft, and safeguarding the software requires
precise testing. This tutorial gives a clear idea of what it takes for banking domain testing and how im-
portant it is. One must understand that -
 Majority of banking software are developed on Mainframe and Unix
 Testing helps to lessen possible glitches encounter during software development
 Proper testing and compliance to industry standards, save companies from penalties
 Good practices help develop good results, reputation and more business for companies
 Both manual and automated testing have respective merits and usability

2) Testing E-commerce Applications

Setting up an E-commerce system is a complex process and subject to many market specific variables.
To maintain the integrity of the E-commerce system, testing becomes compulsory. It helps in the pre-
vention of errors and adds value to the product by ensuring conformity to client requirements.

The objective of testing is to ensure

 Software reliability
Manual Testing Notes Page 86
 Software quality
 System Assurance
 Optimum performance and capacity utilization
In this tutorial we will learn,
 Types of Testing for E-commerce System
 Performance testing- a top priority in E-commerce
 Useful Tools for Mapping E-commerce Site
 Challenges of E-commerce Testing
Types of Testing for E-commerce System

Common type of testing included into e-commerce system are

Sr.# Type of Testing Testing Process
 Lack of support for early browsers
 Browser specific extensions
1 Browser compatibility
 Browser testing should cover main platforms ( Linux,
Windows, Mac etc.)
 Incorrect display of pages
 Runtime error messages
2 Page display
 Poor page download time
 Dead hyperlink, plugin dependency, font sizing, etc.
 Session expiration
3 Session Management
 Session storage
 Non-intuitive design
 Poor site navigation
4 Usability
 Catalog navigation
 Lack of help-support
 Misleading, offensive and litigious content
 Royalty free images and copyright infringement
5 Content Analysis
 Personalization functionality
 Availability 24/7
 Denial of service attacks
6 Availability
 Unacceptable levels of unavailability
 Failure or fall over recovery
7 Back-up and Recovery  Backup failure
 Fault tolerance

Manual Testing Notes Page 87

  Transaction Integrity
8 Transactions  Throughput
 Auditing
 Shopping cart functionality
Shopping order processing and  Order processing
9
purchasing  Payment processing
 Order tracking
 Language support
 Language display
10 Internationalization
 Cultural sensitivity
 Regional Accounting
 How well e-procedure copes
11 Operational business procedures
 Observe for bottlenecks
 Data Interface format
 Interface frequency and activation
12 System Integration  Updates
 Interface volume capacity
 Integrated performance
 Performance bottlenecks
13 Performance  Load handling
 Scalability analysis
 Login capability
 Penetration and access control
 Insecure information transmission
14 Login and Security
 Web attacks
 Computer viruses
 Digital signatures
Performance testing- a top priority in E-commerce

Just delay about 250 milliseconds of a page load time, is what keeps your customer going to your
competitor. Retail giant Walmart overhaul their site speed and noticed an increase of 2% in visitor's
conversion rate and revenue by 1%.

Performance of your site depends on this factors

 Throughput
o Request per second

Manual Testing Notes Page 88

 o Transactions per minute
o Executions per click
 Response Time
o Duration of a task
o Seconds per click
o Page Load
o DNS Lookup
o Length of time between click and seeing page
Useful Tools for Mapping E-commerce Site

 Concept Feedback: Post your website and get feedback from experts
 ClickHeat: It shows the most clicked and unclicked zones of sites by visitors
 FiveSecondTest: This tool ensures that your message is communicated as effectively as possi-
ble, in just five seconds it tells what a person recalls about your website design
 Feedback Army: For your e-commerce site it start a usability test by submitting questions
about your site and receiving 10 responses from reviewers
 Feng-GUI: It simulates the human vision during first five seconds and predicts what a real hu-
man would most likely look at
 Optimizely: It enables you to test track, clicks, conversions or anything else that matters to e-
commerce business
Challenges of E-commerce Testing

 Compliance with security guidelines to safeguard customer data and identity

 Compliance with accessibility standards to support multi-lingual markets and business regions
 End to end testing and test management for large e-commerce transformation programs
 Scalability and reliability of applications
 Compliance with accessibility standards to support multi-lingual markets and business regions

3) Payment Gateway Testing Tutorial with Sample Test Cases

A payment gate-way system is an e-commerce application service that approves credit card payment
for online purchases. Payment gateways safeguard the credit card details by encrypting sensitive in-
formation like credit card numbers, account holder details and so on. This information is passed safely
between the customer and the merchant and vice versa.

Manual Testing Notes Page 89

Modern payment gateways also securely approve payments via debit cards, electronic bank transfers,
cash cards, reward points etc.

In this tutorial we will learn

 Types of Payment Gateway System
 Testing Types for Payment Gateway System
 Test Preparation for Testing Payment Gateway
 Sample Test Cases for Payment Gateway Testing
 Things to consider before Buying Gateway Package

Types of Payment Gateway System

 Hosted Payment Gateway:

Hosted payment gateway system direct customer away from e-commerce site to gateway link dur-
ing payment process. Once the payment is done, it will bring customer back to e-commerce site.
For such type of payment you don't need merchant id, example of hosted payment gateway are
PayPal, Noche and WorldPay.
 Shared Payment Gateway:
In shared payment gateway, while processing payment customer is directed to payment page and
stays on the e-commerce site. Once the payment detail is filled, the payment process proceeds.
Since it does not leave the e-commerce site while processing payment, this mode is easy and more
preferable, example of shared payment gateway is eWay, Stripe.

Testing Types for Payment Gateway System

Testing for Payment Gateway should include

Functional Testing: It is the act of testing base functionality of the payment gateway. It is to verify
whether the application behaves in same way as it is supposed to be like handling orders, calculation,
addition of VAT as per the country etc.

Integration: Test integration with your credit card service.

Manual Testing Notes Page 90

Performance: Identify various performance metrics like highest possible number of users coming
through gateways during specific day and converting them to concurrent users

Security: You need to perform a deep security pass for Payment Gateway.

Test Preparation for Testing Payment Gateway

Before you begin testing -

 Collect proper test data for the dummy credit card number for maestro, visa, master etc.
 Collect payment gateway information like Google wallet, Paypal or else
 Collect payment gateway document with error codes
 Understand the session and parameters passed through application and payment gateway
 Understand and test the amount related information passed through query string or vari-
able or session
 Along with payment gateway language check the language of the application
 Under the various settings of payment gateway like currency format, subscriber data col-
lected.

Sample Test Cases for Payment Gateway Testing

Sr# Test Cases

1 During the payment process try to change the payment gateway language

After successful payment, test all the necessary components, whether it is retrieved
2
or not

4 Check what happens if payment gateway stops responding during payment

5 During the payment process check what happens if session ends

6 During the payment process check what happens in back end

7 Check what happens if payment process fails

8 Check the Data-base entries whether they store credit card details or not

9 During payment process check error pages and security pages

Check settings of pop-up blocker, and see what happens if pop up blocker is on and
10
off

11 Between payment gateway and application check buffer pages

Manual Testing Notes Page 91

 Check on successful payment, a success code is send to the application and a confirm-
12
ation page is show to the user

Verify whether the transaction processes immediately or processing is hand to your

13
bank

14 After successful transaction check if the payment gateway returns to your application

15 Check all format and messages when successful payment process

Unless you don't have an authorization receipt from payment gateway, good should
16
not be shipped

Inform the owner for any transaction processed through e-mail. Encrypt the content
17
of the mail

18 Check the amount format with currency format

19 Check if each of the payment options are selectable

Check if each listed payment option opens the respective payment option according
20
to specification

21 Verify whether the payment gateway defaults to the desired debit/credit card option

22 Verify the default option for debit card shows card selection drop down menu

Things to consider before Buying Gateway Package

 If you have bought a shopping cart package, find out about its compatibility
 If shopping gateway package is due, ask the payment gateway provider for a list of supported
applications
 The gateway must offer Address Verification System Protection
 Find out the types of transaction protection being offered
 Check what types of debit or credit cards are accepted by your chosen payment gateway
 Check the transaction fees levied by payment gateway
 Check whether the gateways collect the payment right on the form or direct to another page
to complete the purchase
Use the comments section below to contribute more test cases on Payment Gateway Testing

Manual Testing Notes Page 92

Manual Testing Notes Page 93
4) Testing for Retail POS (Point Of Sale) System
What is POS software?

POS or Point Of Sale software is a vital solution for retail businesses to carry out retail transactions ef-
fortlessly from anywhere. You must have seen Point of Sale terminal while checking out at your fa-
vourite Mall.

The system is more complex than you think and is tightly integrated with other software systems like
Warehouse, Inventory, purchase order, supply chain, marketing, merchandise planning etc.

In this tutorial, we will learn

 Test Architecture for POS Application
 Types of Testing for POS system
 Sample Test Cases for POS used in Retail
 Security Testing for Retail POS Systems
 Challenges in POS testing
Test Architecture for POS Application

POS test architecture includes three components for testing - POS terminal, store server and enter-
prise server. Basically it is classified into three levels for testing of POS application.

Manual Testing Notes Page 94

 Level 1- (POS Terminal ) Level 2- (Store Server) Level 3- (Enterprise Server)

Device and hardware testing Security Testing Security Testing

(RIFD, Scanner, Printer,

Barcode reader)

Interoperability Testing BI & Analytics Testing BI & Analytics Testing

BI & Analytics Testing Disaster recovery Testing Disaster recovery Testing

Performance Testing Interface Testing Interface Testing

Types of Testing for POS system

Testing of POS System can be broken down into two levels

1. Application Level

2. Enterprise Level

Testing Performed At Application Level Testing Performed At Enterprise Level

 Compliance Testing
 Functionality Testing
 Performance Testing
 Compatibility Testing
 Interoperability Testing
 Payment Gateway Testing
 Data Migration
 Report Testing
 Mobility
Sample Test Cases for POS used in Retail

To ensure quality of the POS system, proper POS software testing is mandatory. The POS testing spans
many things like

Manual Testing Notes Page 95

 Test Cases
Test Scenario

 Test the entry of items purchased by customer is correct

 Test discounts are applied correctly
 Verify store value cards can be used
 Check petty cash management works as expected
Cashier activity
 Check totals and closings match
 Check cash drawer loans are handled properly
 Test the POS system is compatible with peripherals like RFID
Reader, Bar Code Scanner etc.
 Test the validity of CVV number of Credit Card
Payment Gateway Pro-  Test swiping of cards from both sides and chips
cessing  Verify that the captured card details are properly encrypted and
decrypted
 Check for regular sale process
 Check sales can be processed with debit/credit cards
 Check for loyalty membership purchase
 Check for correct prices are displayed for merchandise purchased
 Test for "0" or null transaction
Sales  Tie UPC or bar codes to vendors
 Test for billing details or shipping details in payment manager
 Test for reference transaction
 Test the print format of the receipt generated
 Verify that the correct code is generated for approved, hold or de-
clined transactions
 Make sure the in-house inventory is well integrated with other out-
lets or supply chain
 Check for exchange or return of an item with cash
 Check whether system responds on exchange or return of an item
Return & Exchange scen- with credit card
arios  Check system process the sale with receipt or without receipt
 Verify that system should allow enter bar-code manually incase
scanner don't work
 Verify system display both the current amount as well as discount
amount on exchange of item if applicable

Manual Testing Notes Page 96

  Check for speed or time taken to receive a response or send a re-
quest
 Check the transaction based rules are applicable (discounts/tax/ re-
Performance
bates etc.)
 Verify that the correct code is generated for approved, hold or de-
clined transactions
 Test system with expired card details
 Test with invalid PIN for credit card
 Check the inventory by entering wrong code for the item
Negative Scenarios  Check how system responds while entering wrong invoice number
 Test for negative transaction
 Test the responds of system while entering invalid date for promo-
tional offers on line items
 Test system for various discount like veteran discount, seasonal dis-
count, undergage or overgage discount etc.
 Test system for various promotional offers on certain line items
 Test alert system that notifies end or beginning of seasonal offers
Managing Promotions and
Discounts  Test whether receipt print the exact discount or offers that is lever-
aged
 Test system for allocating wrong offers or discount on line item
 Test the order management process
 Verify product data obtained after scanning barcode is accurate
 Test for system response with incorrect customer data input
 Test system for allowing authorized access to customer's confiden-
Tracking customer's data tial data
 Test the database for recording customer's buying history like
(what they buy, how frequent they buy, etc.)
 Verifying POS system as per regulatory compliances
 Test alert system that notifies security defenders
 Make sure you can void a payment before posting
Security & Regulatory
Compliance  Test user profiles and access levels on the POS Software
 Test database consistency
 Verify specific information about each tender cash, coupon identi-
fier, check number and so on
Report testing  Testing of trend analysis report
 Test information related to credit card transaction should be re-

Manual Testing Notes Page 97

 flected in reports
 Test for individual as well as consolidated reports of customers
buying history
 Test for online report generation
Security Testing for Retail POS Systems

Some recent studies have Point of Sale Systems very high security vulnerabilities. Following measures will help with secur-
ity of POS

 Security testing in compliance with PCI standard is very crucial to be addressed as the part of enterprise testing
 Actively manage all software on the network so that only authorized software can only execute and installed
 Conduct regular penetration testing to identify attack vectors and vulnerabilities
 Include tests for the presence of unprotected system information and artifacts that would be useful to hackers
 Use vulnerability testing tools
 Create a test bed that imitate a production environment for specific penetration tests and attacks against ele-
ments that are not tested in production
Challenges in POS testing

 Multiple Configurations
 Complex interfaces
 Peripheral issues
 Upgrades
 PCI compliance
 Test lab maintenance

Summary

 Retail POS demands high level of testing keeping in mind that its performance and correct functioning directly af-
fect business revenues.
 To reduce the risk and chances of POS failure during transaction process, testing under extreme condition is es-
sential.
 Testing needs to performed at Application as well as Enterprise Level
 Your Testing should cover the following scenarios - Cashier activity, Payment Gateway Processing, Sales, Return &
Exchange scenarios, Performance, Negative Scenarios, Managing Promotions and Discounts, Security & Regulatory
Compliance.
 Multiple configuration settings, peripheral issues, upgrades are few issues you will need to tide over while testing.

5) Testing Insurance Applications with Sample Testcases

Manual Testing Notes Page 98
Insurance Companies rely heavily on Software to run their business. Software Systems helps them to
deal with various insurance activities like developing standard policy forms, handling billing process,
managing customer's data, rendering quality services to the customer, coordinating between
branches and so on.

Though this software is designed to meet the customer's expectations, its durability and consistency
needs to be tested before its actual deployment. Software testing assures the quality of the insurance
software by identifying bugs before go-live.

What is Insurance? Type of Insurance

Insurance is defined as the equitable transfer of the risk of a loss from one entity to another in ex-
change for payment. Insurance Company, which sells the policy is referred as INSURER while the per-
son or company who avails the policy is called the INSURED.

Insurance policies are usually classified into two categories, and insurer buy these policies as per their
requirement and budget.

However, there are other types of insurance that falls under these categories
 Unemployment insurance
 Social Security
 Workers Compensation
What is Premium? How is Premium calculated?

Premium is defined as the amount to be charged for a certain amount of insurance coverage or policy
the insurer has bought.

Premium for the insurance is determined by on the basis of two factors

 The frequency of claims
 The Severity of claims (Cost of each claim)
For example, we will see how insurance system works,

Suppose an insurance company provides insurance to all houses in a village

Home Insurance Amount

Manual Testing Notes Page 99
Total number of house in village = 1000

Value of each house = $ 800

Contribution of each house owner as premium = $ 8

Total Premium Collected = $8000

Statistically, it has calculated that in case of fire a maximum of 10 villages are burnt which it need to
compensate.

So incase, of fire, it will have to pay 10 house $800 which comes $8000 equal to the premium it collec-
ted.

The risk of 10 house owners is spread over 1000 house owner in the village hence reducing the bur-
den on any one of the owner.

In case of no fire in a particular year, the entire sum goes to its profit while if more than 10 houses
burn the insurer will incur a loss.

Testing required in different process area of Insurance

Testing can mitigate the risk of business disruption during and after deployment of software. There
are many branches of an insurance company that requires testing.
 Policy Administration Systems
 Claim Management Systems
 Distribution Management Systems
 Investment Management Systems
 Third party Administration Systems
 Risk Management Solutions
 Regulatory and Compliance
 Actuarial Systems (Valuation & Pricing)

What to Test in Insurance?

The insurance sector is a network of small units that deals directly or indirectly with processing claims.
For smooth functioning of an insurance company, it is necessary that each of this unit is tested rigor-
ously before it is sync together to deliver the desired outcome. The testing includes
 Call Center  IVR integration testing

Manual Testing Notes Page 100

  Call routing and assignment
 Security and access
 Reflexive Questions
 Policy life cycle testing
 Financial and Non-financial policy changes
 Policy lapse and Re-instatement
 Policy Serving
 Policy aging-run cycles
 Premium due alerts
 Valuation of NPV/NAV
 Claims triage and assignment
 Testing claims life cycle
 Claims
 Claims accounting/reserving
 Third party EDI/messaging
 Mobile access
 Direct chan-  Cross browser/cross platform accessibility
nel  Application performance
 Usability of application
 Behaving to regulatory requirements
 Generate quality data for reporting
 Reports/BI
 Create bulk data for roll-up reports
 Testing formula based fields in reports
 Underwriting quality
 Manual and Straight through processing
 Complex business rules
 Underwriting
 Rating efficiency
 Requirements Management (Vendor Interfac-
ing)
 Data integration
 Complex interface integration
 Integration  Source/Destination formats
 Production like interface
 Web service pull/push efficiency
 New Business  Validate rates-factor combinations
 Batch job schedules and runs
 Commissioning calculations settlements
 Quick and detailed quote

Manual Testing Notes Page 101

  Benefit illustration
 Benefit summary validation
 Quick and detailed quote

Sample Test Case for Insurance Application Testing

Sr# Test Cases for Insurance Application

1 Validate claims rule

2 Ensure that claim can occur to the maximum and minimum payment

3 Verify data is transferred accurately to all sub-systems including accounts and reporting.

4 Check that the claims can be processed via all channels example web, mobile, calls, etc

5 Test for 100% coverage and accuracy in calculations determining premium rates

6 Make sure formula for calculating dividend and paid up values gives correct value

7 Verify surrender values are calculated as per the policy requirement

8 Verify fiduciary details and bookkeeping requirements

9 Test complex scenarios for policy lapse and revivals

10 Test various conditions for non-forfeiture value

11 Test scenarios for policy termination

12 Verify general ledger account behave same as to reconcile with subsidiary ledger

13 Test calculation of net liability for valuation

14 Test conditions for extended term insurance

15 Verify policy for a non-forfeiture option

16 Check different insurance product term behaves as expected

17 Verify premium value as per product plan

18 Test automatic messaging system to inform customer about new products

Validate all the data entered by users as it progresses through the workflow to trigger
19
warnings, compliance, notification and other workflow events

20 Verify insurance document template supports the document format like MS-Word

Manual Testing Notes Page 102

21 Test system for generating invoice automatically and send it to customer through e-mail

Summary

Timely process of the insurance policy and managing client's data is a foremost priority for any insur-
ance company. Their complete dependency on a software solution for handling claims, as well as cus-
tomers, requires software solution to be precise and accurate. Considering all the key aspects of in-
surance company's requirement some of the testing strategy and scenarios are represented in this tu-
torial.

6) Healthcare Application Testing with Sample Test Cases

Before we begin testing, let's quickly understand the healthcare industry.

The entire health care system is weaved with each other by the single body that is hospital or provider
(doctor).

While the other entities include-

Manual Testing Notes Page 103

 Insurance company: Medicare, Medicaid, BCBS, etc.
 Patient/Consumers: Patient Enrolled
 Regulatory Authority: HIPAA, OASIS assessment, HCFA 1500 and UB92, etc.
 Health-care and Life-Science solution Vendors
Healthcare Business Process

Most health-care organization have adapted software program to process the smooth functioning of
the system. This software system gives all the information in a single document for each entity dealing
with this.

Interconnecting this whole system to a single web application is a huge task and making it work ef-
fectively is even a bigger task. Rigorous testing of this health application is compulsory, and it has to
go through various testing phases.

In this tutorial, we will learn,

 Basic Terminology of Health Care System
 Testing of Providers system
 Testing of Broker System
 Testing of Member System
 Testing of Claims System
 Testing of Finance System
 Testing under regulatory compliance
 Performance testing of Healthcare Application
 Other Testing Types for Healthcare Application
 Testing Challenges in Healtcare Application
 Healthcare device Testing
 Useful tips for Healthcare Testing
Basic Terminology of Health Care System

 Provider: A health care professional (doctor), medical group, clinic, lab, hospital, etc. licensed
by health care services
 Claim: A request to your health insurance company to pay a bill for health care service
 Broker: An insurance professional, who negotiates, procures insurance on behalf of insured or
prospective insured
 Finance: Insurance bodies that pay for medical expenses, it could be government (Medicare or
Medicaid) or commercial (BCBS)
 Medicare: A federal health insurance program for senior citizen and permanently disabled
people
Manual Testing Notes Page 104
 Medicaid: A joint and state program that helps low-income families and individuals pay for the
cost associated with medical care
 CPT code: A current procedural terminology code is a medical code set to describe medical,
surgical and diagnostic services
 HIPAA: It is a set of rules and regulations which doctors, hospitals, healthcare providers and
health plan must follow in order to provide their services
Testing of Providers system

Sample Test Scenarios and Test cases for providers (doctor/hospital) system:
Test Scenario Test Cases

1. Access to
 Provider system should let us enter, edit and save provider's data
providers system

2. Positive flow  It includes scenarios to enter different types of provider, change providers
system testing details, save and inquire them

3. Negative
 Allows to save a provider information with incomplete data, contract's ef-
flow system
fective date, entering details about existing providers in the system
testing

 Validate the feed to members system, finance system, claim system, and
4. System inte-
provider portal. Also, validate if the changes from provider portal are entered
gration testing
into the respective provider's record

5. Positive flow
 Login and view providers details, claim status, and member details
providers portal
 Make change request to change the name, address, phone number, etc.
testing

6. Negative
 View the member details with an invalid ID
flow providers
 Login with invalid credentials
portal testing

7. Positive flow
 Login and view details about broker and commission payment
Broker portal
 Make request to change the name, address, phone number, etc.
testing

8. Negative
flow Broker por-  It should include scenarios to login with invalid credentials
tal testing

Manual Testing Notes Page 105

Testing of Broker System

Sample Test Scenarios and Test cases for Broker System:

Sr# Test Scenario Test Cases

 It should be capable of edit, enter and save broker data

1) Broker System  Broker commission calculation based on the premium payment de-
tails from member system
 Enter, save and edit brokers record for different types of broker
Positive Flow Sys-
2)  For active brokers calculate the commission by creating feed file
tem Testing
with the respective record for members with different plan
 Enter a broker record with incomplete data and save for different
types of broker
Negative flow Sys-  By creating the feed file with the respective record for members
3)
tem Testing with different plan calculate the commission for the terminated broker
 By creating the feed file with the respective record for members
with different plan calculate the commission for the invalid broker
 To downstream system such as finance system, broker portal and
member system validate the feeds
4) System Testing
 Validate if the changes from broker portal are incorporated in the re-
spective broker record
Testing of Member System

Sample Test Scenarios and Test cases for Member (Patient) System:

Sr# Test Scenario Test Cases

 Enroll, reinstate and terminate a member

 Remove and add a dependent
1) Member system
 Generate premium bill
 Process premium payments
2) Positive Flow System  With current, past and future effective dates enroll different types of
Testing members
 Inquire and change members
 Produce premium bill for an active member for following month
 Terminate an active member with past, current and future termina-
tion dates greater than effective date
 Re-enroll a terminated member with current, past and future effec-

Manual Testing Notes Page 106

 tive dates
 Reinstate a terminated number
 With insufficient data enroll a member
Negative flow system
3)  For a terminated member produce a premium bill for following
testing
month
 Validate the feed to downstream systems such as provider portal,
broker portal, finance system and claim system
System Integration  Validate if the alterations from member portal are incorporated in
4)
Testing the respective member record
 Process the payment of premium bill generated with feed from mem-
bers portal that has details of payment made
Testing of Claims System

Sample Test Scenarios and Test cases for Claims System:

Sr# Test Scenarios Test Cases

 Claims in health-care should edit, enter and process claims for

member as well as dependent
1) Claim System
 For invalid claims, it should throw errors when incorrect data is en-
tered
Positive Flow System  It should include the scenario to edit, enter and process claims for
2)
Testing member as well as dependent
 It should validate and enter a claim with invalid procedure code and
Negative Flow System diagnosis code
3)
Testing  Validate and enter a claim with inactive provider ID
 Validate and enter a claim with terminated member
 It should include scenario to validate the feed to downstream sys-
4) System Integration
tems such as provider and finance portal
Testing of Finance System

Sample Test Scenarios and Test cases for Finance System

Sr# Test Scenarios Test Cases

1) Finance System  Enroll, reinstate and terminate a member

Positive flow sys-  It should check whether correct account number or address is chosen
2)
tem testing for the respective member, provider or broker for the payment

Manual Testing Notes Page 107

  Verify whether payment is done for invalid member, provider or broker
Negative flow sys- ID by creating respective record in the feed
3)
tem testing  Verify whether payment is done for invalid amount for the member,
provider or broker by creating respective records in the feed
Testing for regulatory compliance

Protecting patient sensitive data and health information is an utmost priority for health regulatory
bodies. The testing should be done in compliance of such regulatory bodies.

Sample Test Scenarios and Test cases for Regulatory Compliance:

Sr# Test Scenarios Test Cases

 Using verification method to ensure that correct users get login

1) User's Authentication
and deny to others
 Authorizing access to information is based on user's role and pa-
2) Information Disclosure
tient limitation
3) Data Transfer  At all transfer points ensure that data is encrypted
 All transactions and all attempts to access data with a proper set
4) Audit Trail
of audit trail information are recorded
 Perform sanity testing and verify the encryption of the data is
Sanity Testing related to
5) done in particular areas like EPHI ( Electronic Protected Health Infor-
regulatory body
mation)
Performance testing of Healthcare Application

Before preparing test scenarios certain requirement of the system should be considered. For example,
health-care providers (Doctors/Hospitals) provide care 24/7, so the patient check-in software needs
to be available at all times. Also, it needs to communicate with insurance companies to validate policy
information, send claims and receive remittances. Here, the architecture should define the different
components of the system, the protocol to communicate with insurance companies, and how to de-
ploy the system so that it complies 24/7.

As a tester, you need to ensure that the healthcare software system meets the desired load/perform-
ance benchmark.

Other Testing Types for Healthcare Application

 Functional Testing: Testing healthcare application against functional capabilities

Manual Testing Notes Page 108

 Conformance Testing: Conformance test Healthcare security requisites and industry frame-
works
 Platform Testing: Testing of applications on mobile platform and applications testing for cross-
browser compatibility
 Interoperability Testing: Testing conformance to interoperability standards ( Eg; DICOM, HL7,
CCD/CDA)
Testing Challenges in Healthcare Application

Testing challenges in testing healthcare application are no different than other web application test-
ing.
 Requires expertise in testing, and usually it is high in cost
 Requires interoperability, compliance, regulatory, security, safety testing besides regular testing
techniques (Non-Functional, Functional and Integration testing)
 Testing should be done keeping in mind the safety and regulatory standards- as any error can
cause direct effect on patient's life
 Testing team needs to be well aware of the various functionalities, clinical usage, and the envi-
ronment the software will be used for
 Health-care product should comply with various standards like FDA, ISO and CMMI before it
can be used
 Cross dependency of software- testers need to ensure that any changes in one component or
layer should not lead to side effect on the other.
Healthcare device Testing

While health-care device software is not the direct concern of patient, they also require a rigorous
testing like other software testing. For example, X-ray machines that are controlled by software pro-
grams should be tested well because any testing error in software can lead to a serious effect on the
patient.

FDA (Food and Drug Administration) has guidelines for mobile and web applications for medical
devices. While testing medical devices the proper functional test plan along with pass and fail criteria
is also the part of FDA guidelines. When test plan is executed, the results are collected and reported
to FDA. This process ensures that the device meets the standard of the regulatory bodies.

Useful tips for Healthcare Testing

While testing software, you can consider some important tips for the testing healthcare system.
 Dates are important and needs to be accurate

Manual Testing Notes Page 109

 While designing test cases consider various parameters like different types of plan, brokers,
members, commission, etc.
 Complete knowledge of the domain is required

7) Testing Telecom Application with Sample Testcases

Since the shift of telecom sector to computer network and digital medium, telecommunication sector
has undergone a major software transformation. Telecom started depending on the various types of
software components to deliver many services like routing and switching, VoIP broadband access, etc.
Hence, that telecom testing has become an inevitable process.

Business Processes in Telecom Industry

For telecom testing end-to-end service verification is important. To ensure efficient testing a good un-
derstanding of different Business process is a must.

You need to understand each stage of service deliverability before drafting the test cases.

Telecom services are either based on a business support system that includes IVR's, Call Centers, gen-
erating invoices, etc. or an operation support system that includes routers, switches, cell towers, etc.

The following table shows what activities are performed at different levels

Manual Testing Notes Page 110

Telecom Depart-
Telecom Activities
ment

Pre-sales  It handles all the sales information like discounts, services, promos, etc.

Ordering  Applying for a new connection or disconnecting a connection

 This division deals with the physical connection between customers and
Provisioning
TSP ( Telecom Service Provider)
Billing  Under this division, all billing work is done

Service Assurance  In case of any failure, this division corrects the problem

Inventory Systems  It is the repository of all information

Tracking  This division tracks the ordering system and the status of an order

Typical Telecom Business Process

Following is a typical business process in the Telecom Industry.

Types of Protocols used in Telecom Industry

Here the popular protocols used in the Telecom industry

 VoIP technologies: VoIP, IMS, MPLS, ISDN, PSTN
 Signaling and Protocols: SIP, ISDN, Codecs, H.323
 Wireless technologies: GPRS, CDMA, GSM, UMTS
 Network Management: SNMP
 Layer 2 Protocols: ARP, STP, L2TP, PPP
 Layer 3 protocols/routing: ICMP, BGP, ISIS, MPLS
 Infrastructure/Security: ATM, TCP/IP, LAN/VLAN, SSH
You can learn more about Protocol Testing here

Testing LifeCycle in the Telecom Industry

The Test Lifecycle in the telecom industry is similar to that of any other industry but with a stress on de-
tails. Here is how the test lifecycle looks like along with the test artifacts.

Manual Testing Notes Page 111

 Telecom Testing Stage Test artifacts

 Requirement based test artifacts

 Feasibility based artifacts
 Business View
 Standard and policy identification based test artifacts
 Operation and maintenance considerations related test artifacts
 System test artifacts (Security, Installation)
 System/ Architec-  Test artifacts for virtual prototype
ture  Special system testing artifacts ( interoperability, disaster recov-
ery)
 Unit test artifacts
 Integration test artifacts
 Implementation
 Quality and performance artifacts
 Regression, load testing, sanity, etc.
 Acceptance test artifacts
 Integration test artifacts
 Deployment  Quality and performance artifacts
 Functional test artifacts
 Alpha/Beta test artifacts
Types of Testing Performed on Telecom Software

 Interconnection Testing
 Conformance Testing
 IVR Testing
 Performance Testing
 Security Testing
 Interoperability Testing
 Protocol Testing
 Functional Testing
 Automation Testing
Sample TestCases for Telecom Testing

In Telecom Testing, one must consider testing following

Various Telecom Testing Testing activities in Telecom

Billing System  Verify, the telephone number of the customer, is registered un-
der telecom operator

Manual Testing Notes Page 112

  Verify whether number is still working
 Verify the number entered is valid, and it is 10 digit number
 Verify the number is not blocked due to some reasons
 Verify if the number has any outstanding bills, if exist, display it
on screen
 Verify the number has all previous accounts or bills cleared
 Verify the system enables statement generation as per cus-
tomer requirement
 Verify the system has recorded number of calls accurately
 Verify the plan chosen by the customer displays on the billing
system
 Verify the total amount billed is accurate and mapped to the
service offered
 Protocols, signaling, field testing for IOT
 Usage and functional testing for core mobile handset applica-
Application Testing tions like call, SMS, transfer/hold, etc.
 Testing of various applications like finance, sports and location
based services, etc. OSS-BSS testing
 Billing, customer case, interconnect billing, order and fraud
management, revenue assurance
OSS-BSS Testing
 Network management, mediation, provisioning, etc.
 EAI, CRM & ERP, data warehousing, etc.
 Electrical interface compatibility
Conformance Testing  Conformance of protocol
 Conformance of transport layers
 Interactive test scenarios
 Detection of voice energy
IVR Testing  Broadband audio tones
 Extensive conditional branching sequences
 DTMF Entries
Summary

The telecom service is a very broad field consists of various component including cables, networks,
signals, protocols, etc. and their testing requires broad range of testing techniques, so the choice of
testing techniques and strategy highly depends on what component of telecom is tested.

Manual Testing Notes Page 113

The test requirement, scope, test scenarios, testing techniques, testing tools, etc. varies with the type
of testing involves, it can be protocol testing for VoIP or wireless device testing for CDMA. The tutorial
gives basic but complete overview of how telecom testing can be performed and discuss various pro-
spects that are crucial for telecom testing.

SECURITY TESTING

Manual Testing Notes Page 114

What is Security Testing?
Software industry has achieved a solid recognition in this age. In the recent decade, however, cyber-
world seems to be even more dominating and driving force which is shaping up the new forms of
almost every business. Web based ERP systems used today are the best evidence that IT has
revolutionized our beloved global village.

These days, websites are not meant only for publicity or marketing but these have been evolved into
the stronger tools to cater complete business needs. Web based Payroll systems, Shopping Malls,
Banking, Stock Trade application are not only being used by organizations but are also being sold as
products today.

This means that online applications have gained the trust of customers and users regarding their vital
feature named as SECURITY. No doubt, the security factor is of primary value for desktop applications
too. However, when we talk about web, importance of security increases exponentially. If an online
system cannot protect the transaction data, no one will ever think of using it. Security is neither a
word in search of its definition yet, nor is it a subtle concept. However, I would like to list some
complements of security.

Manual Testing Notes Page 115

Examples of security flaws in an application:

1) A Student Management System is insecure if ‘Admission’ branch can edit the data of ‘Exam’ branch
2) An ERP system is not secure if DEO (data entry operator) can generate ‘Reports’
3) An online Shopping Mall has no security if customer’s Credit Card Detail is not encrypted
4) A custom software possess inadequate security if an SQL query retrieves actual passwords of its
users
Security Testing Definition:
Now, I present you a simplest definition of Security in my own words. “Security means that
authorized access is granted to protected data and unauthorized access is restricted”. So, it has two
major aspects; first is protection of data and second one is access to that data. Moreover, whether the
application is desktop or web based, security revolves around the two aforementioned aspects. Let us
have an overview of security aspects for both desktop and web based software applications.
Desktop and Web Security Testing:
A desktop application should be secure not only regarding its access but also with respect to
organization and storage of its data. Similarly, a web application demands even more security with
respect to its access, along with data protection. Web developer should make the application immune
to SQL Injections, Brute Force Attacks and XSS (cross site scripting). Similarly, if the web application
facilitates remote access points then these must be secure too. Moreover, keep in mind that Brute
Force Attack is not only related to web applications, desktop software is also vulnerable to this.
I hope this foreword is enough and now let me come to the point. Kindly accept my apology if you so
far thought that you are reading about the subject of this article. Though I have briefly explained
software Security and its major concerns, but my topic is ‘Security Testing’. In order to know further
details of security aspects, kindly refer to – Web application security testing article.
I will now explain how the features of security are implemented in software application and how
should these be tested. My focus will be on Whats and Hows of security testing, not of security.

Security Testing Techniques:

1) Access to Application:
Whether it is a desktop application of website, access security is implemented by ‘Roles and Rights
Management’. It is often done implicitly while covering functionality, [Link] a Hospital Management
System a receptionist is least concerned about the laboratory tests as his job is to just register the
patients and schedule their appointments with doctors. So, all the menus, forms and screen related to
lab tests will not be available to the Role of ‘Receptionist’. Hence, the proper implementation of roles
and rights will guarantee the security of access.

Manual Testing Notes Page 116

How to Test: In order to test this, thorough testing of all roles and rights should be performed. Tester
should create several user accounts with different as well multiple roles. Then he should use the
application with the help of these accounts and should verify that every role has access to its own
modules, screens, forms and menus only. If tester finds any conflict, he should log a security issue with
complete confidence.

2. Data Protection:

There are further three aspects of data security. First one is that a user can view or utilize only the
data which he is supposed to use. This is also ensured by roles and rights e.g. a TSR (telesales
representative) of a company can view the data of available stock, but cannot see how much raw
material was purchased for production.
So, testing of this aspect is already explained above. The second aspect of data protection is related
to how that data is stored in the DB. All the sensitive data must be encrypted to make it secure.
Encryption should be strong especially for sensitive data like passwords of user accounts, credit card
numbers or other business critical information. Third and last aspect is extension of this second
aspect. Proper security measures must be adopted when flow of sensitive or business critical data
occurs. Whether this data floats between different modules of same application, or is transmitted to
different applications it must be encrypted to make it safe.
How to Test Data Protection: The tester should query the database for ‘passwords’ of user account,
billing information of clients, other business critical and sensitive data and should verify that all such
data is saved in encrypted form in the DB. Similarly (s)he must verify that between different forms or
screens, data is transmitted after proper encryption. Moreover, tester should ensure that the
encrypted data is properly decrypted at the destination. Special attention should be paid on different
‘submit’ actions. The tester must verify that when the information is being transmitted between client
and server, it is not displayed in the address bar of web browser in understandable format. If any of
these verifications fail, the application definitely has security flaw.

3. Brute-Force Attack:

Brute Force Attack is mostly done by some software tools. The concept is that using a valid user ID,
software attempts to guess the associated password by trying to login again and again. A simple
example of security against such attack is account suspension for a short period of time as all the
mailing applications like ‘Yahoo’ and ‘Hotmail’ do. If, a specific number of consecutive attempts
(mostly 3) fail to login successfully, then that account is blocked for some time (30 minutes to 24 hrs).

How to test Brute-Force Attack: The tester must verify that some mechanism of account suspension is

Manual Testing Notes Page 117

available and is working accurately. (S)He must attempt to login with invalid user IDs and Passwords
alternatively to make sure that software application blocks the accounts that continuously attempt
login with invalid information. If the application is doing so, it is secure against brute-force attack.
Otherwise, this security vulnerability must be reported by the tester.
The above three security aspects should be taken into account for both web and desktop
applications while, the following points are related with web based applications only.

4. SQL Injection and XSS (cross site scripting):

Conceptually speaking, the theme of both these hacking attempts is similar, so these are discussed
together. In this approach, malicious script is used by the hackers in order to manipulate a website.
There are several ways to immune against such attempts. For all input fields of the website, field
lengths should be defined small enough to restrict input of any script e.g. Last Name should have field
length 30 instead of 255. There may be some input fields where large data input is necessary, for such
fields proper validation of input should be performed prior to saving that data in the application.
Moreover, in such fields any html tags or script tag input must be prohibited. In order to provoke XSS
attacks, the application should discard script redirects from unknown or untrusted applications.
How to test SQL Injection and XSS: Tester must ensure that maximum lengths of all input fields are
defined and implemented. (S)He should also ensure that defined length of input fields does not
accommodate any script input as well as tag input. Both these can be easily tested e.g. if 20 is the
maximum length specified for ‘Name’ field; and input string
“<p>thequickbrownfoxjumpsoverthelazydog” can verify both these constraints. It should also be
verified by the tester that application does not support anonymous access methods. In case any of
these vulnerabilities exists, the application is in danger.

5. Service Access Points (Sealed and Secure Open)

Today, businesses depend and collaborate with each other, same holds good for applications especially
websites. In such case, both the collaborators should define and publish some access points for each
other. So far the scenario seems quite simple and straightforward but, for some web based product
like stock trading, things are not so simple and easy. When there is large number of target audience,
the access points should be open enough to facilitate all users, accommodating enough to fulfill all
users’ requests and secure enough to cope with any security-trial.

How to Test Service Access Points: Let me explain it with the example of stock trading web
application; an investor (who wants to purchase the shares) should have access to current and
historical data of stock prices. User should be given the facility to download this historical data. This
demands that application should be open enough. By accommodating and secure, I mean that

Manual Testing Notes Page 118

application should facilitate investors to trade freely (under the legislative regulations). They may
purchase or sale 24/7 and the data of transactions must be immune to any hacking attack. Moreover,
a large number of users will be interacting with application simultaneously, so the application should
provide enough number access point to entertain all the users.
In some cases these access points can be sealed for unwanted applications or people. This depends
upon the business domain of application and its users, e.g. a custom web based Office Management
System may recognize its users on the basis of IP Addresses and denies to establish a connection with
all other systems (applications) that do not lie in the range of valid IPs for that application.
Tester must ensure that all the inter-network and intra-network access to the application is from
trusted applications, machines (IPs) and users. In order to verify that an open access point is secure
enough, tester must try to access it from different machines having both trusted and untrusted IP
addresses. Different sort of real-time transactions should be tried in a bulk to have a good confidence
of application’s performance. By doing so, the capacity of access points of the application will also be
observed clearly.
Tester must ensure that the application entertains all the communication requests from trusted IPs
and applications only while all the other request are rejected. Similarly, if the application has some
open access point, then tester should ensure that it allows (if required) uploading of data by users in
secure way. By this secure way I mean, the file size limit, file type restriction and scanning of uploaded
file for viruses or other security threats. This is all how a tester can verify the security of an application
with respect to its access points.

Manual Testing Notes Page 119

 Top 20 API Testing Interview Questions

Manual Testing Notes Page 120

1) What is API testing?
API (Application Programming Interface) specifies how some software components should
interact with other, in other words it’s a set of functions and procedures that allows the creation of
applications which access the features or data of an application or operating system. Testing of these
functions is known as API testing.

2) What are the tools used for API testing?

The tools used for various API testing are
SoapUI Pro
LoadUI Pro
Alertsite API monitoring

3) What are the common tests performed on API’s?

The common tests performed on API’s
Verification of the API whether it is updating any data structure
Verify if the API does not return anything
Based on input conditions, returned values from the API’s are checked
Verification of the API whether it triggers some other event or calls another API

4) Mention the key difference between UI level testing and API testing?
UI ( User Interface) refers to testing graphical interface such as how user interacts with the
applications, testing application elements like fonts, images, layouts etc. UI testing basically
focuses on look and feel of an application. While, API enables communication between two separate
software systems. A software system implementing an API contains functions or sub-routines that can
Manual Testing Notes Page 121
be executed by another software system

5) Explain what is SOAP?

SOAP-stands for Simple Object Access Control, and it is an XML based protocol for exchanging
information between computers.

6) Explain what is REST API?

It is a set of functions to which the developers performs requests and receive responses. In
REST API interaction is made via HTTP protocol
REST – stands for Representational State Transfer, it is quickly becoming defacto standard for API
creation.

7) Difference API and Unit Testing?

API testing

1) API is owned by QA team

2) API is mostly black box testing

3) Full functionality of the system is

considered in API testing as it will
be used by the end-user (external
developers who will use your API)

4) API test are often run after the build is ready

and authors do not have access to the source
code

UNIT testing

1) Unit testing is owned by development team

2) Unit testing is white box testing

3) Unit testing is done to verify whether each unit in

isolation performs as expected or not

Manual Testing Notes Page 122

4) For each of their module the developers are
expected to build unit tests for each of their
code modules and have to ensure that each
module pass unit test before the code is
included in a build

8) How to test API’s ?

To test the API’s you should follow the following steps
Select the suite in which you want to add the API test case
Choose test development mode
Develop test cases for the desired API methods
Configure application control parameters
Configure test conditions
Configure method validation
Execute API test
View test reports
Filter API test cases
Sequence API test cases

9) Mention what the main areas to be taken in consideration while writing API document
?
The key area to be considered when writing API documents are
Source of the content
Document plan or sketch
Delivery layout
Information required for each function in the document
Automatic document creation programs
10) In API document explain how to document each function ?What are the tools used for
documentation?
Description: Small description about what a function does
Syntax: Syntax about the parameter of the code, the sequence in which they occur,
required and optional elements etc.
Parameters: Functions parameters
Error Messages: Syntax of error messages
Example Code: Small snippet of code
Related Links: Related functions
Popular tools used for API documentations are JavaDoc (for Java code ) Doxygen (for .Net
code)

11) Explain API framework?

API framework is self-explanatory. Values for test run and for holding the configurable parts,
config file is used. Automated test cases must represent in “ parse-table” format within configfile.
When testing API, it is not necessary to test each API so the config file have some section whose all

Manual Testing Notes Page 123

API are activated for that specific run.
12) How does the API Builder work?
API Builder is a PLSQL program consists of four SQL files
For setting API parameters and starting the process one file is responsible
Two files are created for temporary tables and Master package to create the outputted
code
Fourth file creates “spooled” output of the code into a file called “output_script_.sql”

13) Explain what is TestApi ?

TestApi is a library of utility and test APIs that enables testers and developers to create testing tools
and automated tests for .NET and Win32 application. It provides a set of common test building blocks,
types, data-structure and algorithms.

14) What is Input injection and what are different ways of doing it ?
Input Injection: It is the act of simulating user input, in several ways you can simulate user
input.
Direct Method Invocation
Invocation using an accessibility interface
Simulation using low-level input
Simulation using a device driver
Simulation using a robot
15) What are the main challenges of API testing?
The main challenges in API testing is
Parameter Selection
Parameter Combination
Call sequencing

16) What is API testing with runscope ?

Runscope is a web application that provides backend services and easy to use interface for
testing APIs.

17) Explain what are the principles of API test design?

The principle for API test design are
Setup : Create objects, start services, initialize data etc
Execution: Steps to exercise API or scenario, also logging
Verification: Oracles to evaluate execution outcome
Reporting: Pass, failed or blocked
Clean up: Pre-test state

18) What are the types of Bugs will API testing finds?
The types of Bugs, API will find
Missing or duplicate functionality
Fails to handle error conditions gracefully
Stress
Reliability

Manual Testing Notes Page 124

Security
Unused flags
Not implemented errors
Inconsistent error handling
Performance
Multi-threading issues
Improper errors

19) What are the tools used for API test automation?
While testing Unit and API testing, both target source code, if an API method is using code
based on .NET then the tool which is supporting should have .NET
Automation tools for API testing can be used are
NUnit for .NET
JUnit for Java
HP UFT
Soap UI

20) Mention the steps for testing API ?

API testing steps
Select the test case that has to be fulfilled
For API call develop a test case
To meet the test case configure the API parameters
Determine how will you validate a successful test
Using programming language like PHP or .NET execute the API call
Allow the API call to return the data to validate
21) What are the common protocols that are testing in API tesing ?
HTTP
JMS
REST
SOAP
UDDI

Manual Testing Notes Page 125

 QA Interview Questions
1. Can you tell me about yourself?
Answer: In my QA career, I have been working on various system platforms and operating systems like Windows
95, Windows 2000, Windows XP and UNIX. I have tested applications developed in Java, C++, Visual Basic and
so on. I have tested Web-based applications as well as client server applications.
As a QA person, I have written Test Plans, Test Cases, attended walkthrough meetings with the Business
Analysts, Project Managers, Business Managers and QA Leads. Attended requirement review meetings and
provided feedback to the Business Analysts. I have worked in different databases like Oracle and DB2, wrote
SQL queries to retrieve data from the database.
As far as different types of testing is concerned, I have performed Smoke Testing, Functional Testing, Backend
Testing, BlackBox Testing, Integration Testing, Regression Testing and UAT (User Acceptance Testing) Testing. I
have participated in Load Testing and Stress Testing.
I have written defects as they are found using ClearQuest and TestDirector. Once the defects were fixed,
retested them and if the passed, closed them. If the defects were not fixed, then reopened them. I have also
attended the defect assessment meetings as necessary.
In the meantime, a continuous interaction with developers was necessary.
This is pretty much what I have been doing as a QA person.

2. What did you do in your last project?

In my last project, the application was a web-based application developed in Java platform. As a QA Person, I
wrote Test Plans from the requirement documents and Use Cases. I performed Smoke Testing, Functional
Testing, Backend Testing, BlackBox Testing, Integration Testing, Regression Testing and UAT (User Acceptance
Testing). I have participated in Load Testing and Stress Testing. I attended several walkthrough meetings for
requirement reviews and provided feedback to the Business Analysts. Mostly, I was in the backend testing,
which required writing SQL queries directly to the database.
Manual Testing Notes Page 126
Besides these, I wrote defects using ClearQuest. Once the defects were fixed, retested them and if the passed,
closed them. If the defects were not fixed, then reopened them.

3. Have you written Test Plan? What is a Test Plan? What does it include?
Yes.
What is a Test Plan?
A Test Plan is a document describing the scope, approach, resources, and schedule of intended testing
activities. It identifies test items, the features to be tested, the testing tasks and who will do each task (roles
and responsibilities) and any risks and its solutions.
What does it include? A Test Plan includes Heading, Revision History, Table of Contents, Introduction, Scope,
Approach, Overview, different types of testing that will be carried out, what software and hardware will be
required, issues, risks, assumptions and sign off section.
Click here to see how a complete Test_Plan_Sample looks like.

4. Have you written a Test Case?

Yes.
What is a Test Case? What does it include?
A Test Case is a document that describes step by step process how to test the application. A Test Case includes
Test Case ID, Steps Description, Expected Output, Actual Output, Pass/Fail, Remarks.
Click here to see how a complete Test Case looks like.
5. How many Test Cases did you write in your last project?
Answer: I wrote about 1100 Test Cases in my last project. (The reasonable number of Test Cases varies from
500 to thousands. The number 1100 test cases can be completed in a 6 month project duration).
6. What document did you refer to write the Test Cases?
Requirement document. (NOTE: It can also be Use Cases, or Design Document)
(Note: It depends company to company. In some companies, they use Use Cases. In some companies, they use
Requirement Documents and in some companies, they use Design Document. However, in practical scenario,
most of the companies have requirement document at least). This is the sample Requirement Document for
Mercury Tours.

7. Did you have a situation where you did not have any documents (no requirement document, no Use
Cases, or no Design Document) and you had to write the Test Cases? How did you write the Test Cases?
Yes. I have been to that kind of scenarios several times. There were companies where they had no documents
at all. In that case, I had to discuss the application scenario and functionalities with the Business Analysts or
developer. I kind of prepared a document in consultation with Business Analysts and Developers and then
started writing Test Cases.

8. Have you worked with the Uses Cases before?

Yes. I have written Test Cases using Use Cases.
Can you tell me what a Use Case is?
A use case is a document that describes the user action and system response for a particular functionality. (you
can also include, For example, in the Use Case given below, is a Use Case for login system for a company called
Auto Parts One. This application is being developed by Digital Systems, Inc. The project name is Auto Parts One.
However, the business owner (user) is a company called American Auto Parts of the North (imaginary name). Or
What is a Use Case and what does it include?
A Use Case is a document that describes the user action and system response for a particular functionality. It
includes cover page, Revision History, Table of Contents, Floe of Events (normal flow and alternative flow),
Exceptions, Special Requirements, Pre-conditions and Post-conditions.
Please see the Use Case: Click this link: 2. Use_Case_SampleThis is how it looks (Next Page) (coming soon)For

Manual Testing Notes Page 127

the complete Use Case sample, click here. (coming soon)
Now, Let us write Test Cases based on this Use Case. Remember, one Use Case can have many Test Cases. For
example, look below:
For a complete Test Case for [Link], please click here.

9. What is Software Development Life Cycle?

The systems (or software) development life cycle (SDLC) is a conceptual model used in project management
that describes the stages involved in an information system development project, from an initial feasibility
study through maintenance of the completed application.
It includes the following different stages:
1. Requirement phase
2. Design phase
3. Coding (programming)
4. Testing
5. Release (Production)
6. Maintenance (Support)
10. What is Business Requirement Document (BRD)?
It is a document that describes the details of the application functionalities which is required by the user. This
document is written by the Business Analysts.
What is Software Testing Life Cycle (STLC)?

The testing of software has its own life cycle. It starts with study and analyzing the requirements. Here is the
software testing life cycle:
1. Requirement Study
2. Test Planning
3. Writing Test Cases
4. Review the Test Cases
5. Executing the Test Cases
6. Bug logging and tracking
7. Close or Reopen bugs
To see the diagram click here.
What is Business Design Document?
It is the document which describes the application functionalities of the user in detail. This document is the
further details of the Business Requirement Document. This is a very crucial step in the SDLC. Sometimes the
Business Requirement Document and Business Design Document can be lumped together to make only one
Business Requirement Document.
What is Code Generation or Program?
Coding is the process of translating the Business Design Document into the machine readable form. If the
design is done in detailed manner, the Code Generation can be done without much application. Programming
tools like Compilers, Interpreters and Debuggers are used to generate the code thru different high level
language like C, C++, Pascal, Java.

11. What is a Module?

A ‘Module’ is a software component that has a specific task. It can be a ‘link’ which can go inside to its
component detail.

12. What is meant by Walk-thru meeting?

Manual Testing Notes Page 128

Before start working in a module and/or after accomplishing the testing of a module, the tester calls a meeting
to disseminate his findings or to share his queries to other tester or leads of the company working on the same
application that is called the Walk-thru meeting.

13. What is Build?

When each of the different modules of software is prepared, they are put in a single folder by the Configuration
Management Team (CMT) and it is called the ‘Build’. In other word, the developers put their code in the shared
location (folder) and all those code (modules) are combined together so that it is a complete application that
works.
What is meant by the Build Deployment?
When the Build so prepared by the CMT is sent to different Test Environments, it is called the Build
Deployment.

14. What is Test Strategy?

A test strategy is an outline that describes the testing portion of the software development cycle. It is created to
inform project managers, testers, and developers about some key issues of the testing process. This includes
the testing objective, methods of testing new functions, total time and resources required for the project, and
the testing environment.
The test strategy describes how the product risks of the stakeholders are mitigated at the test-level, which types
of test are to be performed, and which entry and exit criteria apply. (source: Wikipedia)
The test strategy is created based on development design documents.. It is written by the Test Manager or
Lead.

The following are some of the components that the Test Strategy includes:
1 Test Levels. 2 Roles and Responsibilities. 3 Environment Requirements. 4 Testing Tools. 5 Risks and
Mitigation. 6 Test Schedule. 7 Regression Test Approach. 8 Test Groups. 9 Test Priorities. 10 Test Status
Collections and Reporting. 11 Test Records Maintenance. 12 Requirements traceability matrix. 13 Test Summary
Click here to see how the Test Strategy looks like.
Are Test Plan and Test Strategy same type of document?
No. They are different documents. Test Plan is a document that collects and organizes test cases by functional
areas and/or types of testing in a form that can be presented to the other teams and/or customer where as the
Test Strategy is the documented approach to testing. Test Plan is prepared by the tester whereas the Test
Strategy is prepared by the QA Manager or QA lead.
Both are important pieces of Quality Assurance processes since they help communicate the test approach
scope and ensure test coverage while improving the efficiency of the testing effort.

15. What does the Test Strategy include?

It includes introduction, scope, resource and schedule for test activities, acceptance criteria, test environment,
test tools, test priorities, test planning, executing a test pass and types of test to be performed.

16. What are different types of software testing?

Different types of testing carried out are:
1) Unit testing
2) Shakeout testing
3) Smoke testing (Ad-hoc testing)
4) Functional testing
5) Integration testing
6) Regression testing

Manual Testing Notes Page 129

7) System testing
8) Load testing
9) Stress testing
10) Performance testing
11) User acceptance testing
12) Black box testing
13) White box testing
14) Alpha testing
15) Beta testing
Note: Except the Shakeout testing and Unit testing which are respectively done by the CMT and
Coder/Developer, all other testing are done by the QA Engineer (Tester).
1) Unit testing: It is a test to check the code whether it is properly working or not as per the requirement. It is
done by the developers (Not testers).
2) Shakeout testing: This test is basically carried out to check the networking facility, database connectivity and
the integration of modules. (It is done by the Configuration Team)
3) Smoke testing: It is an initial set of test to check whether the major functionalities are working or not and
also to check the major breakdowns in the application. It is the preliminary test carried out by the SQA tester.
4) Functional testing: al It is a test to check whether each and every functionality of that application is working
as per the requirement. It is major test where 80% of the tests are done. In this test, the Test Cases are
‘executed’.
5) Integration testing: It is a test to check whether all the modules are combined together or not and working
successfully as specified in the requirement document.
6) Regression testing: When a functionality is added to an application, we need to make sure that the newly
added functionality does not break the application. In order to make it sure, we perform a repeated testing
which is called Regression Testing. We also do regression testing after the developers fix the bugs. See the
video below for more understanding. (Courtesy of [Link]).
7) System testing: Testing which is based on overall requirements specification and it covers all combined parts
of a system. It is also a black box type of testing.
8) Load testing: It is a test to check the user’s response time of number of users using any one scenario (single
business process) of the same application at the same time.
9) Stress testing: In this type of testing the application is tested against heavy load such as complex numerical
values, large number of inputs, large number of queries etc. which checks for the stress/load the applications
can withstand.
10) Performance testing: It is a test to check the user’s response time of number of users using multiple
scenarios (multiple business process) of the same application at the same time.
11) User acceptance testing: In this type of testing, the software is handed over to the user in order to find out
if the software meets the user expectations and works as it is expected to.
12) Black box testing: It is test where a tester performs testing without looking into the code. OR A testing
method where the application under test is viewed as a black box and the internal behavior of the program is
completely ignored. Testing occurs based upon the external specifications. Also known as behavioral testing,
since only the external behavior of the program is evaluated and analyzed.
13) White box testing: It is a test where a tester looks into the code and performs the testing.
14) Alpha testing: In this type of testing, the users are invited at the development center where they use the
application and the developers note every particular input or action carried out by the user. Any type of
abnormal behavior of the system is noted and rectified by the developers.
15) Beta testing: In this type of testing, the software is distributed as a beta version to the users and users test
the application at their sites. As the users explore the software, in case if any exception/defect occurs that is
reported to the developers.
What is Negative Testing?

Manual Testing Notes Page 130

Testing the system or application using negative data is called negative testing, for example, testing password
entering 6 characters where it should be 8 characters should display a message.
When we test an application by putting negative values (instead of actual values), then the system should not
allow the other values rather than the actual value. The system should give an message that the value is not
correct. This is called negative testing.
Another example is, if a user tries to type a letter in a numeric field, the correct behavior in this case would be
to display the “Incorrect data type, please enter a number” message. The purpose of negative testing is to
detect such situations and prevent applications from crashing. Also, negative testing helps you improve the
quality of your application and find its weak points. (source: Jerry Ruban)
What is the difference between Load Testing and Performance Testing?
Basically Load, Stress and Performance Testing are the same. However, Load testing is the test to check the
users’ response time of number of users of any one scenario of the application whereas Performance Testing is
the test to check the user response time for multiple scenario of the same application.

17. What was the process of QA testing in your company where you worked for the last time? (or As far as
the QA process is involved, what was the testing process in your company?)
The QA testing process that was followed in my last company where I worked was like this: First of all the
Business Requirement Document was prepared as per the client’s requirement (with the muck-up screen
shots). Then on the basis of the requirement document, Test Strategy, Test Plans and Test Cases were written in
sequential order. Once the Build is made and deployed to the different testing environments where different
types of testing were performed to check whether there are any defects.

18. What is SQL?

SQL stands for Structured Query Language. SQL is an ANSI (American National Standards Institute) standard
computer language for accessing and manipulating database systems. SQL statements are used to retrieve and
update data in a database. SQL works with database programs like MS Access, DB2, Informix, MS SQL Server,
Oracle, Sybase, etc.
Unfortunately, there are many different versions of the SQL language, but to be in compliance with the ANSI
standard, they must support the same major keywords in a similar manner (such as SELECT, UPDATE, DELETE,
INSERT, WHERE, and others).
Note: Most of the SQL database programs also have their own proprietary extensions in addition to the SQL
standard.
Where do you write SQL query?
We write SQL queries using some these tools: Todd, Squirrel and Rapid SQL.
Do you really need to write SQL as a QA Engineer?
Yes. You need to. No matter whether it is a small company or big, they have a database and you need to
validate the data by writing SQL queries going into the database. The stronger you are in SQL, the better the
chance of getting a job.
What are the basic commands in SQL+?
They are:
SQL>select *from tab; -to directory of database tables
SQL>ed -to edit the queries in the notepad
SQL>/ -to run or execute the query command
SQL>create table ‘table name’ -to create a table
SQL>desc ‘table name’ -to display table with column name with type
SQL>alter table ‘table name’ -to add a columnadd ‘column name’ ‘type’
SQL>alter table ‘table name’ -to modify the name and type of a columnmodify ‘column name’ ‘type’

Manual Testing Notes Page 131

What is the most common syntax you have used while writing SQL query?
Answer: SELECT
What is a Primary Key?
In a database table, the Primary Key is a column which has a unique value for each of the row within that
column. It can’t have NULL value.
What is a Unique Key?
In a database table, the Unique Key is a column which may or may not have null value of each of the row within
that column.
What is Data?
Data is number, character or image which has some information.
What is Database?
It is collection of logically related data designed in a tabular form to meet the information needs of one or more
users.
19. What is Change Control (OR Change Request)?
Answer: It is a document that describes the additional functionalities that are added after the Business
Requirement Document is signed off. It can be updated in the old business requirement document or it can be a
separate document.
(For example, in the Business Requirement Document, on the login page, there are User Name and Password
fields. The owner of the software wants to add, “If you do not have User Name and Password, please click
here.” This is a change. But this change came after the document is signed off by the Project Managers. Now
this is a change control and comes as a separate document. (It is also called Change Request, Modification
Request).

20. Have you written Change Control?

Answer: Yes. There was a situation where in one page of an application in my previous project, when the user
clicked “Contact” link, it would pop up a different window (new separate window). But it was NOT the way it
was described in the requirement document. In the requirement document, when the user clicks “Contact”
link, then it should navigate to another page (Not a separate new window. Then was it a problem? Functionality
wise, it was NOT a problem, however, on all the other pages, when the user clicked “Contact” link, the system
would navigate to next page (not a separate window). So, it was NOT CONSISTENT with the other functionalities
on the other pages. Therefore, it was a consistency issue. I reported this as a bug. But the Project Manager
asked me to write it as a Change Control (because it requires more budget to fix this issue) so that he can
address this issue at a later time. So I wrote this as a Change Control. (However, it is NOT a job of a tester to
write change control. It’s the business analyst’s job)

20. What is Backend Testing?

It is a test to check whether the data displayed in the GUI front end report format matches with the particular
data in the original database.

21. Have you done any Back End Testing and/or if you did, how did you do it in your last project?
Yes I did. I was working on Reports. When I was working in my last project, this was my scenario:
It was the case of testing one part of application used in the bank, where a customer comes to a bank’s front
desk associate and ask for opening an account. The associate then asks for the personal information about the
customer which, are the primary data, such as: First Name, Last Name, Date of Birth, Address and Social
Security Number. The associate then put these primary data of that particular customer into the computer,
which then afterwards batch-processed into the DATABASE in XML Format. Then the batch-processed data is
sent to ETL (Extract-Transform-Load, which is software made by ‘AbInitio’ or ‘Informatica’) which processes the

Manual Testing Notes Page 132

job to create a file to produce the report. The file is displayed to a GUI Front End report format with the help of
Crystal Report/Business Object. In the GUI Front End report, let us say, if for January, the income of that person
was displayed as $ 900.00, then my job was to validate this data by writing SQL queries whether this displayed
data matches with the original input data in the database, being called as the Back End Testing.
How can you be sure that the query you wrote is correct? Or how do you know that the data you pulled from
the database is correct?
Answer: I write SQL query based on the requirement document. In the requirement document, various
conditions are given for the query. Based on those conditions, I write SQL query. Therefore, anything different
from the requirement document is definitely a defect.

22. What is XML?

-XML stands for EXtensible Markup Language.
-XML is a markup language much like HTML.
-XML was designed to describe data.
-XML tags are not predefined and we must define our own tags.
-XML uses a Document Type Definition (DTD) or an XML Schema to describe data.
-XML with a DTD or XML Schema is designed to be self-descriptive.
-XML is a W3C Recommendation.

23. From you resume, I see that you have been working in one place for a very short period of time. This
raises me questions why. Can you explain why?
Ans. As a consultant, I am hired for a certain period of time, normally for 6 months to 1 year. Once the project is
over, I needed to move to another project. That’s why you see me in the resume jumping frequently here and
there.
24 What do you do on your first day of the work?
(Note: The person who is asking this question probably wants to know how the real scenario of a working
person at work. It is a hard question for those who has never worked in a work place as a Software Tester.)
Answer: On the first day, normally, we will be given a computer and support people will set up the User Name
and Password for the computer. If that is done already, then the QA Lead or QA Manager will give me a brief
walk through of the documents (which documents are where), introduce to different team members (normally
to the ones you will be working with). Then your boss will ask you to step into work what needs to be done.
However, the first thing normally is, they will ask you to read the documents available for that project.

25 What do you do if you have any questions to ask? Who do you ask?
At the beginning, we all panic, what kind of questions to ask? What if they ask questions that I don’t know? Is it
OK to ask questions? What do I do if I don’t know how to do the job I am assigned to? and so on.
As mentioned earlier, on the first day, your Manager will give you the system (computer) (They normally call
system, not computer), will tell you what the User ID and Password is, where are the QA documents on the
shared drive (or Network drive) are and so on. They will definitely ask you to read a lot of documents at the
beginning (And you must read read and read those documents AS MUCH AS POSSIBLE. At the beginning,
allocate about 2 hours extra at home for reading these documents. This habit will put you on the top of your
job). These documents are normally design specification document (DSD). Different companies call it with
different names, for example, Requirement Specification Document (RSD) and so on. After reading the
documents, you will be asked to write Test Plans or Test Cases (Don’t panic. The Test Plans and Test Cases
templates will be give by your manager or test lead and they will tell you what to do and how to do because
different companies have different formats they follow. If they don’t have one, then you can always prepare a
sample from this website (see on the right column) and give it to them. You will be hero)
Who do you ask?

Manual Testing Notes Page 133

Now let’s say you did not understand something while reading documents. Who are you going to ask? Answer-
Business Analysts who wrote this document. If you have any other questions that you don’t know, you will be
asking that to you friend first, if he/she is not able to answer, then ask this question to the Lead (or Manager).
Do not ask too many questions (some people get irritated). Therefore, it is important to read read and read.
That’s the only way to succeed.
If you have any questions in TestDirector, or QTP or any other automation tools, then there is a HELP menu as
well as tutorial. Please go through these, read them before you ask any questions to anyone else.
What kind of questions should I ask in the meeting?
Nothing. My advice is, keep your mouth shut. Just listen. This is the best way to handle the job until you are
confident enough to speak and you know what you are talking about. If they ask you some questions, then
reply gently, wisely.

26 How to deal with your team members?

Most probably, you will not be the only tester in the team. There will be more than you. Sometimes, dealing
with you team members is frustrating, specially when you are new. They try to ignore you. They want to show
themselves smart. Don’t worry. Don’t blame them. This part of the human nature. Try to cope with it. Invite
them when you go for coffee (in the coffee room in your office, don’t go outside), try to share your feelings and
so on. It is all how you handle your friends. It is part of your daily activities, handle it gently. This is part of the
situation I have gone through, my friends have gone through. I am just sharing this with you.

27. Have you used automation tools?

(Normally, when some one asks this question, we tend to think about automation functional testing tools, like
WinRunner, LoadRunner, QTP (Quick Test Pro), Rational Robot, Experian and so on. But the reality is, even a
Manual Tester also uses automation tools like bug tracking tools like TestDirector, ClearQuest, PVC Tracker and
so on. Therefore, your answer should be Yes)

Answer: Yes. I have used TestDirector and ClearQuest as defect tracking tools. (Your answer is based on whether
you have used automation tools specially for functional and load testing. If you have NOT used, but read about
these tools, then you may be better off saying, “I know about the tools. I was involved in some of the testing
using these tools, but would need some brush up in order to work independently.” I am saying this because
these tools are difficult to tackle in the interview and have to know in depth. In order to pass the interview on
functional automation tools, it may not be easy unless you really know the stuff. But, since there is not much to
learn in ClearQuest and TestDirector, you only have to know what different types of fields are there in the
defect logging window when writing a defect.)

29. When you log a defect using TestDirector (or ClearQuest) what fields do you see?
Answer: When we log a defect, we see Defect ID (it shows later in TestDirector), Summary (where we write
short description of the defect), Description (long description of the defect), Detected by (Person who found
the defect, (it’s you), Severity (meaning-is the defect critical? High? Medium? Or Low?), Date, Detected in
Version, Priority, Project, Status, Assigned to and so [Link] here to see the fields in TestDirector (go to page
24-27)
Click here to see the fields in ClearQuest (go to page 9)

30. Are you better working in a team or working alone?

Answer: I am a team player. I get along with team members very well. As far as the working is concerned, I can
be equally productive in team or working alone.
(Caution: Never say, I like working alone. This could lead you to not getting a job as they are always looking for
people who can get along with other people.)

Manual Testing Notes Page 134

31. Do you have any situations in the past where you have some arguments with your team members?
Answer: No. I never had that type of situation wherever I have worked.
(Even if you had one, it’s a good idea to say “No”. This could be a red flag, which might stop you from getting
the job)

32. What do you like about a Manager? And what don’t you like?

Answer: The best thing I like about a Manager is that the Manager should be able to coordinate with the other
teams so that we can get the updated documents, for example, updated requirements documents right away. A
Manager who can efficiently in distributes the work to the team, without being biased and easily accessible and
protective to his team for the right cause. As far as “what I don’t like” is concerned, I don’t like a manager who
keeps coming to desk 10 times a day to check my work even if it is just a regular work. Once the responsibility is
given, the team member should be trusted and let his work done.

33. Where do you see yourself in another 5 years?

Answer: I see myself a QA Lead in another 5 years.

(You can also say “QA Manager”, but since the QA Manager is taking your interview most of the time, they
some times feel challenged. Therefore, it might be a good idea to limit you to QA Lead)

34. Why are you in QA?

Answer: I am in QA because I like this job.

35. Why do you like this job?

Answer: I like this job, because it is process oriented. Meaning that I get an opportunity to work from analyzing
the requirement documents to writing test plans, test cases, testing the application, logging defects, retesting,
preparing reports and finally testing in production as well. Therefore, I am involved from the very beginning to
the end of the software development life cycle (SDLC) process. I like this.
Another reason is I like to find defects. I enjoy logging defects. The more defects I find, the happier I am.

36. How do you determine what to test in an application?

Answer: First of all we have the test cases (or test scripts) that are written based on the requirement document.
This pretty much covers what functionalities to test. Therefore, looking at the test cases tells us what to test in
the application.

37. If you have no documentation about the product, how do you test an application? Describe the process.

Answer: Well, this is a situation where I have come across several times. Some of the companies in my previous
projects did not have any documents. In this case, I went to the Business Analyst and some times to developers
to find out how exactly the functionalities work, how to navigate from one page to another page and so on.
After getting a clear vision, I write test cases based on the conversation (which is a step by step procedure to
test an application) and get ready for testing.

What do you do once you find a defect?

Once you find a defect, this is what we need to do:

Manual Testing Notes Page 135

1. Recreate the Defect: Once you find a defect, we must try to recreate (meaning that we should be able to
reproduce it) at least 3 times so that we are sure that it is a defect. Some times, once we find it log it without
recreating, may put us in a false situation (because sometimes the application does not behave in the same
way). Therefore, it is important to recreate the same defect several times.
2. Attach the Screen Shot (supporting document): Once we confirm that it is a defect, and then it is a good idea
to attach supporting documents when we log (write) a defect. For example, screen shot, requirement
document etc. For instance, let us say that instead of “Continue” button on a page, there is a typo “Contiinuee”.
Now, we will make a screen shot of this page (To make screen shot, press “Print Screen” button on the
keyboard, and open a Word document, and Click Edit on the Word document and “Past” it. You will see the
screen now) Now, a tester needs to write defects in easy and clear language to make all the developers to
understand easily.
3. Log the Defect: Now, the next step is, we need to log it. Depending on the company what kind of tools they
are using (for example, some companies use TestDirector to log defects, some companies use Rational
ClearQuest, some use PVC Tracker and so on). If the company is small and cannot afford these expensive tools,
then they may simply use Excel sheet to log defects. We log the defect.

38. What are the basic elements you put in a defect?

Answer: Basic elements we put in a defect are: SEVERITY, PRIORITY, CREATED BY, VERSION NO, HEADER,
DESCRIPTION OF THE DEFECT where we write how to recreate a defect, in what module the defect is found,
Status, and so on.

39. What is the biggest bug you have ever found?

Answer: Well, there are many big defects I have found in various projects. For example, in the last project, on a
page, there was a button called “More Information”. Once the user clicked that button, the system would open
a new window (pop up).
We could close the new window in 3 ways:
-By clicking X at the top right corner of the page
-By clicking “Close” button on the page
-By pressing combination keys (Alt+F4) on the key board
Although the combination key (Alt+F4) was not mentioned in the test case, I just wanted to try how the
application reacts when Alt+F4 is pressed. Then I pressed Alt+F4. The result was a disaster-the application
crashed (broke). The application disappeared from the computer monitor. Since it was the last day of testing for
us, it brought chaos in our Managers, Leads and the whole teams. Finally, the developers disabled Alt+F4 as a
temporary solution and the application went into production.

40. How do you make sure that it is quality software?

Answer: There is a certain process how the quality of software is guaranteed (ensured). If is defined by the ‘exit
criteria’. (What it means is, a QA Manager writes a document called Test Strategy. This Test Strategy defines the
‘exit criteria’.) Exit Criteria gives the measurement, for example, in order to confirm the quality, how many
critical defects, high defects, medium defect and low defect are acceptable? These are all defined in the exit
criteria. (Normally in practice, for a quality software, there should no critical defects (0 critical), no high defect
(0 high), no medium defect (0 medium) and may be 1 low defect)

Manual Testing Notes Page 136

41. As a QA Tester, can you tell me the situation when you felt the most proud of it?

Answer: When I find the defect that normally others don’t find, then I feel very proud. For example, there were
situations where I found bugs that crashed the whole system at the end of testing phase. I tried the scenarios
where the scenarios were NOT mentioned in the test cases. For example, we can close the windows by clicking
X on the page, with “Close” button and so on. But there is another way that you can close the window, by
pressing Alt+F4 on the keyboard. Not many testers test this scenario. I have done this in my last two projects.
Both the time, the application crashed which became a big issue. I felt proud.

42. What made you to choose testing career?

Answer: I am a very detailed oriented person and I like process-oriented job. The way QA process works is just
the kind of work I like. For example, analyzing requirement documents, attending walk-through meetings,
writing test plans, writing test cases, executing the test cases (or running the test cases) testing the application,
logging defects, retesting them and so on. I think I really like the process and that’s why I chose this career.

43. When should testing start in a project? Why?

Answer: We should start testing as soon as the following things are ready:
-Test Data are ready
-Build (all the developers have coded their code and merged them
together)
-Test Environment (servers, network etc) is set up and ready
-When the manager asks us to go ahead and start testing.

44. Let us say you have a web application to test. How do you go about testing it? What is the process?

Answer: First of all, I will look at the requirement documents (or design document in some companies). The
requirement document will tell us what the functionalities in the application (software) are. Once I analyze the
requirement documents (one module=one requirement document). After that, I will write test plans for each
module (one module =one test plan). Then after the test plan is complete, I will write test cases (One module
can have hundreds, even thousands test cases). Once the test cases are ready and the application is ready (or
once the build is ready), then I will start testing. Before I start testing, however, I will make sure the test
environments, test data and defect logging tools are in place. This is how I will go about testing an application.

45. What is a “bug?”

Answer: A bug is a bug is an error, flaw, mistake, failure, or fault in a computer code (program) that prevents it
from behaving as intended (e.g., producing an incorrect result). (You can also add this: When the expected
results (accordingly to the requirement documents) don’t match with the actual results (while testing), then it is
considered a bug)

46. How would you ensure that you have covered 100% testing?

Answer: The testing coverage is defined by exit criteria (There is exit criteria and entry criteria in the Test
Strategy). For example, if the exit criteria says “The software will be acceptable to the client only if there are no
critical defects, no high defects, no medium defects and only two low defects”, then all the critical, high,
medium should be zero. Only 2 low defects are acceptable. Thus, 100% coverage is measured by the exit
criteria. Also, 100% test cases must be executed in order to cover 100% of testing.

Manual Testing Notes Page 137

47. What problems did you face in the past? How did you solve it?
(You will be OK if you just give one of the problems below, not all of them)

Answer: I had many problems while testing applications in the past.

As far as I remember one of them (then describe one of them from below), this was the scenario:
(i) It was a web-based application. I was working on a module called “Transaction Summary”. There was
“Submit” button on that page. After entering data in the all the fields, for example, First Name, Last Name,
Social Security Number, Date of Birth and so on, I clicked the Submit button. Once I clicked Submit button, an
error page displayed, “Page cannot be found…”. Since it was a critical defect, I immediately informed the Test
Lead. There was a chaos in the room. All the developers, Database Administrators and Testers gathered in my
cube (room). No body could tell exactly what was wrong with it. Finally, one smart guy checked into the
database and found out that one of the files in the database was closed. The status of all the files should be in
the open status. Once the status of the closed file was put in the “open” status, the application worked fine.
(ii) One of the problems was in the Login window (page). When the user enters and Login Name and Password,
then Password should be encrypted. One of the Test Cases was that I needed to open database and see
whether the password is encrypted or not. I found out it was not encrypted. I reported it as a bug (defect) and
it was fixed in the next release (build).
(iii) Defects I have found in a project was a defect to close a window (pop up).
For example, in the last project, on a page, there was a button called “More Information”. Once the user clicked
that button, the system would open a new window (pop up).We could close the new window in 3 ways:
-By clicking X at the top right corner of the page
-By clicking “Close” button on the page
-By pressing combination keys (Alt+F4) on the key board
Although the combination key (Alt+F4) was not mentioned in the test case, I just wanted to try how the
application reacts when Alt+F4 is pressed. Then I pressed Alt+F4. The result was a disaster-the application
crashed (broke). The application disappeared from the computer monitor. Since it was the last day of testing for
us, it brought chaos in our Managers, Leads and the whole teams. Finally, the developers disabled Alt+F4 as a
temporary solution and the application went into production.
(iv) Another problem was that a user would search for branch location information of a bank. The user logs in
by using User Name and Password. After the log in, on the “Search Location” page, the user enters and zip code
of the location he wants to find, then clicks Find button. After that the system (application) gives a number of
branch locations. The user now clicks “Request Information” for one of the branches. As soon as the user clicks
“Request Information” button, the application breaks (displays “Page cannot be found” error). I logged this
defect as a critical defect. When the developers and database administrator looked into it, then they found out
that in one of the tables, the data was not recorded. In all the tables (UserProfile table, ClientID table and
SessionID table), the data should be populated with the information entered by the user. For some reason, in
one of the tables, it was blank (null). Once they wrote a small code to populate data (enter data) to the table,
the application started working.
(v) In my previous project, when the customer wants to upload a document, for example, a copy of a monthly
statement (in Word format), on the website, the system should automatically change the Word document
into .pdf format. Once the document was uploaded, I saw that the fields in the .pdf document were
interchanged (misplaced). For example, the First Name displayed in the Last Name section. Date of Birth
displayed in the Social Security Number field and so on. We found out that the problem was a mapping
problem (remember this word). Once the mapping was correct, I tested in the new build. It was fixed.
(vi) The most common problem that I have faced in my previous projects are the Java script errors, data
connectivity, error, HTTP 500 error (This error occurs when server is down), HTTP 400 error (when file is not
found) and so on.

Manual Testing Notes Page 138

(vii) “Father” pop up displayed when Print/Print Preview button clicked. (This was coded by the developer to
mark this coding portion (for his/her own purpose as a mark to indicate where he/she made changes, however,
forgot to remove it). Once the developer fixed it, it still displayed the same thing (because it was in the servers
memory and could not go). Now, I had to reset memory of the server from my machine. Therefore, what I did
is, I went to the website I was testing (for example, [Link] and added [Link] at
the end of the URL (Now the URL becomes [Link] and hit enter. It took
me to the server memory and I selected section and submitted the query and it was cleared. Retested again
and it is now OK.

(viii) I was testing a web application. On one page, I clicked Save & Continue button twice (my mistake). Once
this button is clicked twice, the system displayed an error message, “Could not save the answers, please contact
technical support”. (When clicked only once, the button works fine.).

Solution: Once the user clicks the button once, the button was disabled later so that the user cannot click
twice.
(ix) I was testing a web-based application. Once all the fields are entered on the one of the pages, we had Print
Preview button. If the user clicks this button, we were supposed see the same information in a new window in
PDF format. While looking at the data in PDF file, there were some fields missing, for example, Date of Birth was
missing in the PDF file.

48. Tell me about the worst boss you’ve ever had. (Here, you should be careful not to say any negative words
about the past boss. This will give a reflection that you cannot work with different nature of people. You
should be able to show them that you can cope with any king of boss. Therefore, just take an idea below how
the answer should be.)

Answer: I can hardly think of any Manager that was really bad. But when I compare, then I remember of a Test
Lead who was just made a lead from the developers team. She used to feel that she has been very proud of her
position and used to boss around. Some times, she used to call home and check where I was and what I was
doing. Or have I completed my job before leaving and so on. I think, whatever she did, was in the benefit of the
company and myself in the long run which would give me more confidence in future.

49. What do you like about QA?

Answer: The best thing I like about QA is, I like the job which is more process oriented. For example, we have to
work right from reading the requirement documents, providing feedback to the Business Analysts as necessary,
writing test plans, test cases, execute the test cases, interaction with different developers, attend walk-through
meeting and so on. I am a very detailed oriented person. When I test applications, I try to get into the depth of
functionality so that I don’t miss out anything. Finally, I love logging defects.

50. What are all the basic elements in a defect report?

Answer: The basic elements in a defect report are: Defect ID, Header, Description, Defect Reported by, Date,
Status, Version, Assigned to, Approved by, Module where the defect was found and so on.

Manual Testing Notes Page 139

51. What is the difference between verification and validation?

Verification: Verification is a process to ensure that the software that is made, matches the original design. In
other words, it checks whether the software is made according to the criteria and specification described in the
requirement document. It is to check whether you built the product right as per design. It is a low level
checking. (It is done in walk-through meetings generally). It checked whether it is made accordingly to the
design..
Validation: Validation is a process to check whether the product design fits the client’s need. It checks whether
you built the right thing. It checks whether it is designed properly.

52. How do you know it is sufficient testing?

Answer: Every company has entry and exit criteria. When we test applications, we refer to exit criteria. When
we are about to finish testing, then the QA Team (QA Manager) refers to the exit criteria (exit criteria tells the
level of defect that you can be comfortable with before it goes to production. For example, there should be
ZERO critical defect, ZERO high level defect, ZERO medium defect, 1 Low level defect, all the test cases must be
100% executed etc). Once the exit criteria meet the requirements, then the software is considered to be
sufficiently tested.
Every company has entry and exit criteria. When we test applications, we refer to exit criteria. When we are
about to finish testing, then the QA Team (QA Manager) refers to the exit criteria (exit criteria tells the level of
defect that you can be comfortable with before it goes to production. For example, there should be ZERO
critical defect, ZERO high level defect, ZERO medium defect, 1 Low level defect, all the test cases must be 100%
executed etc). Once the exit criteria meet the requirements, then the software is considered to be sufficiently
tested.

53. How to derive test scenarios and use cases? What are the contents and format?

Answer: Test scenarios are derived from requirement documents. We follow each and every functionality
(called business rules) mentioned in the requirement document. One functionality can have multiple business
rules. For example, let us say in there is one requirement called “Login”. This “Login” may have various
scenarios. For example, one scenario is, enter the right User ID and wrong password. The system should display
an error message. Another scenario would be to enter wrong User ID and right Password. The system should
display an error message. The third scenario could be to enter the right User Name and right Password. The
system should allow the user to get into the system. This is how the test cases are derived from the
requirement documents or from the Use Cases.
(For contents for formats of test scenario, please refer to question 4 in [Link])

54. What are the types of test cases that you write?

Answer: We write test cases for smoke testing, integration testing, functional testing, regression testing, load
testing, stress testing, system testing and so on.

55. How to write Integration test cases?

Answer: I have never written separate Test Cases Integration Testing. Since Integration Testing is a test to check
whether the all the modules are integrated together or not (meaning that when the developers compile all
their module and make a build, all modules should be working when they are combined together and those
modules when combined, should work as expected). If they are not integrated (combined) in a nice way, then
the application breaks. Basically, when we do the functional testing, the integration testing is automatically
done. This is my experience.

Manual Testing Notes Page 140

56. How to write Regression test cases? What are the criteria?
Answer: Regression test cases are also based on the requirement documents. They are written more into detail
and with every release (build), the testers need to do regression testing. The criteria for regression testing are;
there should be no major defects while we do our smoke test and functional testing.

57. Is there a format for a test case? Do you follow any methodology for numbering test cases?
Answer: Yes. It depends upon the company how the company has followed the numbering of test cases.
However, normally, it is just a simple numbering in most of the time (see question 4 of [Link]). But
some companies may also relate this numbering to the requirement number. For example, if the requirement
for Login is “REQ-LOG-001”, then we can number the test cases like REQ-LOG-001-001 and so on.

58. What is Test Harness?

Answer: (Definition from [Link]) “In software testing, a test harness or automated test framework
is a collection of software and test data configured to test a program unit by running it under varying conditions
and monitor its behavior and outputs. It has two main parts: the test execution engine and the test script
repository.”

59. How to write User Acceptance Test plan & test cases?

Answer: The way of writing Test Plan and Test Cases is the same in all the test phases. However, specifically for
User Acceptance Testing, the testers use data nearly real data (meaning that the data is very much similar to
the production data or real data). For the format, please refer to question 3 and 4 in [Link].

60. What are the different matrices that you follow?

Answer: There are various reports we normally prepare in QA:
· Test summary Report – It is a report that has list of the total test cases, list of executed test cases, remaining
test case to be executed, executed date, pass/fail
· Defect Report – In this report we normally prepare a list of defect in spreadsheet e.g. defect # CQ12345 [ if you
log a defect in the application called Rational ClearQuest]
· Traceability Matrix [also called RTM (Requirement Traceability Matrix)] Report – the document which shows
the relationship between the functionalities or the business rules and the test cases. So, with the help of
Traceability Matrix we make sure that we includes all the functionalities in our test cases according to the
requirement document.

61. Explain Bug Life Cycle.

Answer: I would describe this as below:

A Tester finds a defect and logs it. (But before you log it, you must try to recreate it for 3 or 4 times so that you
are 100% sure that it is a bug)
The defect is now approved or disapproved by the Test Lead.
(If it is disapproved, then the test lead will come to you ask for more details and you have explain to him why it
is a bug)
After the Test Lead approves the bug, it is now assigned to a development Team Lead (or Development
Manager). He/she now assigns that bug to the concerned developer. The developer now looks into the bug and
fixes it. Once the fix is ready, there will be another build ready to test. The tester now tests the defect. It the
defect is fixed, then the tester closes the defect, if not then the test will reopen it and same cycle [Link]
Life Cycle

Manual Testing Notes Page 141

62. What will you do if developer does not accept the bug?
Answer: If the developer does not accept the defect, then he will reject it. Once it is rejected, then it comes
back to the tester. Now, the tester will ask for clarification with the developer why the defect is rejected. Since
everything is based on the requirement documents, both tester and developer will have to look at the
requirement document, validate it and then reopen it if necessary or close.

63. What are the different tests that can be done for Client Server Application and Web-based Application.
Give details.

Answer: For both client server and web based applications, the testing is the same except one thing: We test
web based applications in different browsers, for example, Internet Explorer (will test in different versions like IE
5.0, IE 6.0, IE 7.0), Firefox, Safari (for Mac) and so on where as for client server, we don’t need to test in the
browsers.

64. What is an inspection?

Answer: An inspection is a formal meeting, more formalized than a walkthrough and typically consists of 3-10
people including a moderator, reader (the author of whatever is being reviewed) and a recorder (to make notes
in the document). The subject of the inspection is typically a document, such as a requirements document or a
test plan. The purpose of an inspection is to find problems and see what is missing, not to fix anything. The
result of the meeting should be documented in a written report. Attendees should prepare for this type of
meeting by reading through the document, before the meeting starts; most problems are found during this
preparation. Preparation for inspections is difficult, but is one of the most cost-effective methods of ensuring
quality, since bug prevention is more cost effective than bug detection.

65. Give me five common problems that occur during software development.

Answer: Poorly written requirements, unrealistic schedules, inadequate testing, adding new features after
development is underway and poor communication. Requirements are poorly written when requirements are
unclear, incomplete, too general, or not testable; therefore there will be problems. The schedule is unrealistic if
too much work is crammed in too little time.
Software testing is inadequate if none knows whether or not the software is any good until customers complain
or the system crashes. It’s extremely common that new features are added after development is underway.
Miscommunication either means the developers don’t know what is needed, or customers have unrealistic
expectations and therefore problems are guaranteed

66. What is the role of documentation in QA?

Answer: Documentation plays a critical role in QA. QA practices should be documented, so that they are
repeatable. Specifications, designs, business rules, inspection reports, configurations, code changes, test plans,
test cases, bug reports, user manuals should all be documented. Ideally, there should be a system for easily
finding and obtaining of documents and determining what document will have a particular piece of
information. Use documentation change management, if possible.

67. What if the software is so buggy it can’t be tested at all?

Answer: In this situation the best bet is to have test engineers go through the process of reporting whatever
bugs or problems initially show up, with the focus being on critical bugs. Since this type of problem can severely

Manual Testing Notes Page 142

affect schedules and indicates deeper problems in the software development process, such as insufficient unit
testing, insufficient integration testing, poor design, improper build or release procedures, managers should be
notified and provided with some documentation as evidence of the problem.
68. How do you know when to stop testing?

Answer: This can be difficult to determine. Many modern software applications are so complex and run in such
an interdependent environment, that complete testing can never be done. Common factors in deciding when to
stop are…
Deadlines, e.g. release deadlines, testing deadlines;
Test cases completed with certain percentage passed;
Test budget has been depleted;
Coverage of code, functionality, or requirements reaches a specified point;
Bug rate falls below a certain level; or
Beta or alpha testing period ends.

69. What if there isn’t enough time for thorough testing?

Answer: Since it’s rarely possible to test every possible aspect of an application, every possible combination of
events, every dependency, or everything that could go wrong, risk analysis is appropriate to most software
development projects. Use risk analysis to determine where testing should be focused. This requires judgment
skills, common sense and experience. The checklist should include answers to the following questions:
· Which functionality is most important to the project’s intended purpose?
· Which functionality is most visible to the user?
· Which functionality has the largest safety impact?
· Which functionality has the largest financial impact on users?
· Which aspects of the application are most important to the customer?
· Which aspects of the application can be tested early in the development cycle?
· Which parts of the code are most complex and thus most subject to errors?
· Which parts of the application were developed in rush or panic mode?
· Which aspects of similar/related previous projects caused problems?
· Which aspects of similar/related previous projects had large maintenance expenses?
· Which parts of the requirements and design are unclear or poorly thought out?
· What do the developers think are the highest-risk aspects of the application?
· What kinds of problems would cause the worst publicity?
· What kinds of problems would cause the most customer service complaints?
· What kinds of tests could easily cover multiple functionalities?
· Which tests will have the best high-risk-coverage to time-required ratio?

70. What can be done if requirements are changing continuously?

Answer: Work with management early on to understand how requirements might change, so that alternate test
plans and strategies can be worked out in advance. It is helpful if the application’s initial design allows for some
adaptability, so that later changes do not require redoing the application from scratch. Additionally, try to… ·
Ensure the code is well commented and well documented; this makes changes easier
for the developers.
· Use rapid prototyping whenever possible; this will help customers feel sure of their
requirements and minimize changes.
· In the project’s initial schedule, allow for some extra time to commensurate with
probable changes.

Manual Testing Notes Page 143

· Move new requirements to a ‘Phase 2′ version of an application and use the original
requirements for the ‘Phase 1′ version.
· Negotiate to allow only easily implemented new requirements into the project; move
more difficult, new requirements into future versions of the application.
· Ensure customers and management understand scheduling impacts, inherent risks and
costs of significant requirements changes. Then let management or the customers
decide if the changes are warranted; after all, that’s their job.
· Balance the effort put into setting up automated testing with the expected effort
required to redo them to deal with changes.
· Design some flexibility into automated test scripts;
· Focus initial automated testing on application aspects that are most likely to remain
unchanged;
· Devote appropriate effort to risk analysis of changes, in order to minimize regression-
testing needs;
· Design some flexibility into test cases; this is not easily done; the best bet is to minimize the detail in the test
cases, or set up only higher-level generic-type test plans;
· Focus less on detailed test plans and test cases and more on ad-hoc testing with an understanding of the
added risk this entails.

71. What if the application has functionality that wasn’t in the requirements?

Answer: It may take serious effort to determine if an application has significant unexpected or hidden
functionality, which it would indicate deeper problems in the software development process. If the functionality
isn’t necessary to the purpose of the application, it should be removed, as it may have unknown impacts or
dependencies that were not taken into account by the designer or the customer.
If not removed, design information will be needed to determine added testing needs or regression testing
needs. Management should be made aware of any significant added risks as a result of the unexpected
functionality. If the functionality only affects areas, such as minor improvements in the user interface, it may
not be a significant risk.

72. How can software QA processes be implemented without stifling productivity?

Answer: Implement QA processes slowly over time. Use consensus to reach agreement on processes and adjust
and experiment as an organization grows and matures. Productivity will be improved instead of stifled. Problem
prevention will lessen the need for problem detection. Panics and burnout will decrease and there will be
improved focus and less wasted effort. At the same time, attempts should be made to keep processes simple
and efficient, minimize paperwork, promote computer-based processes and automated tracking and reporting,
minimize time required in meetings and promote training as part of the QA process. However, no one,
especially talented technical types, like bureaucracy and in the short run things may slow down a bit. A typical
scenario would be that more days of planning and development will be needed, but less time will be required
for late-night bug fixing and calming of irate customers.

73. What is parallel/audit testing?

Answer: Parallel/audit testing is testing where the user reconciles the output of the new system to the output
of the current system to verify the new system performs the operations correctly. Let us say, for example, the
currently software is in the mainframe system which calculates the interest rate. The company wants to change
this mainframe system to web-based application. While testing the new web based application, we need to
verify that the web-based application calculates the same interest rate. This is parallel testing.

Manual Testing Notes Page 144

74. What is system testing?

Answer: System testing is black box testing, performed by the Test Team, and at the start of the system testing
the complete system is configured in a controlled environment. The purpose of system testing is to validate an
application’s accuracy and completeness in performing the functions as designed. System testing simulates real
life scenarios that occur in a “simulated real life” test environment and test all functions of the system that are
required in real life. System testing is deemed complete when actual results and expected results are either in
line or differences are explainable or acceptable, based on client input.
Upon completion of integration testing, system testing is started. Before system testing, all unit and integration
test results are reviewed by Software QA to ensure all problems have been resolved. For a higher level of
testing it is important to understand unresolved problems that originate at unit and integration test levels. You
CAN learn system testing, with little or no outside help. Get CAN get free information. Click on a link!

75. What is end-to-end testing?

Answer: Similar to system testing, the *macro* end of the test scale is testing a complete application in a
situation that mimics real world use, such as interacting with a database, using network communication, or
interacting with other hardware, application, or system.

76. What is security/penetration testing?

Answer: Security/penetration testing is testing how well the system is protected against unauthorized internal
or external access, or willful damage. This type of testing usually requires sophisticated testing techniques.

77. What is recovery/error testing?

Answer: Recovery/error testing is testing how well a system recovers from crashes, hardware failures, or other
catastrophic problems.

78. What is compatibility testing?

Answer: Compatibility testing is testing how well software performs in a particular hardware, software,
operating system, or network environment.

79. What is comparison testing?

Answer: Comparison testing is testing that compares software weaknesses and strengths to those of
competitors’ products.

80. What is acceptance testing?

Answer: Acceptance testing is black box testing that gives the client/customer/project manager the opportunity
to verify the system functionality and usability prior to the system being released to production. The
acceptance test is the responsibility of the client/customer or project manager, however, it is conducted with
the full support of the project team. The test team also works with the client/customer/project manager to
develop the acceptance criteria.

81. What is a Test/QA Team Lead?

Manual Testing Notes Page 145

Answer: The Test/QA Team Lead coordinates the testing activity, communicates testing status to management
and manages the test team.

82. What is software testing methodology?

Answer: One software testing methodology is the use a three step process of…
1. Creating a test strategy;
2. Creating a test plan/design; and
3. Executing tests. This methodology can be used and molded to your organization’s needs. Rob Davis believes
that using this methodology is important in the development and in ongoing maintenance of his customers’
applications.

83. What is the general testing process?

Answer: The general testing process is the creation of a test strategy (which sometimes includes the creation of
test cases), creation of a test plan/design (which usually includes test cases and test procedures) and the
execution of tests.

84. How do you create a test strategy?

Answer: The test strategy is a formal description of how a software product will be tested. A test strategy is
developed for all levels of testing, as required. The test team analyzes the requirements, writes the test strategy
and reviews the plan with the project team. The test plan may include test cases, conditions, the test
environment, a list of related tasks, pass/fail criteria and risk assessment. Inputs for this process:
· A description of the required hardware and software components, including test tools. This information comes
from the test environment, including test tool data.
· A description of roles and responsibilities of the resources required for the test and schedule constraints. This
information comes from man-hours and schedules.
· Testing methodology. This is based on known standards.
· Functional and technical requirements of the application. This information comes from requirements, change
request, technical and functional design documents.
· Requirements that the system can not provide, e.g. system limitations. Outputs for this process:
· An approved and signed off test strategy document, test plan, including test cases.
· Testing issues requiring resolution. Usually this requires additional negotiation at the project management
level.

85. How do you create a test plan/design?

Answer: Test scenarios and/or cases are prepared by reviewing functional requirements of the release and
preparing logical groups of functions that can be further broken into test procedures. Test procedures define
test conditions, data to be used for testing and expected results, including database updates, file outputs,
report results. Generally speaking…
Test cases and scenarios are designed to represent both typical and unusual situations that may occur in the
application.
Test engineers define unit test requirements and unit test cases. Test engineers also execute unit test cases.
It is the test team that, with assistance of developers and clients, develops test cases and scenarios for
integration and system testing.
Test scenarios are executed through the use of test procedures or scripts.
Test procedures or scripts define a series of steps necessary to perform one or more test scenarios.

Manual Testing Notes Page 146

Test procedures or scripts include the specific data that will be used for testing the process or transaction.
Test procedures or scripts may cover multiple test scenarios.
Test scripts are mapped back to the requirements and traceability matrices are used to ensure each test is
within scope.
Test data is captured and base lined, prior to testing. This data serves as the foundation for unit and system
testing and used to exercise system functionality in a controlled environment.
Some output data is also base-lined for future comparison. Base-lined data is used to support future application
maintenance via regression testing.
A pretest meeting is held to assess the readiness of the application and the environment and data to be tested.
A test readiness document is created to indicate the status of the entrance criteria of the release.
Inputs for this process:
Approved Test Strategy Document.
Test tools, or automated test tools, if applicable.
Previously developed scripts, if applicable.
Test documentation problems uncovered as a result of testing.
A good understanding of software complexity and module path coverage, derived from general and detailed
design documents, e.g. software design document, source code and software complexity data.
Outputs for this process:
Approved documents of test scenarios, test cases, test conditions and test data.
Reports of software design issues, given to software developers for correction.

86. How do you execute tests?

Answer: Execution of tests is completed by following the test documents in a methodical manner. As each test
procedure is performed, an entry is recorded in a test execution log to note the execution of the procedure and
whether or not the test procedure uncovered any defects. Checkpoint meetings are held throughout the
execution phase. Checkpoint meetings are held daily, if required, to address and discuss testing issues, status
and [Link] output from the execution of test procedures is known as test results. Test results are
evaluated by test engineers to determine whether the expected results have been obtained. All
discrepancies/anomalies are logged and discussed with the software team lead, hardware test lead,
programmers, software engineers and documented for further investigation and resolution. Every company has
a different process for logging and reporting bugs/defects uncovered during testing.A pass/fail criteria is used to
determine the severity of a problem, and results are recorded in a test summary report. The severity of a
problem, found during system testing, is defined in accordance to the customer’s risk assessment and recorded
in their selected tracking [Link] fixes are delivered to the testing environment, based on the severity of
the problem. Fixes are regression tested and flawless fixes are migrated to a new baseline. Following
completion of the test, members of the test team prepare a summary report. The summary report is reviewed
by the Project Manager, Software QA Manager and/or Test Team Lead.
After a particular level of testing has been certified, it is the responsibility of the Configuration Manager to
coordinate the migration of the release software components to the next test level, as documented in the
Configuration Management Plan. The software is only migrated to the production environment after the Project
Manager’s formal acceptance.

87. What testing approaches can you tell me about?

Manual Testing Notes Page 147

Answer: Each of the followings represents a different testing approach:
Black box testing,
White box testing,
Unit testing,
Incremental testing,
Integration testing,
Functional testing,
System testing,
End-to-end testing,
Sanity testing,
Regression testing,
Acceptance testing,
Load testing,
Performance testing,
Usability testing,
Install/uninstall testing,
Recovery testing,
Security testing,
Compatibility testing,
Exploratory testing, ad-hoc testing,
User acceptance testing,
Comparison testing,
Alpha testing,
Beta testing, and
Mutation testing.

88. How do you divide the application into different sections to create scripts?
Answer: First of all, the application is divided in different parts when a business analyst writes the requirement
document (or Use Cases or Design Document), he/she writes EACH requirement document for EACH module.
Let us say, if there are 12 different modules in an application that a business analyst has written the
requirements for, then a tester would write the test cases for each module, which means in 12 different
sections. This is the standard practice. There might be scenarios where you might have to break down scripts
into sub-categories. For example, if a tester is writing a script for Login Page, he/she might write one for
positive and negative testing and another sub-set of test cases would be for error message when the wrong
information is entered. In short, the test cases are divided according to the modules.
(The following questions were asked to Padma in one of her interviews very recently)
(This question is asked to check how ambitious you are as far as your career is concerned, whether you like the
job you are doing and so on. Therefore, no matter what, you should stick to your QA job at this point and say
that you love this so much and your goal is some thing similar to the one below)
What is your salary requirement?
$70k (negotiable), or ($35 per hour)
Please provide information (an example) of your experience testing Linux and UNIX environments (including
type of system tested, how tested, actual commands and steps used for test) Testing applications using Linux
and UNIX.
Answer: I have tested applications using UNIX. For every backend testing I have done in the past, I have used
UNIX platform while performing backend testing. For example, when the data is fed into the system in the front
end, that data goes to the database after the batch processing. From the database, the data is now sent to the
ETL system (in XML format) for data manipulation as per our need (ETL is a software tool of Ab Initio company
which is used to manipulate data in the data warehouse). In the ETL system, we manipulate those data

Manual Testing Notes Page 148

according to our need), for example, it could be income statement of the company, balance sheet, monthly
reports, and so on. In order to produce income statement, we need to run a job in ETL. To run this job, we use
UNIX. In the same way, different types of jobs are created for each need (creating balance sheet is another job,
creating reports is next job etc) then I had to run different jobs in the ETL system. Once we run the job, the
running job finally creates an output file which is now validated by us tester. This output file can be in text
format or GUI format. Thus, this is the scenario where I had to use UNIX. (I have used Linux much, however,
since UNIX and Linux are the same thing, I should have no problem in using Linux)
Some of the commands I used while testing using UNIX are;
Ls –l ———>to check the file list
Pwd———-> to see which directory I am in
Cd ———–>change the directory
Cd .. ———>change the directory one level up
Mkdir ———>make a directory
Rmdir ———>Delete the directory
setenv name v ——>Set environment
kill% ——–>Kill the running job
vi ———>editor Used to write scripts
more——-> to see the contents page by page
cat —–>list contents of the file
chmod ——–>change permission
cp ——–>copy
rm —–>delete a file

The following are the some of the things that a tester has to know (but may not be asked in the interview)What
is a cookie? (You must know how to clean cookies)
A small text file of information that certain Web sites attach to a user’s hard drive while the user is browsing the
Web site. A Cookie can contain information such as user ID, user preferences, archive shopping cart
information, etc. Cookies can contain Personally Identifiable Information.
Does a tester have to know about cookie?
Yes. A tester has to know HOW TO CLEAN cookies (Does not have to know the difinition)
How to clean cookies?

Cookies are cleaned in the browsers like IE (Internet Explorer), Firefox, Safari (for MAC and windows both),
Netscape and so on.
However, the mostly used (90%) browser is IE (Internet Explorer)
Here is how you clean cookies in IE (Internet Explorer):

1. Open IE (Internet Explorer)

2. On the menu, click Tools–>Internet Options–>Click Delete button (It is in General Tab)
(You will see different buttons now, for example, Delete Files, Delete Cookies, Delete History, Delete Forms,
Delete Passwords,
Delete All).
3. Click Delete All button.
Now the cookies are cleaned in IE.
Here is how you can clean cookies in Fire Fox:

1. Open Firefox Brower.

Manual Testing Notes Page 149

2. Click Tools.
3. Click Error Console.
4. Click Clear.
Now the cookies are cleaned in Firefox.
What are different types of protocols?

-Generally, a Tester does NOT necessarily have to know different types of protocols. This is Network Engineers
job. However, if you want to know more for your knowledge, you can visit:
[Link]
What is Web Architecture?

-A tester does not necessarily have to know this unless you are a very Senior Tester testing networks and doing
some kind of development. However, if you want to know more about it, please visit:
[Link] a Tester need SQL?

Answer: Yes. For a Tester, SQL is needed. I had the same question in mind becore I came to the actual
implication-what is SQL used for? And now, I know that when we do the backend testing (see [Link]
for details), we need to write SQL queries to retrieve the data from the database and compare this data to the
one with reports or output. Another scenario is, if something goes wrong in the application, for example, if
there is an error, then we might have to write SQL queries to retrieve the data from the database and check
what went wrong. Let’s say, we need to check in the Error Log table what went wrong. To check this, we open
the database, go to Error Log table and find out that happened. In the Error Log table, there are many records,
so which one is your error then? To find out which one is yours, we need to write SQL queries. Example, you
logged in to the application with User and password=sn992jj. Now, to retrieve your record, you can write a
query some thing like this: select * from Error_Log where userID=devin99; This query will retriev your record
only so that you can see what happened.
What is a ‘Show Stopper’?
A show stopper is a defect or bug that stops the user for further action (testing). It has no work around. In
other words, it stops every thing and the user cannot go any futher. This is called show stopper in software
industry languague. (This is not an interview questions, but you have to know this terminology)
Some GlossaryTest Plan, Test Case, Test Script, Requirement Document, Design Document, Shared Drive,
Network Driver, Share Point, System, Build Configuration Management Team, Defect, Log, Automation Tools,
TestDirector, Quality Center, ClearQuest, ClearCase, Rational Robot, Rational Functional Tester, WinRunner,
LoadRunner, Business Objects, Crystal Reports, SQA, QA
Answer: My goal is to be QA Lead (or QA Manager) in near future.

90. What are you expecting from our company?

Answer: My expectation from you company would be I will have more challenges and new things to learn and
whatever the skills I have to contribute, hopefully, I will be able to contribute if they are in any way helpful to
enhance productivity of the company.
91. What did you learn from your previous companies?

Answer: I learned a lot from the previous companies wherever I have worked. Wherever I have worked, I
found out the there is always something to learn. Different companies have different ways of working. The
environment and technology always differ from one company to another company. I have never found one
company’s environment matching with another company. For example, if one company is using documents
called requirement documents, then the other company might be using Use Cases and some companies might
be using Design Document and so on. Therefore, in my experience, there are always new things to learn in

Manual Testing Notes Page 150

every company and we can always contribute these thing in the next company if they help to be more
productive.
92. What do you want to be in next 2 years?

Answer: I want to be QA Lead in another two years.

Why QA Lead? Why not something else?

Answer: QA is the only thing I love doing it. I love this job and want to progress in this sector. I want to know
how to manage QA process, how to handle different jobs and so on. Since the next step is the QA Lead, that
would preferably be one I will targeting for.
93. Why do you want to work for this company?

Answer: (This is a tricky question. They want to know what really interests you and you have to be careful when
you answer this question. You must admire the line of that company. For example, if you are being interviewed
by a pharmaceutical company, then tell them that you are always interested in the medical applications and the
better part of your company is that it has exciting products that I am really curious to learn. That’s why I would
feel really great if I am given the opportunity to work in your company)
94. Did you get any compliments from your previous employers? What were those situations?
Answer: Yes. I did. There were many occasions where I had compliments. For example, I was testing an
application going a little bit off my test cases. After I finished executing my test cases, I always think in a way
what a real user would possibally click in various parts of the application. So I was just clicking back and forth
and at one specific scenario, the application simply broke and displayed an error message. That scenario was
not in the test cases. The manager really appreciated me and thanked for finding this kind of critical defect.
Answer: Yes. I did. There were many occasions where I had compliments. For example, I was testing an
application going a little bit off my test cases. After I finished executing my test cases, I always think in a way
what a real user would possibally click in various parts of the application. So I was just clicking back and forth
and at one specific scenario, the application simply broke and displayed an error message. That scenario was
not in the test cases. The manager really appreciated me and thanked for finding this kind of critical defect.

What are your strengths?

Answer: I am a very detailed oriented person. I have the sense of urgency. I can prioritize my job according to
the deadline. I am very much dedicated towards my job. I am honest. I have the skills and expertise in QA
process. These are some of my strengths.

What is your weakness?

Answer: I think my weakness is that whenever I am given some responsibilities and there is a deadline for it, I
work day and night, 7 days a week. This is probably bad for my family life, but I can’t sleep unless I am done
with my assignments.(Note: You should think of your weakness where because of your weakness (like the one
above), still the employer benefits. DON’T SAY anything negative thing, like “I cannot work long hours, it is hard
for me pick up things, it is difficult for me to understand requirement documents etc)

89. What is your goal?

Ans: My goal in the next 4 years is to be a QA Manager.

90. What is RTM (Requirement Traceability Matrix)?

Answer – Tractability matrix is used to cross check the test cases as per the requirement of the test cases. In
other words, it checks whether the each functionality is covered in the Test Cases as per requirement

Manual Testing Notes Page 151

document. (We create RTM using Quality Center tool)

Manual Testing Notes Page 152