What are Software & its types?

 The two major categories of software are system software and

application software.
 System software is made up of control programs. Application
software is any program that processes data for the user
(spreadsheet, word processor, payroll, etc.).
 Application software can once again break up into Web, Window
and mobile as of now.

What is software testing?

 A software product should only be released after it has gone

through a proper process of development, testing and bug fixing.
 It is important to note that software is mainly tested to see that it
meets the customers’ needs and that it conforms to the
standards.
 It is a usual norm that software is considered of good quality if it
meets the user requirements.

Who does Testing?

Now, everyone would be confused that only the software tester and
developer may perform the test. But that’s not the case. The following
are some who performs testing at various instances

 Software Tester
 Software Developer (Perform Unit testing at the time of
developing the software)

1
  Project Lead/Manager (Performs an overall check when the
product is ready to ship. They would check if everything is working
fine and upto the standards)
 End User (Involved in Beta testing, that is pre-release testing. To
check for any bugs available and explore new features)

Different companies have different designations for people who test

the software on the basis of their experience and knowledge such
as Software Tester, Software Quality Assurance Engineer, QA Analyst,
etc.

When to Start Testing?

In Software Development Life Cycle (SDLC), testing can be started

from the Requirements Gathering phase and continued till the
deployment of the software. It also depends on the development
model that is being used. For example, in the Waterfall model,
formal testing is conducted in the testing phase; but in the incremental
model, testing is performed at the end of every increment/iteration
and the whole application is tested at the end.
Testing is done in different forms at every phase of SDLC:
Requirements Gathering - During the requirement gathering phase, the
analysis and verification of requirements are also considered as testing.
Design Phase - Reviewing the design in the design phase with the intent
to improve the design is also considered as testing.
Development Phase - Testing performed by a developer on
completion of the code is also categorized as testing. Also, the tester
works on generating the test cases are also considered to be a testing
activities.
2
Testing Phase - Execution of the test cases that is prepared. Testing ,
debugging and tracking the bug to closure.
Maintenance Phase – Once the product is deployed, Testing carried in
the production environment for retesting the bug fixes and updates in
the software.

When to Stop Testing?

It is difficult to determine when to stop testing, as testing is a
never-ending process and no one can claim that a software is 100%
tested. The following aspects are to be considered for stopping the
testing process:
 Completion of test case execution
 Bug rate falls below a certain level and no high-priority bugs are
identified. Low priority bugs with some workaround.
 Management decision (When the management says so)
 Testing Deadlines.

Testing Principles
A number of testing principles have been suggested over the past 40
years and offer general guidelines common f or all testing.

Principle 1 – Testing shows presence of defects

Testing can show that defects are present, but cannot prove that there
are no defects. Testing reduces the probability of undiscovered defects
remaining in the software but, eve n if no defects are found, it is not a
proof of correctness.

3
Principle 2 – Exhaustive testing is impossible
Testing everything (all combinations of inputs and preconditions) is not
feasible except for trivial cases. Instead of exhaustive testing, risk
analysis and priorities should be used to focus testing efforts.

Principle 3 – Early testing

To find defects early, testing activities shall be started as early as
possible in the software or system development life cycle, and shall
be focused on defined objectives.

Principle 4 – Defect clustering

Testing effort shall be focused proportionally to the expected and
later observed defect density of modules. A small number of
modules usually contains most of the defects discovered during
pre-release testing, or is responsible for most of the operational
failures.

4
During software testing, as defects are found, analysis of defects
can give surprising results!
Defect Clustering in Software Testing means that the majority of
the defects are caused by a small number of modules, i.e. the
distribution of defects are not across the application but rather
centralized in limited sections of the application.
Defect Clustering in Software Testing is based on the Pareto
principle, also known as the 80-20 rule, where it is stated that
approximately 80% of the problems are caused by 20% of the
modules.
This can give a good indication that when a defect is found in one
area of the application, chances are there are more defects in that
particular area, so it is worth investing more time to test that
particular area of the application to find as many defects as
possible.
However, testers should not ignore to test the rest of application as
well as there may be other defects scattered around.
Defect aggregation or defect clustering in software testing can also
indicate which area of the application needs more regression
testing to ensure related features are not broken.

Principle 5 – Pesticide paradox

If the same tests are repeated over and over again, eventually the
same set of test cases will no longer find any new defects. To
overcome this “pesticide paradox”, test cases need to be regularly
reviewed and revised, and new and different tests need t o be
written to exercise different parts of the software or system to find
potentially more defects.

Let’s say you are testing a application. You have written a set of
test cases.

5
Now you run one cycle of testing. You find few bugs and report
them to the development team. Development team fixes the bugs
and reverts to you with the updated code. You again execute the
same set of test cases. This time you find that few of the bug were
still not fixed and you report that back to the development team.
They work of it and send an update to you. Once again, you
execute the same set of test cases and don't find any bugs.
Now in a new release some changes were made in the application.
You run the same set of test cases and they all pass. But, what you
miss here is the new bugs that may have introduced when the fix
and new changes were applied. The old sets of test cases are
incapable of identifying these new bugs.
This is called Pesticide Paradox. To avoid this you need to update
your test cases with each cycle and add new cases to the old set.

Principle 6 – Testing is context dependent

Testing is done differently in different contexts. For example,
safety-critical software is tested differently from an e-commerce
site.

Principle 7 – Absence-of-errors fallacy

Finding and fixing defects does not help if the system built is
unusable and does not fulfill the users’ needs and expectations.

Verification VS Validation
Verification Validation
1. Verification is a static 1. Validation is a dynamic
Activity of verifying activity of validating and

6
documents, design, code and
program.
2. Done by developers.
3. Ensures that the software
system
meets all the functionality.
4. Verification addresses the
concern: "Are you building it
right?"
5. It is human based checking
of documents and files.
6. For Example: Building a
weight machine which weighs
object and displays the weight
only upon inserting one rupee
coin. Now this is the
requirement of the Customer.
Quality Assurance VS Quality Control
Quality Assurance
1. It is a procedure that focuses on 1. It is a procedure that focuses on
providing assurance that quality
request will be achieved
2. QA aims to prevent the defect
7
testing the actual product.
2. Done by Testers.
3. Ensures that the
functionalities
meet the intended behavior.
4. Validation addresses the
concern:
"Are you building the right
thing?"
5. It is computer based
execution of program.
6. Once this weight machine is
built it’s the Tester who needs
to validate if the weight
machine displays the weight
only for 1Rs coin or it displays
the weight for "2" and "5"
Rupee coin. If machine
displays the weight for "2" and
"5" rupee coin then it’s a bug
and it need to be reported.
Quality Control
fulfilling the quality request
2. QC aims to identify and fix
defects
3. It's a Preventive technique
4. It is the procedure to create the
deliverables
5. In order to meet the customer
requirements QA defines
standards and methodologies
6. It requires involvement of the
whole team
7. QA comes under the
category of Verification.
8. It is done before Quality
Control.
3. It's a Corrective technique
4. It is the procedure to verify that
deliverables
5. QC confirms that the standards
are followed while working on the
product
6. It requires involvement of
Testing team
7. QC comes under the
category of Validation.
8. It is done only after
Quality Assurance activity is
completed.

Audit and Inspection

Audit means the inspection, examination or verification of a person,
organization, system, process, enterprise, project or product and to
recommend necessary changes in controls, policies, or procedures. An
audit can be done anytime. It is a systematic process to determine how
the actual testing process is conducted within an organization or a
team. Types of audit include Legal Compliance Audit, Internal Audit,
and System Audit
Inspection indicates that the regulatory authorities are checking
documents, records, facilities and any other resources to verify a
certain set of standards. It is a formal technique that involves formal or
informal technical reviews of any artifact by identifying any error
or gap. inspection is a formal evaluation technique in which
software requirements, designs, or codes are examined in detail by
a person or a group other than the author to detect faults,
violations of development standards, and other problems.

8
Testing and Debugging
A common perception of testing is that it only consists of running test s,
i.e., executing the software. This is part of testing, but not all of the
testing activities. Test activities exist before and after test execution.
These activities include planning and control, choosing test conditions,
designing and executing test cases, checking results, evaluating exit
criteria, reporting on the testing process and system under test, and
finalizing or completing closure activities after a test phase has been
completed.
Debugging is the development activity that finds, analyzes and removes
the cause of the failure. Subsequent re-testing by a tester ensures that
the fix doe s indeed re solve the failure. The responsibility for these
activities is usually testers test and developers debug.

Types of Testing:
Types of testing can be basically divided into Manual and Automation.
Manual testing is the process of manually testing software for defects.
i.e., without using any automated tool or any script. It requires a tester
to play the role of an end user and use most of all features of the
application to ensure correct behavior.
Testers use test plans, test cases, or test scenarios to test a software to
ensure the completeness of testing. Manual testing also includes
exploratory testing, as testers explore the software to identify errors in
it.
Automation testing, which is also known as Test Automation, is when
the tester writes scripts and uses another software to test the
product. Automation Testing saves time, cost and manpower. Once

9
recorded, it's easier to run an automated test suite when compared to
manual testing which will require skilled labor.
Any type of application can be tested manually but automated testing is
recommended only for stable systems and is mostly used for regression
testing. Also, certain testing types like ad-hoc and monkey testing are
more suited for manual execution.
What to Automate?
It is not possible to automate everything in software. The following are
some cases that one can perform the automation
1. Tests that carried out in various builds.
2. Tests that has complexity in executing a functionality
3. Testing a scenario with numerous amounts of test data.
The following are some cases that one cannot perform the automation
1. Test that requires manual intervention again and again.
2. Test cases that tests the UI. (Look and feel cases)
3. Tests that are carried out one or two times
How to Automate?
There are many tools available that can be used to write automation
scripts. Before mentioning the tools, let us identify the process that can
be used to automate the testing process:
1. Identifying areas within a software for automation
2. Selection of appropriate tool for test automation
3. Writing test scripts
4. Reviewing test scripts
5. Rework of scripts
6. Integration of scripts
7. Execution of scripts
8. Enhancement of scripts

10
 Automation Software Testing Tools
The following tools can be used for automation testing:
 HP Quick Test Professional - Now UFT (Unified Functional
testing)
 Selenium
 IBM Rational Functional Tester
 SilkTest
 TestComplete
 Testing Anywhere
 WinRunner
 LoadRunner
 Visual Studio Test Professional
 Virtual Users
 Appium (Selenium Mobile testing tool)
 JMeter

Testing Methods
There are different methods that can be used for software testing.
 Black-Box Testing
 White-Box Testing
 Grey-Box Testing
Black-Box Testing:
The technique of testing without having any knowledge of the interior
workings of the application is called black-box testing. The tester is
obvious to the system architecture and does not have access to the
source code. Typically, while performing a black-box test, a tester will
interact with the system’s user interface by providing inputs and

11
examining outputs without knowing how and where the inputs are
worked upon.
The following table lists the advantages and disadvantages of black-box
testing.
Advantages Disadvantages
Well suited and efficient for large Limited coverage, since only a
code segments. selected number of test scenarios
is actually performed.
Large numbers of moderately Inefficient testing, due to the fact
skilled testers can test the that the tester only has limited
application with no knowledge of knowledge about an application.
implementation, programming
language, or operating systems.
Clearly separates user's Blind coverage, since the tester
perspective from the developer's cannot target specific code
perspective through visibly defined segments or error-prone areas.
roles.
Code access is not required. The test cases are difficult to
design.

White-Box Testing:
White-box testing is the detailed investigation of internal logic and
structure of the code. White-box testing is also called glass testing or
open-box testing. In order to perform white-box testing on an
application, a tester needs to know the internal workings of the code.
The tester needs to have a look inside the source code and find
out which unit/chunk of the code is behaving inappropriately.

12
The following table lists the advantages and disadvantages of white-box
testing.
Advantages Disadvantages
As the tester has knowledge of the Due to the fact that a skilled tester
source code, it becomes very easy is needed to perform white-box
to find out which type of data can testing, the costs are increased.
help in testing the application
effectively.
It helps in optimizing the code. Sometimes it is impossible to look
into every nook and corner to find
out hidden errors that may create
problems, as many paths will go
untested.
Extra lines of code can be removed It is difficult to maintain white-box
which can bring in hidden defects. testing, as it requires specialized
tools like code analyzers and
debugging tools.
Due to the tester's knowledge
about the code, maximum
coverage is attained during test
scenario writing.

Grey-Box Testing:
Grey-box testing is a technique to test the application with having
a limited knowledge of the internal workings of an application.
Mastering the domain of a system always gives the tester an edge over
someone with limited domain knowledge. Unlike black-box testing,
where the tester only tests the application's user interface; in grey-box

13
testing, the tester has access to design documents and the database.
Having this knowledge, a tester can prepare better test data and test
scenarios while making a test plan.
Advantages Disadvantages
Offers combined benefits of black- Testing every possible input
box and white-box testing stream is unrealistic because it
wherever possible. would take an unreasonable
amount of time; therefore, many
program paths will go untested.
Based on the limited information Since the access to source code is
available, a grey-box tester can not available, the ability to go over
design excellent test scenarios. the code and test coverage is
limited.
The test is done from the point of
view of the user and not the
designer.

Test Levels
There are four levels of software testing:

Component Testing or Unit Testing:

Component testing (also known as unit, module or program
testing) searches for defects in, and verifies the functioning of,
software modules, programs, objects, classes, etc., that are
separately testable.

Component testing may include testing of functionality and

specific non-functional characteristics, such as resource-
behavior (e.g., searching for memory leaks) or robustness
testing, as well as structural testing (e. g., decision coverage).

14
Test cases are derived from work products such as a
specification of the component, the software design or the data
model.

Typically, component testing occurs with access to the code

being tested and with the support of a development
environment, such as a unit test framework or debugging tool.
In practice, component testing usually involves the programmer
who wrote the code.
Defects are typically fixed as soon as they are found, without
formally managing these defects.

One app roach to component testing is to prepare and

automate test cases before coding. This is called a test-first app
roach or test-driven development. TDD
This approach is highly iterative and is based on cycles of
developing test cases, then building and integrating small pieces
of code, and executing the component tests correcting any
issues and iterating until they pass.

Integration Testing:
Integration testing tests interfaces between components,
interactions with different parts of a system, such as the
operating system, file system and hardware.

There may be more than one level of integration testing

 Component integration testing tests the interactions
between software components and is done after
component testing

15
  System integration testing tests the inter actions between
different systems or between hard ware and software and
may be done after system testing.

The greater the scope of integration, the more difficult it

becomes to isolate defects to a specific component or system,
which may lead to increased risk and addition al time for
troubleshooting.

Systematic integration strategies may be based on the system

architecture (such as top-down and bottom-u p), function al
tasks, transaction processing sequences.

In order to ease fault isolation and detect defects early,

integration should normally be incremental rather than “big
bang” (performed as a whole).

Testing of specific n on-functional characteristics (e.g.,

performance) may be included in integration testing

At each stage of integration, testers concentrate solely on the

integration itself. For example, if they are integrating module A
with module B they are interested in testing the communication
between the modules, not the functionality of the individual
module as that was done during component testing.

Ideally, testers should understand the architecture and

influence integration planning.

System Testing

16
System testing is concerned with the behavior of a whole
system/product.

In system testing, the test environment should correspond to

the final target or production environment as much as possible
in order to minimize the risk of environment-specific failures not
being found in testing.

System testing should investigate functional and non-functional

requirements of the system.
Testers also need to deal with incomplete or undocumented
requirements.

System testing of functional requirements starts by using the

most appropriate specification-based (black-box) techniques for
the aspect of the system to be tested. Structure-based
techniques (white-box) may then be used to assess the
thoroughness of the testing with respect to a structural
element.

An independent test team often carries out system testing.

Acceptance Testing
Acceptance testing is often the responsibility of the customers
or users of a system; other stakeholders may be involved as
well.

The goal in acceptance testing is to establish confidence in the

system, parts of the system or specific non-functional
characteristics of the system.

17
Finding defects is not the main focus in acceptance testing.
Acceptance testing may assess the system’s readiness for
deployment and use

Acceptance testing may occur at various times in the life cycle,

for example:
 A COTS (Commercial off the Shelf)software product m ay
be acceptance tested when it is installed or integrated.
 Acceptance testing of the usability of a component may be
done during component testing.
 Acceptance testing of a new functional enhancement may
come before system testing.

Typical forms of acceptance testing include the following:

User acceptance testing

Typically verifies the fitness for use of the system by business
users.

Operational (acceptance) testing

The acceptance of the system by the system administrators,
including:
 Testing of backup/restore
 Disaster recovery
 User management Maintenance tasks
 Data load and migration tasks
 Periodic checks of security vulnerabilities

18
Alpha and beta (or field) testing
Developers of market, or COTS, software often want to get
feedback from potential or existing customers in their market
before the software product is put up for sale commercially.

Alpha testing is performed at the developing organization’s site

but not by the developing team, but still within the company. Unit
testing, integration testing and system testing when combined
together is known as alpha testing.

Beta testing or field-testing is performed by customers or

potential customers at their own locations.
Organizations may use other terms as well, such as factory
acceptance testing and site acceptance testing for systems t hat
are tested before and after being moved to a customer’s site.

Test Types
Levels of testing include different methodologies that can be
used while conducting software testing. The main levels of
software testing are:
 Functional Testing
 Non-functional Testing
 Structural Testing
 Re-testing and Regression.

Functional Testing
The functions that a system, subsystem or component are to
perform may be described in work products such as a
requirements specification, use cases , or a functional

19
specification, or they may be undocumented.
T he functions are “what” the system does. Function al tests are
based on functions and features (described in documents or
understood by the testers) and their interoperability with
specific systems. Functional testing considers the external
behavior of the software (black-box testing).
A type of functional testing, security testing, investigates the
functions (e.g., a fire wall) relating to detection of threats, such as
viruses, from malicious outsiders. Another type of functional
testing, interoperability testing, evaluates the capability of the
software product to interact with one or more specified
component s or systems.

Non-functional Testing
Non-functional testing includes, but is not limited to, performance
testing, load testing, stress testing, usability testing, maintain
ability testing, reliability testing and portability testing.
It is the testing of “how” the system works. Non-functional testing
may be performed at all test levels.
The term non-functional testing describes the tests required to
measure characteristics of systems and software that can be
quantified on a varying scale, such as response times for
performance testing.
Non-function al testing considers the external behavior of the
software and in most cases uses black-box test design techniques
to accomplish that.

Structural Testing
Structural (white-box) testing may be performed at all test levels.
Structural techniques are best used after specification-based
techniques, in order to help measure the thoroughness of testing

20
through assessment of coverage of a type of structure.

Coverage is the extent that a structure has been exercised by a

test suite, expressed as a percentage of the items being covered.
If coverage is not 100%, then more tests may be designed to test
those items that were missed to increase coverage.

At all test levels, but especially in component testing and

component integration testing, tools can be used to measure the
code coverage of elements, such as statements or decisions.

Structural testing approaches can also be applied at system,

system integration or acceptance testing levels.

Structural Testing Techniques:

Statement Coverage - This technique is aimed at exercising all
programming statements with minimal tests.
Branch Coverage - This technique is running a series of tests to
ensure that all branches are tested at least once.
Path Coverage - This technique corresponds to testing all possible
paths which means that each statement and branch are covered.

Re-testing and Regression Testing:

Re-Testing can be of two ways

 Re-execution of Testcases on same application build with
different inputs or testdata.
 Retesting is testing of a particular bug after it has been
fixed. Usually tester raises the bug when they find it while
testing the product or its component. This bug is assigned

21
 to a developer and he fixes it. Post fixing the bug is
assigned to the tester for its verification. This testing is also
known as retesting.

Regression testing is the repeated testing of an already tested

program, after modification, to discover any defects introduced
or uncovered as a result of the change(s). These defects ma y be
either in the software being tested, or in another related o r
unrelated software component. It is performed when the
software, or its environment, is changed. The extent of regression
testing is based on the risk of not finding defects in software that
was working previously.

Other Testing Types

What is Static and Dynamic testing?

Static security testing is used to analyse software in a non-runtime
environment – when the software is inactive, and not in operation. This
allows developers to perform a thorough inspection of every aspect of
the software’s source code, in order to identify and remedy any flaws,
back-doors, and in some instances, malicious code. Static testing is
often referred to as verification: the evaluation of the development
process.

Dynamic testing is performed in a runtime environment, with security

analysis carried out whilst software is in operation. With a given input,
the software’s actual output is compared to its expected output. This
allows developers to analyze the functional behavior of a piece of
software, and monitor its interaction with system memory, CPU
function and overall system performance. Dynamic testing is often
referred to as validation: the evaluation of a finished product.
22
What is Maintenance testing?
Once a system is deployed it is in service for years and decades. During
this time the system and its operational environment is often
corrected, changed or extended. Testing that is provided during this
phase is called maintenance testing.
Usually maintenance testing is consisting of two parts:
First one is, testing the changes that has been made because of the
correction in the system or if the system is extended or because of
some additional features added to it.
Second one is regression tests to prove that the rest of the system has
not been affected by the maintenance work.

What is Smoke Testing?

Smoke Testing is a testing technique that is inspired from hardware
testing, which checks for the smoke from the hardware components
once the hardware's power is switched on. Similarly in Software testing
context, smoke testing refers to testing the basic functionality of the
build.
If the Test fails, build is declared as unstable and it is NOT tested
anymore until the smoke test of the build passes.
Smoke Testing - Features:
 Identifying the business critical functionalities that a product must
satisfy.
 Designing and executing the basic functionalities of the
application.
 Ensuring that the smoke test passes each and every build in order
to proceed with the testing.

23
  Smoke Tests enables uncovering obvious errors which saves time
and effort of test team.
 Smoke Tests can be manual or automated.

What is Sanity Testing?

Sanity testing, a software testing technique performed by the test team
for some basic tests. The aim of basic test is to be conducted whenever
a new build is received for testing. The terminologies such as Smoke
Test or Build Verification Test or Basic Acceptance Test or Sanity Test
are interchangeably used , however, each one of them is used under a
slightly different scenario.
 Sanity test is usually unscripted, helps to identify the dependent
missing functionalities. It is used to determine if the section of the
application is still working after a minor change.
 Sanity testing can be narrow and deep. Sanity test is a narrow
regression test that focuses on one or a few areas of functionality.

What is confirmation testing?

When a test fails because of the defect then that defect is reported and
a new version of the software is expected that has had the defect fixed.
In this case we need to execute the test again to confirm that whether
the defect got actually fixed or not. This is known as confirmation
testing and also known as re-testing. It is important to ensure that the
test is executed in exactly the same way it was the first time using the
same inputs, data and environments.

What is random/monkey testing?

Monkey testing is a software testing technique in which the testing is
performed on the system under test randomly. The Input data that is
used to test also generated randomly and keyed into the system.

Characteristics of Monkey Testing:

24
Following are the characteristics of the Monkey testing:
 This testing is so random that the tester may not be able to
reproduce the error/defect.
 The scenario may NOT be definable and may NOT be the correct
business case.
 Monkey Testing needs testers with very good domain and
technical expertise.
Advantages of Monkey Testing:
 As the scenarios that are tested are adhoc, system might be under
stress so that we can also check for the server responses.
 This testing is adopted to complete the testing, in particular if
there is a resource/time crunch.

What is Adhoc testing?

When a software testing performed without proper planning and
documentation, it is said to be Adhoc Testing. Such kind of tests is
executed only once unless we uncover the defects.

Adhoc Tests are done after formal testing is performed on the

application.
Adhoc methods are the least formal type of testing as it is NOT a
structured approach. Hence, defects found using this method are hard
to replicate as there are no test cases aligned for those scenarios.

Testing is carried out with the knowledge of the tester about the
application and the tester tests randomly without following the
specifications/requirements.
Hence the success of Adhoc testing depends upon the capability of the
tester, who carries out the test. The tester has to find defects without
any proper planning and documentation, solely based on tester's
intuition.

25
When to Execute Adhoc Testing?
 Adhoc testing can be performed when there is limited time to do
exhaustive testing and usually performed after the formal test
execution. Adhoc testing will be effective only if the tester has in-
depth understanding about the System under Test.

Forms of Adhoc Testing:

 Buddy Testing: Two buddies, one from development team and

one from test team mutually work on identifying defects in the
same module. Buddy testing helps the testers develop better test
cases while development team can also make design changes
early. This kind of testing happens usually after completing the
unit testing.

 Pair Testing: Two testers are assigned the same modules and they
share ideas and work on the same systems to find defects. One
tester executes the tests while another tester records the notes on
their findings.

 Monkey Testing: Testing is performed randomly without any test

cases in order to break the system.

What is State Transition Testing?

State Transition testing, a black box testing technique, in which outputs

are triggered by changes to the input conditions or changes to 'state' of
the system. In other words, tests are designed to execute valid and
invalid state transitions.

26
Any system where you get a different output for the same input,
depending on what has happened before, is a finite state system.

The above diagram shows an example of entering a Personal Identity

Number (PIN) to a bank account. The states are shown as circles, the
transitions as lines with arrows and the events as the text near the
transitions. (‘We have not shown the actions explicitly on this diagram,
but they would be a message to the customer saying things such as
‘Please enter your PIN’.)

The state diagram shows seven states but only four possible events
(Card inserted, Enter PIN, PIN OK and PIN not OK). We have not
specified all of the possible transitions here – there would also be a
time-out from ‘wait for PIN’ and from the three tries which would go
back to the start state after the time had elapsed and would probably
eject the card. There would also be a transition from the ‘eat card’ state
back to the start state. We have not specified all the possible events
either – there would be a ‘cancel’ option from ‘wait for PIN’ and from
the three tries, which would also go back to the start state and eject
the card.

What is Backward Compatibility Testing?

Type of software testing performed to check newer version of the

27
software can work successfully installed over previous version of the
software and newer version of the software works as fine with table
structure, data structures, files that were created by previous version of
the software.

What is Boundary Value Testing (BVT)?

Boundary Value Testing is a testing technique that is based on concept

“error aggregates at boundaries”. In this testing technique, testing is
done extensively to check for defects at boundary conditions. If a field
accepts value 1 to 100 then testing is done for values 0, 1, 2, 99, 100
and 101.

What is Equivalence Partitioning?

Equivalence partitioning technique is used in black box and grey box

testing types. Equivalence partitioning classifies test data into
Equivalence classes as positive Equivalence classes and negative
Equivalence classes, such classification ensures both positive and
negative conditions are tested.

For example, if a program accepts integer values only from 1 to 10. The
possible test cases for such a program would be the range of all
integers. In such a program, all integers up to 0 and above 10 will cause
an error. So, it is reasonable to assume that if 11 will fail, all values
above it will fail and vice versa.
If an input condition is a range of values, let one valid equivalence class
be the range (0 or 10 in this example). Let the values below and above
the range be two respective invalid equivalence values (i.e. -1 and 11).
Therefore, the above three partition values can be used as test cases
for the above example.

28
What is Localization Testing?

Localization testing a type of software testing performed by software

testers, in this type of testing, software is expected to adapt to a
particular locale, it should support a particular locale/language in terms
of display, accepting input in that particular locale, display, font, date
time, currency etc., related to a particular locale. For e.g. many web
applications allow choice of locale like English, French, German or
Japanese. So once locale is defined or set in the configuration of
software, software is expected to work as expected with a set
language/locale.

What is Performance Testing?

It is mostly used to identify any bottlenecks or performance issues

rather than finding bugs in software. There are different causes that
contribute in lowering the performance of software.
 Network delay
 Client-side processing
 Database transaction processing
 Load balancing between servers
 Data rendering
Performance testing can be either qualitative or quantitative and can
be divided into different sub-types such as Load testing and Stress
testing.

What is Load Testing?

It is a process of testing the behavior of software by applying maximum

load in terms of software accessing and manipulating large input data.
It can be done at both normal and peak load conditions. This type of

29
testing identifies the maximum capacity of software and its behavior at
peak time.

Most of the time, load testing is performed with the help of automated
tools such as Load Runner, AppLoader, IBM Rational Performance
Tester, Apache JMeter, Silk Performer, Visual Studio Load Test, etc.

Virtual users (VUsers) are defined in the automated testing tool and the
script is executed to verify the load testing for the software. The
number of users can be increased or decreased concurrently or
incrementally based upon the requirements..

What is Stress Testing?

Stress testing includes testing the behavior of software under abnormal

conditions. For example, it may include taking away some resources or
applying a load beyond the actual load limit.

The aim of stress testing is to test the software by applying the

load to the system and taking over the resources used by the
software to identify the breaking point. This testing can be performed
by testing different scenarios such as:

 Shutdown or restart of network ports randomly

 Turning the database on or off
 Running different processes that consume resources such as CPU,
memory, server, etc.

What is UI Testing?

30
UI testing involves testing the Graphical User Interface of the Software.
UI testing ensures that the GUI functions according to the requirements
and tested in terms of color, alignment, size, and other properties.

What is Usability Testing?

Usability testing is testing for 'user-friendliness'. A way to evaluate and
measure how users interact with a software product or site. Tasks are
given to users and observations are made.

What is Security Testing?

Security testing involves testing the software in order to identify any

flaws and gaps from security and vulnerability point of view. Listed
below are the main aspects that security testing should ensure:

 Confidentiality
 Integrity
 Authentication
 Availability
 Authorization
 Non-repudiation
 Software is secure against known and unknown vulnerabilities
 Software data is secure
 Software is according to all security regulations
 Input checking and validation
 SQL insertion attack
 Injection flaws
 Session management issues
 Cross-site scripting attacks
 Buffer overflows vulnerabilities
 Directory traversal attacks

31
What is Portability Testing?

Portability testing includes testing a software with the aim to

ensure its reusability and that it can be moved from another
software as well. Following are the strategies that can be used for
portability testing.
 Transferring installed software from one computer to another.
 Building executable (.exe) to run the software on different
platforms.

Portability testing can be considered as one of the sub-parts of system

testing, as this testing type includes overall testing of a software
with respect to its usage over different environments. Computer
hardware, operating systems, and browsers are the major focus of
portability testing.

What is Recovery Testing?

Testing how well a system recovers from crashes, hardware failures, or

other catastrophic problems.
It is a type of non-functional testing technique. Recovery testing is the
forced failure of the software to verify if the recovery is successful.

What is Penetration Testing?

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.

32
It is a type of security testing. Penetration testing is done to tests how
secure software and its environments (Hardware, Operating system,
and network) are when subject to attack by an external or internal
intruder.
An intruder can be a human/hacker or malicious programs. Pentest
uses methods to forcibly intrude (by brute force attack) or by using a
weakness (vulnerability) to gain access to a software or data or
hardware with an intent to expose ways to steal, manipulate or corrupt
data, software files or configuration.
Penetration Testing is a way of ethical hacking, an experienced
Penetration tester will use the same methods and tools that a hacker
would use but the intention of Penetration tester is to identify
vulnerability and get them fixed before a real hacker or malicious
program exploits it.

Recovery Plan - Steps:

 Determining the feasibility of the recovery process.
 Verification of the backup facilities.
 Ensuring proper steps are documented to verify the compatibility
of backup facilities.
 Providing Training within the team.
 Demonstrating the ability of the organization to recover from all
critical failures.
 Maintaining and updating the recovery plan at regular intervals.

What is Endurance Testing?

Type of testing which checks for memory leaks or other problems that
may occur with prolonged execution. It is usually performed by
performance engineers.

33
What is Exploratory Testing?

Black box testing technique performed without planning and

documentation. It is usually performed by manual testers.

What is Storage Testing?

Testing type that verifies the program under test stores data files in the
correct directories and that it reserves sufficient space to prevent
unexpected termination resulting from lack of space. It is usually
performed by the testing team.

What is Incremental integration testing?

Bottom up approach for testing i.e continuous testing of an application

as new functionality is added; Application functionality and modules
should be independent enough to test separately. done by
programmers or by testers.

What is Bottom up Integration testing?

Bottom-up integration testing is an integration testing approaches

where testing starts with smaller pieces or sub-systems of the software
till all the way up covering entire software system. Bottom-up
integration testing begins with small portions of the software and
eventually scales up in terms of size, complexity, and completeness.

Some Testing Terms:

34
• Bug: A software bug may be defined as a coding error that causes an
unexpected defect, fault or flaw. In other words, if a program does not
perform as intended, it is most likely a bug.

• Error: A mismatch between the program and its specification is an

error in the program.

• Defect: Defect is the variance from a desired product attribute (it can
be a wrong, missing or extra data). It can be of two types – Defect from
the product or a variance from customer/user expectations. It is a flaw
in the software system and has no impact until it affects the
user/customer and operational system. 90% of all the defects can be
caused by process problems.

• Failure: A defect that causes an error in operation or negatively

impacts a user/ customer.

What is Bug Life Cycle?

35
1. New: When a defect is logged and posted for the first time. It’s
state is given as new.
2. Assigned: After the tester has posted the bug, the lead of the
tester approves that the bug is genuine and he assigns the bug to
corresponding developer and the developer team. It’s state given
as assigned.
3. Open: At this state the developer has started analyzing and
working on the defect fix.
4. Fixed: When developer makes necessary code changes and
verifies the changes then he/she can make bug status as ‘Fixed’
and the bug is passed to testing team.
5. Pending retest: After fixing the defect the developer has given
that particular code for retesting to the tester. Here the testing is
pending on the testers end. Hence its status is pending retest.
6. Retest: At this stage the tester do the retesting of the changed
code which developer has given to him to check whether the
defect got fixed or not.
7. Verified: The tester tests the bug again after it got fixed by the
developer. If the bug is not present in the software, he approves
that the bug is fixed and changes the status to “verified”.
8. Reopen: If the bug still exists even after the bug is fixed by the
developer, the tester changes the status to “reopened”. The bug
goes through the life cycle once again.
9. Closed: Once the bug is fixed, it is tested by the tester. If the
tester feels that the bug no longer exists in the software, he
changes the status of the bug to “closed”. This state means that
the bug is fixed, tested and approved.
10. Duplicate: If the bug is repeated twice or the two bugs
mention the same concept of the bug , then one bug status is
changed to “duplicate“.

36
 11. Rejected: If the developer feels that the bug is not genuine,
he rejects the bug. Then the state of the bug is changed to
“rejected”.
12. Deferred: The bug, changed to deferred state means the
bug is expected to be fixed in next releases. The reasons for
changing the bug to this state have many factors. Some of them
are priority of the bug may be low, lack of time for the release or
the bug may not have major effect on the software.
13. Not a bug: The state given as “Not a bug” if there is no
change in the functionality of the application. For an example: If
customer asks for some change in the look and field of the
application like change of color of some text then it is not a bug
but just some change in the looks of the application.

Explain Software testing life cycle?

Software Testing is not a just a single activity. It consists of series of

activities carried out methodologically to help certify your software
product. These activities (stages) constitute the Software Testing Life
Cycle (STLC).
The different stages in Software Test Life Cycle -

Requirement Analysis

37
During this phase, test team studies the requirements from a testing
point of view to identify the testable requirements. The QA team may
interact with various stakeholders (Client, Business Analyst, Technical
Leads, System Architects etc) to understand the requirements in detail.
Requirements could be either Functional (defining what the software
must do) or Non Functional (defining system performance
/securityavailability ) .Automation feasibility for the given testing
project is also done in this stage.
Activities

 Identify types of tests to be performed.

 Gather details about testing priorities and focus.
 Prepare Requirement Traceability Matrix (RTM).
 Identify test environment details where testing is supposed to be
carried out.
 Automation feasibility analysis (if required).

Test Planning

This phase is also called Test Strategy phase. Typically , in this stage, a
Senior QA manager will determine effort and cost estimates for the
project and would prepare and finalize the Test Plan.
Activities

 Preparation of test plan/strategy document for various types of

testing
 Test tool selection
 Test effort estimation
 Resource planning and determining roles and responsibilities.
 Training requirement

38
Deliverables

 Test plan /strategy document.

 Effort estimation document.

Test Case Development

This phase involves creation, verification and rework of test cases &
test scripts. Test data , is identified/created and is reviewed and then
reworked as well.
Activities

 Create test cases, automation scripts (if applicable)

 Review and baseline test cases and scripts
 Create test data (If Test Environment is available)

Deliverables

 Test cases/scripts
 Test data

Test Environment Setup

Test environment decides the software and hardware conditions under

which a work product is tested. Test environment set-up is one of the
critical aspects of testing process and can be done in parallel with Test
Case Development Stage. Test team may not be involved in this activity
if the customer/development team provides the test environment in
which case the test team is required to do a readiness check (smoke
testing) of the given environment.

39
Activities

 Understand the required architecture, environment set-up and

prepare hardware and software requirement list for the Test
Environment.
 Setup test Environment and test data
 Perform smoke test on the build

Deliverables

 Environment ready with test data set up

 Smoke Test Results.

Test Execution:

During this phase test team will carry out the testing based on the test
plans and the test cases prepared. Bugs will be reported back to the
development team for correction and retesting will be performed.

Activities

 Execute tests as per plan

 Document test results, and log defects for failed cases
 Map defects to test cases in RTM
 Retest the defect fixes
 Track the defects to closure

Deliverables

 Test cases updated with results

 Defect reports

Test Cycle Closure

40
Testing team will meet, discuss and analyze testing artifacts to identify
strategies that have to be implemented in future, taking lessons from the
current test cycle. The idea is to remove the process bottlenecks for
future test cycles and share best practices for any similar projects in
future.

Activities

 Evaluate cycle completion criteria based on Time, Test coverage,

Cost, Software, Critical Business Objectives , Quality
 Prepare test metrics based on the above parameters.
 Document the learning out of the project
 Prepare Test closure report
 Qualitative and quantitative reporting of quality of the work
product to the customer.
 Test result analysis to find out the defect distribution by type and
severity.

What is Waterfall model- advantages, disadvantages and when

to use it?

The Waterfall Model was first Process Model to be introduced. It is also

referred to as a linear-sequential life cycle model. It is very simple to
understand and use. In a waterfall model, each phase must be completed
fully before the next phase can begin. This type of model is basically
used for the for the project which is small and there are no uncertain
requirements. At the end of each phase, a review takes place to
determine if the project is on the right path and whether or not to
continue or discard the project. In this model the testing starts only after
the development is complete. In waterfall model phases do not overlap.

41
Diagram of Waterfall-model:

Advantages of waterfall model:

 This model is simple and easy to understand and use.

 It is easy to manage due to the rigidity of the model – each phase
has specific deliverables and a review process.
 In this model phases are processed and completed one at a time.
Phases do not overlap.
 Waterfall model works well for smaller projects where
requirements are very well understood.

Disadvantages of waterfall model:

42
  Once an application is in the testing stage, it is very difficult to go
back and change something that was not well-thought out in the
concept stage.
 No working software is produced until late during the life cycle.
 High amounts of risk and uncertainty.
 Not a good model for complex and object-oriented projects.
 Poor model for long and ongoing projects.
 Not suitable for the projects where requirements are at a
moderate to high risk of changing.

When to use the waterfall model:

 This model is used only when the requirements are very well
known, clear and fixed.
 Product definition is stable.
 Technology is understood.
 There are no ambiguous requirements
 Ample resources with required expertise are available freely
 The project is short.

Very less customer enter action is involved during the development of

the product. Once the product is ready then only it can be demoed to the
end users. Once the product is developed and if any failure occurs then
the cost of fixing such issues are very high, because we need to update
everywhere from document till the logic.

What is V-model- advantages, disadvantages and when to use

it?

V- model means Verification and Validation model. Just like the

waterfall model, the V-Shaped life cycle is a sequential path of
execution of processes. Each phase must be completed before the next
phase begins. Testing of the product is planned in parallel with a
corresponding phase of development in V-model.

43
Diagram of V-model:

The various phases of the V-model are as follows:

Requirements like BRS and SRS begin the life cycle model just like the
waterfall model. But, in this model before development is started, a
system test plan is created. The test plan focuses on meeting the
functionality specified in the requirements gathering.

The high-level design (HLD) phase focuses on system architecture and

design. It provide overview of solution, platform, system, product and
service/process. An integration test plan is created in this phase as well
in order to test the pieces of the software systems ability to work
together.

The low-level design (LLD) phase is where the actual software

components are designed. It defines the actual logic for each and every
component of the system. Class diagram with all the methods and
relation between classes comes under LLD. Component tests are created
in this phase as well.
44
The implementation phase is, again, where all coding takes place. Once
coding is complete, the path of execution continues up the right side of
the V where the test plans developed earlier are now put to use.

Coding: This is at the bottom of the V-Shape model. Module design is

converted into code by developers.

Advantages of V-model:

 Simple and easy to use.

 Testing activities like planning, test designing happens well before
coding. This saves a lot of time. Hence higher chance of success
over the waterfall model.
 Proactive defect tracking – that is defects are found at early stage.
 Avoids the downward flow of the defects.
 Works well for small projects where requirements are easily
understood.

Disadvantages of V-model:

 Very rigid and least flexible.

 Software is developed during the implementation phase, so no
early prototypes of the software are produced.
 If any changes happen in midway, then the test documents along
with requirement documents has to be updated.

When to use the V-model:

 The V-shaped model should be used for small to medium sized

projects where requirements are clearly defined and fixed.
 The V-Shaped model should be chosen when ample technical
resources are available with needed technical expertise.

45
High confidence of customer is required for choosing the V-Shaped
model approach. Since, no prototypes are produced, there is a very high
risk involved in meeting customer expectations.

What is Incremental model- advantages, disadvantages and

when to use it?

In incremental model the whole requirement is divided into various

builds. Multiple development cycles take place here, making the life
cycle a “multi-waterfall” cycle. Cycles are divided up into smaller,
more easily managed modules. Each module passes through the
requirements, design, implementation and testing phases. A working
version of software is produced during the first module, so you have
working software early on during the software life cycle. Each
subsequent release of the module adds function to the previous release.
The process continues till the complete system is achieved.

For example:

In the diagram above when we

work incrementally we are adding piece by piece but expect that each
piece is fully finished. Thus keep on adding the pieces until it’s
complete. As in the image above a person has thought of the application.
Then he started building it and in the first iteration the first module of
the application or product is totally ready and can be demoed to the
customers. Likewise in the second iteration the other module is ready
and integrated with the first module. Similarly, in the third iteration the
whole product is ready and integrated. Hence, the product got ready step
by step.

Diagram of Incremental model:

46
Advantages of Incremental model:

 Generates working software quickly and early during the software

life cycle.
 This model is more flexible – less costly to change scope and
requirements.
 It is easier to test and debug during a smaller iteration.
 In this model customer can respond to each built.
 Lowers initial delivery cost.
 Easier to manage risk because risky pieces are identified and
handled during it’d iteration.

Disadvantages of Incremental model:

 Needs good planning and design.

 Needs a clear and complete definition of the whole system before
it can be broken down and built incrementally.
 Total cost is higher than waterfall.

When to use the Incremental model:

47
  This model can be used when the requirements of the complete
system are clearly defined and understood.
 Major requirements must be defined; however, some details can
evolve with time.
 There is a need to get a product to the market early.
 A new technology is being used
 Resources with needed skill set are not available
 There are some high risk features and goals.

What is Agile model – advantages, disadvantages and when to

use it?

Agile development model is also a type of Incremental model. Software

is developed in incremental, rapid cycles. This results in small
incremental releases with each release building on previous
functionality. Each release is thoroughly tested to ensure software
quality is maintained. It is used for time critical applications. Extreme
Programming (XP) is currently one of the most well known agile
development life cycle model.

Diagram of Agile model:

Advantages of Agile model:

48
  Customer satisfaction by rapid, continuous delivery of useful
software.
 People and interactions are emphasized rather than process and
tools. Customers, developers and testers constantly interact with
each other.
 Working software is delivered frequently (weeks rather than
months).
 Face-to-face conversation is the best form of communication.
 Close, daily cooperation between business people and
developers.
 Continuous attention to technical excellence and good design.
 Regular adaptation to changing circumstances.
 Even late changes in requirements are welcomed

Disadvantages of Agile model:

 In case of some software deliverables, especially the large ones, it

is difficult to assess the effort required at the beginning of the
software development life cycle.
 There is lack of emphasis on necessary designing and
documentation.
 The project can easily get taken off track if the customer
representative is not clear what final outcome that they want.
 Only senior programmers are capable of taking the kind of
decisions required during the development process. Hence it has
no place for newbie programmers, unless combined with
experienced resources.

When to use Agile model:

 When new changes are needed to be implemented. The freedom

agile gives to change is very important. New changes can be
implemented at very little cost because of the frequency of new
increments that are produced.

49
  To implement a new feature the developers need to lose only the
work of a few days, or even only hours, to roll back and
implement it.
 Unlike the waterfall model in agile model very limited planning is
required to get started with the project. Agile assumes that the
end users’ needs are ever changing in a dynamic business and IT
world. Changes can be discussed and features can be newly
effected or removed based on feedback. This effectively gives the
customer the finished system they want or need.
 Both system developers and stakeholders alike, find they also get
more freedom of time and options than if the software was
developed in a more rigid sequential way. Having options gives
them the ability to leave important decisions until more or better
data or even entire hosting programs are available; meaning the
project can continue to move forward without fear of reaching a
sudden standstill.

What is Spiral model- advantages, disadvantages and when to

use it?

The spiral model is similar to the incremental model, with more

emphasis placed on risk analysis. The spiral model has four phases:
Planning, Risk Analysis, Engineering and Evaluation. A software project
repeatedly passes through these phases in iterations (called Spirals in
this model). The baseline spiral, starting in the planning phase,
requirements are gathered and risk is assessed. Each subsequent spirals
builds on the baseline spiral.

50
Planning Phase: Requirements are gathered during the planning phase.
Requirements like ‘BRS’ that is ‘Bussiness Requirement Specifications’
and ‘SRS’ that is ‘System Requirement specifications’.

Risk Analysis: In the risk analysis phase, a process is undertaken to

identify risk and alternate solutions. A prototype is produced at the end
of the risk analysis phase. If any risk is found during the risk analysis
then alternate solutions are suggested and implemented.

Engineering Phase: In this phase software is developed, along with

testing at the end of the phase. Hence in this phase the development and
testing is done.

Evaluation phase: This phase allows the customer to evaluate the

output of the project to date before the project continues to the next
spiral.

Diagram of Spiral model:

Advantages of Spiral model:

 High amount of risk analysis hence, avoidance of Risk is enhanced.

51
  Good for large and mission-critical projects.
 Strong approval and documentation control.
 Additional Functionality can be added at a later date.
 Software is produced early in the software life cycle.

Disadvantages of Spiral model:

 Can be a costly model to use.

 Risk analysis requires highly specific expertise.
 Project’s success is highly dependent on the risk analysis phase.
 Doesn’t work well for smaller projects.

When to use Spiral model:

 When costs and risk evaluation is important

 For medium to high-risk projects
 Long-term project commitment unwise because of potential
changes to economic priorities
 Users are unsure of their needs
 Requirements are complex
 New product line
 Significant changes are expected (research and exploration)

What is Prototype model- advantages, disadvantages and when

to use it?

The basic idea here is that instead of freezing the requirements before a
design or coding can proceed, a throwaway prototype is built to
understand the requirements. This prototype is developed based on the
currently known requirements. By using this prototype, the client can get
an “actual feel” of the system, since the interactions with prototype can

52
enable the client to better understand the requirements of the desired
system. Prototyping is an attractive idea for complicated and large
systems for which there is no manual process or existing system to help
determining the requirements.

The prototype are usually not complete systems and many of the details
are not built in the prototype. The goal is to provide a system with
overall functionality.

Diagram of Prototype model:

Advantages of Prototype model:

 Users are actively involved in the development

 Since in this methodology a working model of the system is
provided, the users get a better understanding of the system
being developed.
 Errors can be detected much earlier.
 Quicker user feedback is available leading to better solutions.
 Missing functionality can be identified easily
 Confusing or difficult functions can be identified
Requirements validation, Quick implementation of, incomplete,
but
functional, application.

Disadvantages of Prototype model:

53
• Leads to implementing and then repairing way of building systems.

• Practically, this methodology may increase the complexity of the

system as scope of the system may expand beyond original plans.

• Incomplete application may cause application not to be used as the

full system was designed

Incomplete or inadequate problem analysis.

When to use Prototype model:

 Prototype model should be used when the desired system needs

to have a lot of interaction with the end users.
 Typically, online systems, web interfaces have a very high amount
of interaction with end users, are best suited for Prototype model.
It might take a while for a system to be built that allows ease of
use and needs minimal training for the end user.
 Prototyping ensures that the end users constantly work with the
system and provide a feedback which is incorporated in the
prototype to result in a useable system. They are excellent for
designing good human computer interface systems.

What is RAD model- advantages, disadvantages and when to

use it?

RAD model is Rapid Application Development model. It is a type of

incremental model. In RAD model the components or functions are
developed in parallel as if they were mini projects. The developments
are time boxed, delivered and then assembled into a working prototype.
This can quickly give the customer something to see and use and to
provide feedback regarding the delivery and their requirements.

54
Diagram of RAD-Model:

The phases in the rapid application development (RAD) model are:

Business modeling: The information flow is identified between various

business functions.
Data modeling: Information gathered from business modeling is used to
define data objects that are needed for the business.

Process modeling: Data objects defined in data modeling are converted

to achieve the business information flow to achieve some specific
business objective. Description are identified and created for CRUD of
data objects.

55
Application generation: Automated tools are used to convert process
models into code and the actual system.

Testing and turnover: Test new components and all the interfaces.

Advantages of the RAD model:

 Reduced development time.

 Increases reusability of components
 Quick initial reviews occur
 Encourages customer feedback
 Integration from very beginning solves a lot of integration issues.

Disadvantages of RAD model:

 Depends on strong team and individual performances for

identifying business requirements.
 Only system that can be modularized can be built using RAD
 Requires highly skilled developers/designers.
 High dependency on modeling skills
 Inapplicable to cheaper projects as cost of modeling and
automated code generation is very high.

When to use RAD model:

 RAD should be used when there is a need to create a system that

can be modularized in 2-3 months of time.
 It should be used if there’s high availability of designers for
modeling and the budget is high enough to afford their cost along
with the cost of automated code generating tools.
 RAD SDLC model should be chosen only if resources with high
business knowledge are available and there is a need to produce
the system in a short span of time (2-3 months).

56
What is the difference between Severity and Priority?

There are two key things in defects of the software testing. They are:

1) Severity

2) Priority

What is the difference between Severity and Priority?

1) Severity:

It is the extent to which the defect can affect the software. In other words
it defines the impact that a given defect has on the system. For
example: If an application or web page crashes when a remote link is
clicked, in this case clicking the remote link by an user is rare but the
impact of application crashing is severe. So the severity is high but
priority is low.

Severity can be of following types:

 Critical: The defect that results in the termination of the complete

system or one or more component of the system and causes
extensive corruption of the data. The failed function is unusable
and there is no acceptable alternative method to achieve the
required results then the severity will be stated as critical.
 Major: The defect that results in the termination of the complete
system or one or more component of the system and causes
extensive corruption of the data. The failed function is unusable
but there exists an acceptable alternative method to achieve the
required results then the severity will be stated as major.

57
  Moderate: The defect that does not result in the termination, but
causes the system to produce incorrect, incomplete or
inconsistent results then the severity will be stated as moderate.
 Minor: The defect that does not result in the termination and
does not damage the usability of the system and the desired
results can be easily obtained by working around the defects then
the severity is stated as minor.
 Cosmetic: The defect that is related to the enhancement of the
system where the changes are related to the look and field of the
application then the severity is stated as cosmetic.

2) Priority:

Priority defines the order in which we should resolve a defect. Should

we fix it now, or can it wait? This priority status is set by the tester to the
developer mentioning the time frame to fix the defect. If high priority is
mentioned then the developer has to fix it at the earliest. The priority
status is set based on the customer requirements. For example: If the
company name is misspelled in the home page of the website, then the
priority is high and severity is low to fix it.

Priority can be of following types:

 Low: The defect is an irritant which should be repaired, but repair

can be deferred until after more serious defect have been fixed.
 Medium: The defect should be resolved in the normal course of
development activities. It can wait until a new build or version is
created.
 High: The defect must be resolved as soon as possible because
the defect is affecting the application or the product severely. The
system cannot be used until the repair has been done.

Few very important scenarios related to the severity and priority

which are asked during the interview:

58
High Priority & High Severity: An error which occurs on the basic
functionality of the application and will not allow the user to use the
system. (Eg. A site maintaining the student details, on saving record if it,
doesn’t allow to save the record then this is high priority and high
severity bug.)

High Priority & Low Severity: The spelling mistakes that happens on
the cover page or heading or title of an application.

High Severity & Low Priority: An error which occurs on the

functionality of the application (for which there is no workaround) and
will not allow the user to use the system but on click of link which is
rarely used by the end user.

Low Priority and Low Severity: Any cosmetic or spelling issues which
is within a paragraph or in the report (Not on cover page, heading, title).

What is test design technique

By design we mean to create a plan for how to implement an idea and

technique is a method or way for performing a task. So, Test Design is
creating a set of inputs for given software that will provide a set of
expected outputs. The idea is to ensure that the system is working good
enough and it can be released with as few problems as possible for the
average user.

Broadly speaking there are two main categories of Test Design

Techniques. They are:

1. Static Techniques
2. Dynamic Techniques
3. Below is the tree structure of the testing techniques:

59
What is Walkthrough in software testing?

Walkthrough:

 It is not a formal process/review

 It is led by the authors
 Author guide the participants through the document according to
his or her thought process to achieve a common understanding
and to gather feedback.
 Useful for the people if they are not from the software discipline,
who are not used to or cannot easily understand software
development process.
 Is especially useful for higher level documents like requirement
specification, etc.

The goals of a walkthrough:

60
 i. To present the documents both within and outside the software
discipline in order to gather the information regarding the topic
under documentation.
ii. To explain or do the knowledge transfer and evaluate the
contents of the document
iii. To achieve a common understanding and to gather feedback.
iv. To examine and discuss the validity of the proposed solutions

What is static analysis?

Performed on requirement design or code without actually executing the

software or before the code is actually run.

 Goal of static analysis is to find the defects whether or not they

may cause failure.
 Static analysis find defects rather than failures.

What are static analysis tools?

It is typically used by the developers before and sometimes during

component and integration testing.

 It is also used by the designers during software modeling

 Compiler can be considered as a static analysis tool because it
builds a symbol table, points out incorrect usage and checks for
non-compliance to coding language conventions or syntax.

The various features of static analysis tools are discussed below with a
special focus on static code analysis tools because they are the most
common in day to day practice.
Static code analysis tools are as follows:

1. Coding standards: A coding standard consists of a set of

programming rules, naming conventions (e.g. Classes should start

61
 with capital C) and layout specifications (e.g. Indent 4 spaces
towards right). The main advantage of this is that it saves lots of
effort. The added advantage of adapting this approach is that if
we take a well-known coding standard there will probably be
checking tools available that support that standard. Without such
tools the enforcement of coding standard in an organization is
likely to fail because the number of rules in the coding standard is
so large that nobody can remember them all. Another reason is
that if people spend time checking coding standards in reviews
that will distract them from other defects that might otherwise
find and makesing the review process less effective.

2. Code metrics: Code metrics is basically the measurement of depth of

nesting, cyclomatic number and number of lines of code. This
information can be computed not only as the design and code are being
created but also during the changes that are made to the system, to see if
the design or code is becoming bigger, more complex and more difficult
to understand and maintain. The measurement also helps us to decide
between several design alternatives. There are many different types of
structural measures. One of them is Cyclomatic complexity metric. The
Cyclomatic complexity metrics based on the number of decisions in a
program. It is important to tester because it provides an indication of the
amount of testing. There are many ways to calculate cyclomatic
complexity but the easiest way is to sum the number of binary decision
statements (e.g. if, while, for, etc.) and add 1 to it.

For example : below is a simple program;

IF A=360
THEN IF B>C
THEN A=B
ELSE A=C
ENDIF
ENDIF
Print A

62
In the program mentioned above has 2 IF conditions. Thus just add 1 to
it and the cyclomatic complexity is 2+1=3.

We can also calculate the cyclomatic complexity using the control flow.
In the control flow shown below there are 7 nodes (shapes) and 8 edges
(lines). Thus by formula ((no. of edges-no. of nodes)+2) that is (8-7)+2
= 1+2 = 3.

3. Code structure: Code structure tells us about the effort required to

write the code in the first place, to understand the code while making the
change, or to test the code using particular tools or techniques. There are
several aspect of code structure to consider:

 Control flow structure: It addresses the sequence in which the

instructions are executed.
 Data flow structure: It follows the track of the data item as it is
accessed and modified by the code.
 Data structure: It refers to the organization of the data itself,
independent of the program.

63
What is traceability in Software testing?

Test conditions should be able to be linked back to their sources in the

test basis, this is known as traceability. Traceability can be horizontal
through all the test documentation for a given test level (e.g. system
testing, from test conditions through test cases to test scripts) or it can be
vertical through the layers of development documentation (e.g. from
requirements to components).

Now, the question may arise is that Why is traceability important? So,
let’s have a look on the following examples:

 The requirements for a given function or feature have changed.

Some of the fields now have different ranges that can be entered.
Which tests were looking at those boundaries? They now need to
be changed. How many tests will actually be affected by this
change in the requirements? These questions can be answered
easily if the requirements can easily be traced to the tests.

 A set of tests that has run OK in the past has now started creating
serious problems. What functionality do these tests actually
exercise? Traceability between the tests and the requirement
being tested enables the functions or features affected to be
identified more easily.

Before delivering a new release, we want to know whether or not we

have tested all of the specified requirements in the requirements
specification. We have the list of the tests that have passed – was every
requirement tested?

64