SOFTWARE TESTING – Q&A

Q1. Define Software Testing

Software testing is performed once the source code has been written by software engineers.
Software testing is the process of finding defects in the software so that these can be debugged
and debugged and the defect-free software can meet the customer needs and expectations. The
intension of the software testing process is to produce s defect-free system. Quality software can
be achieved through testing. Effective testing reduces the maintenance cost and provides reliable
outcomes. Ineffective testing may lead to software failure. Some failures may be dangerous.
Testing is done with test cases.
Testing Fundamentals: Testing provides a systematic approach to finding defects in software.
Error-free software may fail in performing the required tasks. The goal of software testers is to
locate and debug the effects. Software testers always try to prove that the system is incorrect by
applying test cases. To perform successful testing, testers must have a thorough understanding of
the whole system and its sub systems from requirements specification to implementation.

Q2. Define Errors, Faults, and Failures

The purpose of testing is to produce reliable software. As we know that an unreliable system
may lead to system failure. Software failure can have different terms, such as defect, fault, error,
bug, problem, anomaly, incident, mistake, inconsistency and variance.

Errors:

 These are actual coding mistakes made by developers. In addition, there is a difference in
output of software and desired output, is considered as an error.
 Error is the discrepancy between the actual value of the output of software and the
theoretically correct value of the output for the given input.
 It is observed that most of the times errors occur during writing of programs by
programmers.
 A software tester begins with finding any error in the source code. The error is also
known as variance, mistake, or problem.
Fault:

 When error exists fault occurs. A fault, also known as a bug, is a result of an error which
can cause system to fail.
 Fault is also called defect or bug, which is the manifestation of ton or more errors. The
cause of an error is a fault (Either hardware fault or software fault), which resides
temporarily or permanently in the system.
  Mostly faults are observed at the architecture or design level or they might be a faulty
source code.
Failure:

 Failure is said to be the inability of the system to perform the desired task. Failure occurs
when fault exists in the system.
 Failure is the deviation of the observed behaviour from the specified behaviour. It occurs
when the faulty code is executed leading to an incorrect outcome. A failure is the
manifestation of an error in the system or software.
 A failure occurs because the system is erroneous. An error is caused by a fault and may
propagate to become a failure.
The Cost of Defects:

 Defects may arise from requirements specification, design (architectural and design), and
source codes. The error in requirements specifications mainly arise due to the inability to
understand the requirements and changing requirements.
 The blue print of the system is the base of the successful software just like the blueprint
of a building. Deploying the project without testing will lead to its malfunction especially
in the life critical systems.
 Testing becomes costlier if the errors are not taken care of the earlier phases. The cost of
defects can be measured by the impact of the defects and when we find them. Earlier the
defect is found lesser is the cost of defect.
 For example if error is found in the requirement specifications then it is somewhat cheap
to fix it. The correction to the requirement specification can be done and then it can be re-
issued. In the same way when defect or error is found in the design then the design can be
corrected and it can be re-issued. But if the error is not caught in the specifications and is
not found till the user acceptance then the cost to fix those errors or defects will be way
too expensive.
 If the error is made and the consequent defect is detected in the requirements phase then
it is relatively cheap to fix it. Similarly if an error is made and the consequent defect is
found in the design phase then the design can be corrected and reissued with relatively
little expense.
 The same applies for construction phase. If however, a defect is introduced in the
requirement specification and it is not detected until acceptance testing or even once the
system has been implemented then it will be much more expensive to fix.
 This is because rework will be needed in the specification and design before changes can
be made in construction; because one defect in the requirements may well propagate into
several places in the design and code; and because all the testing work done-to that point
will need to be repeated in order to reach the confidence level in the software that we
require.
  It is quite often the case that defects detected at a very late stage, depending on how
serious they are, are not corrected because the cost of doing so is too expensive.

Testing Process: Testing is a disciplined process of finding and debugging defects to produce
defect-free software. Testing is a process rather than a single activity. Testing phases and
processes vary by development methodologies, but is there any best development methodology
for your test plan? Expert Scott Barber offers his advice. This process starts from test planning
then designing test cases, preparing for execution and evaluating status till the test closure. So,
we can divide the activities within the fundamental test process into the following basic steps:

1) Planning and Control

2) Analysis and Design
3) Implementation and Execution
4) Evaluating exit criteria and Reporting
5) Test Closure activities
The Role Software Tester:
 In the planning and preparation phases of the testing, testers should review and contribute
to test plans, as well as analysing, reviewing and assessing requirements and design
specifications. They may be involved in or even be the primary people identifying test
conditions and creating test designs, test cases, test procedure specifications and test data,
and may automate or help to automate the tests.

 They often set up the test environments or assist system administration and network
management staff in doing so.
 As test execution begins, the number of testers often increases, starting with the work
required to implement tests in the test environment.
 Testers execute and log the tests, evaluate the results and document problems found.
 They monitor the testing and the test environment, often using tools for this task, and
often gather performance metrics. Throughout the testing life cycle; they review each
other’s work, including test specifications, defect reports and test results.
Tasks for testing the software:

 Prepare the test plan and test data

 Design test cases and test scripts
 Set up the test environment
 Perform testing
 Tracks defects in the defect management system
 Participates in the test case review meetings
 Prepare test report
 Follows software standards
In order to perform the above technical and non-technical responsibilities, a software tester
should be equipped with the following skills:

 Understanding the business scenario

 Background of programming
 Knowledge of testing tools and their environment
 Skills of writing test cases and test cases execution
 Skills as a planner for preparing the test plan
 Good analysis skills
 Skills to work with other team members
 Problem-solving skills
 Good Communication skills

Software testers perform testing using software testing tools. There are various automated tools
for testing, such as LoadRunner, JMeter, DBMonster, TestTubes, WinRunner, Pounder,
Marathon, and so on. These tools take test cases and program as input and check the behaviour
of software under test.

Q3. Explain about Test Planning

Testing is long activity in which several test cases are executed by different members of the test
team and may be in different environment and at different locations and machines. Test planning
specifies the scope, approach, resources and schedule of the testing activities. During test
planning, the test team decides the features to be tested, takes to be performed , the personal
responsible for testing, and the associated risks in the plan. Thus testing process follows the test
plan. Test planning includes the following activities:

 Create test plan

 Design test cases
 Design test stubs and test drivers
 Test case execution
 Defect tracking and statistics
 Prepare test summary report.

A good test plan detects defects before testing begins and optimizes scarce resources.

Create a Test plan:

A test plan is a document that describes the scope and activities of testing. It is a formal
document for testing software. It identifies test items, the features to be tested, responsibilities,
schedules, and any risks requiring contingency planning. A test plan contains the following
attributes
Test plan ID: A unique identifier for the test plan document is assigned for an easy reference
and access

Purpose: It describes an overview of the test plan including the goals, objectives, and constraints
for testing the document.

Test items: It includes the list of test items and their versions.

References: It describes the related documents which are to be referenced, if required, such as
project plan, configuration management plan, etc.

Features to be tested: A list of features of the software /product to be tested is specified in the
plan. The features which will not be tested should be specified along with the reasons.

Schedule: A detailed schedule for designing and executing test cases for test items must be
specified against calendar time.

Responsibilities: The responsibilities and roles of each member of the test team should be
specified to determine who will design and execute test cases and repair defects.

Test Environment: Test plan describes the required testing tools and the test environment
describing the hardware, software, and network configurations.

Test case libraries and standards: sometimes a process document is needed for identifying,
writing, and managing test cases.

Test strategy: The test strategy specifies the testing methods, such as white box, black box.
Individual modules may need different testing methods.

Test deliverables: Test deliverables are specified in the test plan before testing the module.
They include the test cases, test scripts, defect logs, test reports, etc.

Release criteria: A pass or fail criteria for the test item on test cases must be designed to judge
competition of testing an item.

Expected risk: A list of risks, both which have occurred or are expected to occur, should be
specified along with the contingency plan for each risk.

The test plan should be concise, clear, and point wise. The test descriptions must be specific.

Design Test Cases: Test case design is the key to success of testing. A test case is a set of inputs
and expected results under which a program unit is exercised with the purpose of causing failure
and detecting faults. The intension of designing sets of test cases for testing is to prove that
program under test is incorrect. Test case selection is the main objective to detect errors in the
program unit. Some of the terminologies that are generally used in automated testing and the
design of test cases.
Test Script: A test script is a procedure that is performed on a system under test to verify that
the system functions as expected. Test case is the baseline to create test scripts using automated
tool.

Test suite: A test suite is a collection of test cases. It is the composite of test cases designed for a
system.

Test data: Test data are needed when writing and executing test cases for any kind of test. All
the test values and test components are separately stored in a file in the form of test data. Test
data sometimes also known as mixture.

Test harness: Test harness is the collection of software, tools, input/output data, and
configurations required for test.

Test scenario: Test scenario is the of test cases in which requirements are tested from end to
end. There can be independent test cases or a series of test cases that follows each other. A test
case includes the following fields

 Test plan ID
 Test case ID
 Features to be tested
 Pre conditions
 Test script or test procedure
 Test data
 Expected results
 Test status

Example: Design a test case to issue a book to the member belonging to student category in the
library. The membership provided for an academic session that can be renewed till the student’s
membership exists in the CS department. A student is not issued more than 5 books at a time.

Test stubs and test Drivers: These dummy pieces of code are the stubs. On the other hand,
Drivers are the ones, which are the "calling" programs. Drivers are used in bottom up testing
approach. Drivers are dummy code, which is used when the sub modules are ready but the main
module is still not ready.
  The concept of Stubs and Drivers are mostly used in the case of component testing.
Component testing may be done in isolation with the rest of the system depending upon
the context of the development cycle.
 Stubs and drivers are used to replace the missing software and simulate the interface
between the software components in a simple manner.
 Suppose you have a function (Function A) that calculates the total marks obtained by a
student in a particular academic year. Suppose this function derives its values from
another function (Function b) which calculates the marks obtained in a particular subject.
 You have finished working on Function A and want to test it. But the problem you face
here is that you can't seem to run the Function A without input from Function B;
Function B is still under development. In this case, you create a dummy function to act in
place of Function B to test your function. This dummy function gets called by another
function. Such a dummy is called a Stub.
 To understand what a driver is, suppose you have finished Function B and is waiting for
Function A to be developed. In this case you create a dummy to call the Function B. This
dummy is called the driver.
Test case Execution: Once the test cases, test drivers, and test stubs are designed for a test plan,
the next task is to execute the test case. Test execution is the process of executing the code and
comparing the expected and actual results. Following factors are to be considered for a test
execution process:

 Based on a risk, select a subset of test suite to be executed for this cycle.
 Assign the test cases in each test suite to testers for execution.
 Execute tests, report bugs, and capture test status continuously.
 Resolve blocking issues as they arise.
 Report status, adjust assignments, and reconsider plans and priorities daily.
 Report test cycle findings and status.

Q4. Explain about Black Box Testing

BLACK-BOX TESTING: Black-box testing is performed on the basis of functions or features

of the software. In the Black-box testing, only the input values are considered for the design of
test cases. The internal logic or program structures are not considered during black-box testing.
Requirement specification is the basis of black-box testing. The behaviour of the module is
observed on executing black-box test cases and matched with the features supported by the
module. Therefore, it is also known as behavioural or functional testing. There are number of
black-box test case design methods

 Equivalence class partitioning

 Boundary Value Analysis
 Cause-effect graphing
  Error guessing
Equivalence class partitioning: Equivalence class partitioning method allows partitioning the
input domain into a set of equivalence class (i.e., sub-domains). The module under test behaves
similarly for all input values of an equivalent class. Each equivalence class provides different
behaviour. The input values of an equivalence class will not belong to another equivalence class.
The equivalence partitioning methods are
 Design of equivalence class: The design of equivalence class is made by splitting into
several equivalence classes and these expected to have different behaviour. For example
twelve months in a year can have two equivalence classes viz., leap year and non-leap
year classes.
 Selection of test input data: the Selection of test input data has two ranges for each class
viz., valid input and invalid input data. The valid input data belong to the range of
equivalence class. The invalid input deals with the exceptions whose values may belong
to the outside range of equivalence class.
Boundary Value Analysis: The Boundary Value Analysis is the special case of Equivalence
class partitioning method that focuses on the boundary of the equivalence class. Boundary Value
Analysis is based on the idea of Equivalence class partitioning. The input domain is partitioned
into as many equivalence classes as possible. The boundary values are identified by relating the
elements of the input domain. Test data are selected in such a way that the boundary values will
appear in at least one of the test input data.
Cause-Effect Graphing: the main drawback of equivalence class portioning and boundary
value analysis methods is the consideration of only single input domain. Cause-effect graphing
techniques begin with finding the relationships among input conditions known as effects. A
cause any condition in the requirements that affects the program output.
For Example,” cash withdrawal” depends upon “valid pin”, ”valid amount” and ”cash
withdrawal” and” cash availability “in the account. Using the cause-effect graphing technique,
the requirements can be stated in the cause and effects as follows:
Cause:
C1: Enter valid amount
C2: Enter valid pin
C3: Cash available in the account
Effects:
E1: Cash withdrawal
Error Guessing: The error guessing technique is based on guessing the error –prone areas in the
program. Error guessing is an intuitive and ad-hoc process of testing. In error guessing, a list of
error prone areas is made by reading the requirements specifications and from the design
specifications.

Q5. Explain about white Box testing? [8M] and Explain the differences between Black box
and white box testing [ 8M]
WHITE-BOX TESTING: White-box testing is also known as glass-box testing or structural
testing. Internal logics, such as control structures, control flow, and data structures are
considered during white box testing. White-box testing is performed to cover various program
structures. The White-box testing methods are
 Control flow based testing
 Path testing
 Data flow based testing
 Mutation testing
White Box 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 is covered.
 Mutation testing: Mutation is the act of slightly changing a program. The
changed program known as mutated program and it is called a mutant of the
original program. In mutation testing, mutants are created by using the mutation
operator whose availability depends on a particular programming language.
Advantages of White Box Testing:
 Forces test developer to reason carefully about implementation.
 Reveals errors in "hidden" code.
 Spots the Dead Code or other issues with respect to best programming practices.
Disadvantages of White Box Testing:
 Expensive as one has to spend both time and money to perform white box testing.
 Every possibility that few lines of code are missed accidentally.
 In-depth knowledge about the programming language is necessary to perform white
box testing.
Path Testing Techniques:
 Control Flow Graph (CFG) - The Program is converted into Flow graphs by representing
the code into nodes, regions and edges.
 Decision to Decision path (D-D) - The CFG can be broken into various Decision to
Decision paths and then collapsed into individual nodes.
  Independent (basis) paths - Independent path is a path through a DD-path graph which
cannot be reproduced from other paths by other methods.
Control flow graph (CFG): A control flow graph (CFG) in computer science is a representation,
using graph notation, of all paths that might be traversed through a program during its execution.

Q6. What is testing? Explain the different levels of testing.

Levels of Testing:
Testing is a defect detection technique that is performed at various levels. Testing begins once a
module is fully constructed.
Unit Testing:
Unit testing is the starting level of testing. Here, unit means a program unit, module, component,
procedure, subroutine of a system developed by the programmer. This type of testing is
performed by developers before the setup is handed over to the testing team to formally execute
the test cases. Unit testing is performed by the respective developers on the individual units of
source code assigned areas. The developers use test data that is different from the test data of the
quality assurance team. The goal of unit testing is to isolate each part of the program and show
that individual parts are correct in terms of requirements and functionality.

Integration Testing:
Integration testing is defined as the testing of combined parts of an application to determine if
they function correctly. Integration testing can be done in two ways: Bottom-up integration
testing and Top-down integration testing. In a comprehensive software development
environment, bottom-up testing is usually done first, followed by top-down testing. The process
concludes with multiple tests of the complete application, preferably in scenarios designed to
mimic actual situations.

System Testing:
System testing tests the system as a whole. Once all the components are integrated, the
application as a whole is tested rigorously to see that it meets the specified Quality Standards.
This type of testing is performed by a specialized testing team.

System testing is important because of the following reasons:

 System testing is the first step in the Software Development Life Cycle, where the
application is tested as a whole.
  The application is tested thoroughly to verify that it meets the functional and technical
specifications.
 The application is tested in an environment that is very close to the production
environment where the application will be deployed.
 System testing enables us to test, verify, and validate both the business requirements as
well as the application architecture.
Q7. Define Regression Testing?
Regression Testing
Whenever a change in a software application is made, it is quite possible that other areas within
the application have been affected by this change. Regression testing is performed to verify that
a fixed bug hasn't resulted in another functionality or business rule violation. The intent of
regression testing is to ensure that a change, such as a bug fix should not result in another fault
being uncovered in the application.

Regression testing is important because of the following reasons:

 Minimize the gaps in testing when an application with changes made has to be tested.
 Testing the new changes to verify that the changes made did not affect any other area of
the application.
 Mitigates risks when regression testing is performed on the application.
 Test coverage is increased without compromising timelines.
 Increase speed to market the product.
Acceptance Testing:
This is arguably the most important type of testing, as it is conducted by the Quality Assurance
Team who will gauge whether the application meets the intended specifications and satisfies the
client’s requirement. The QA team will have a set of pre-written scenarios and test cases that
will be used to test the application.

More ideas will be shared about the application and more tests can be performed on it to gauge
its accuracy and the reasons why the project was initiated. Acceptance tests are not only
intended to point out simple spelling mistakes, cosmetic errors, or interface gaps, but also to
point out any bugs in the application that will result in system crashes or major errors in the
application.

By performing acceptance tests on an application, the testing team will deduce how the
application will perform in production. There are also legal and contractual requirements for
acceptance of the system.
Alpha Testing:
This test is the first stage of testing and will be performed amongst the teams (developer and QA
teams). Unit testing, integration testing and system testing when combined together is known as
alpha testing. During this phase, the following aspects will be tested in the application:

 Spelling Mistakes
 Broken Links
 Cloudy Directions
 The Application will be tested on machines with the lowest specification to test loading
times and any latency problems.
Beta Testing:
This test is performed after alpha testing has been successfully performed. In beta testing, a
sample of the intended audience tests the application. Beta testing is also known as pre-release
testing. Beta test versions of software are ideally distributed to a wide audience on the Web,
partly to give the program a "real-world" test and partly to provide a preview of the next release.
In this phase, the audience will be testing the following:

 Users will install, run the application and send their feedback to the project team.
 Typographical errors, confusing application flow, and even crashes.
 Getting the feedback, the project team can fix the problems before releasing the software
to the actual users.
 The more issues you fix that solve real user problems, the higher the quality of your
application will be.
 Having a higher-quality application when you release it to the general public will
increase customer satisfaction.
Non-Functional Testing:
This section is based upon testing an application from its non-functional attributes. Non-
functional testing involves testing software from the requirements which are non functional in
nature but important such as performance, security, user interface, etc.

Some of the important and commonly used non-functional testing types are discussed below.
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 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 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.

Q8. Define Usability Testing

Usability Testing: Usability testing refers to evaluating a product or service by testing it with
representative users. Typically, during 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.

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 impact to the schedule. Usability Testing is a type of testing done from
an end-user’s perspective to determine if the system is easily usable.

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
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.

Q9. Explain About Debugging Approaches.

Debugging Approaches:
Some of the approaches are described below.
Brute Force Method: This method is most common and least efficient for isolating the cause of
a software error. We apply this method when all else fail. In this method, a printout of all
registers and relevant memory locations is obtained and studied. All dumps should be well
documented and retained for possible use on subsequent problems.

Back Tracking Method: It is a quite popular approach of debugging which is used effectively
in case of small applications. The process starts from the site where a particular symptom gets
detected, from there on backward tracing is done across the entire source code till we are able to
lay our hands on the site being the cause. Unfortunately, as the number of source lines increases,
the number of potential backward paths may become unmanageably large.

Cause Elimination: The third approach to debugging, because elimination is manifested by

induction or deduction and introduces the concept of binary partitioning. This approach is also
called induction and deduction. Data related to the error occurrence are organized to isolate
potential causes. A "cause hypothesis" is devised and the data are used to prove or disprove the
hypothesis. Alternatively, a list of all possible causes is developed and tests are conducted to
eliminate each. If initial tests indicate that a particular cause hypothesis shows promise, the data
are refined in an attempt to isolate the bug.

Tools for Debugging: Each of the above debugging approaches can be supplemented with
debugging tools. For debugging we can apply wide variety of debugging tools such as debugging
compilers, dynamic debugging aids, automatic test case generators, memory dumps and cross
reference maps. The following are the main Debugging tools available in the market.

Q [Link] and Validation

  Verification refers to the set of activities refers that function software correctly
implements a specific function
 Validation refers to different set of activities that ensure the software that has been built
is traceable to customer requirements
 Verification and validation encompasses a wide array of SQA activities that include
formal technicalreviews, quality and configuration audits, performance monitoring,
simulation, feasibility study, usability testing, qualification testing and installation testing

Verification: Are we building the product right?

Validation: Are we building the right product?

Criteria Verification Validation

The process of evaluating work-products
The process of evaluating software during
(not the actual final product) of a
or at the end of the development process
Definition development phase to determine whether to determine whether it satisfies specified
they meet the specified requirements for
business requirements.
that phase.
To ensure that the product actually meets
To ensure that the product is being built
the user’s needs, and that the
according to the requirements and design
specifications were correct in the first
Objective specifications. In other words, to ensure place. In other words, to demonstrate that
that work products meet their specified
the product fulfills its intended use when
requirements.
placed in its intended environment.
Question Are we building the product right? Are we building the right product?
Evaluatio Plans, Requirement Specs, Design Specs, The actual product/software.
n Items Code, Test Cases
 Reviews
 Walkthroughs  Testing
Activities
 Inspections

Q.11 A software Testing Strategy

The software engineering process may be viewed as the spiral. Initially, system
engineering defines the role of software and leads to software requirements analysis. Where the
information domain, function, behavior, performance, constraintsand validation criteria for
software are established. Moving inward along the spiral we come to design and finally to
coding.
Unit testingbegins at the vortex of the spiral and concentrates on each unit (i.e., component) of
the software as implemented in source [Link] progresses by moving outward along the
spiral to integration testing, where the focus is on design and the construction of the software
architecture. Taking another turn outward on the spiral, we encounter validation testing, where
requirements established as part of software requirements analysis are validated against the
software that has been constructed. Finally, we arrive at system testing, where the software and
other system elements are tested as a whole.

Testing within the context of software engineering is actually a series of four steps that are
implemented sequentially

Requirements
High order tests

Design Integration test

Unit test
Code

Testing

Direction

 Unit Testing – makes heavy use of testing techniques that exercise specific control paths to
detect errors in each software component individually
 Integration Testing – focuses on issues associated with verification and program
construction as components begin interacting with one another
 Validation Testing – provides assurance that the software validation criteria (established
during requirements analysis) meets all functional, behavioral, and performance requirements
 System Testing – verifies that all system elements mesh properly and that overall system
function and performance has been achieved.

Q12. TEST STRATEGIES FOR CONVENTIONAL SOFTWARE

There are many strategies that can be used to test software. At one extreme a software
team could wait until the system is fully constructed and then conduct test on the overall system
in hopes of finding errors—this approach doesn’t work it will result in buggy software that
disappoints the customer and end user

At other extreme a software engineer could conduct on daily basis whenever any part of
the system is constructed---this approach can be very effective but most software developers
hesitate to use it.

4.2.1 Unit Testing

Unit testing focuses verificationeffort on the smallest unit of software design-- the
software component or module. Using the component-level design description as a guide,
important control paths are tested to uncover errors within the boundary of the module. The unit
test focuses on the internal processing logic and data structureswithin the boundaries of a
component. This type of testing can be conducted in parallel for multiple components.

[Link] Unit Test Considerations

Unit Test focuses on:

 The module interface is tested to ensure that information properly flows into and out of the
program unit under test
 The local data structure is examined to ensure that data stored temporarily maintains its
integrity during all steps in an algorithm's execution
 Boundary conditions are tested to ensure that the module operates properly at boundaries
established to limit or restrict processing.
 All independent paths (basis paths) through the control structure are exercised to ensure that
all statements in a module have been executed at least once.
 All error handling paths are tested.

Interface
In unit test, while testing interfaces, we consider:

 Number of input parameters equal to number of arguments?

 Parameter and argument attributes match?
 Parameter and argument units system match?
 Parameters passed in correct order?
 Input only parameters changed?
 Global variable definitions consistent across modules
 File attributes correct?
 Open / Close statements correct?
 Format specifications match I/O statements?
 Buffer size match record size?
 Files opened before use?
 End of file condition handled?
 I/O errors handled?
 Any textual errors in output information?

Local Data Structure

In unit test, we verify usage of local data structure in following aspects:

 Improper or inconsistent typing

 Erroneous initialization or default values
 Incorrect variable names
 Inconsistent data types
 Overflow, underflow, address exceptions

Boundary Conditions

In unit test, we verify boundary conditions in following aspects:

 Lower bound and upper bound values of defined range of values of variables
 Values of variables beyond acceptable limits

Independent Paths

Unit test shall verify independent paths in following aspects:

 Execution of possible branch statements

  Single entry and single exit of loops
 Handling of Go-Tos
 Balance of beginning and ending of embedded statements and loops
 Initialization and termination conditions of loops

Error Handling

Unit test shall consider error handling related aspects:

 Error description unintelligible

 Error noted does not correspond to error encountered
 Error condition handled by system run-time before error handler gets control
 Exception condition processing incorrect

Module
Interface
~~~~~~~~~ Local data structures
~~~~~~~ Boundary conditions
~~~~~~~~~ Independents paths
~~~~~~~~~ Error handling
~~~~~~

Test cases

Unit Test Procedures

Unit testing is normally considered as an adjunct to the coding step. After source level
code has been developed, reviewed, and verified for correspondence to component-level design,
unit test case design begins. Each test case should be coupled with a set of expected results.

Because a component is nota stand-alone program, driver and/or stub software must be
developed for each unit test. The unit test environment is illustrated in figure below. In most
applications a driver is nothing more than a 'main program' that accepts test case data, passes
such data to the component. (to be tested), and prints relevant results. Stubs serve to replace
modules that are subordinate (called by) the component to be tested. A stub or ‘dummy
subprogram’ uses the subordinate modules interface, may do minimal data manipulation, prints
verification of entry and returns control to the module undergoing testing.

Driver Interface
Local data structures
Boundary conditions
Independents paths
Error handling
Module to
be tested

Stub Stub
Test cases

Ex: Suppose you have a function (Function A) that calculates the total marks obtained by a
student in a particular academic year. Suppose this function derives its values from another
function (Function b) which calculates the marks obtained in a particular subject

You have finished working on Function A and want to test it. But the problem you face here is
that you can't seem to run the Function A without input from Function B; Function B is still
under development. In this case, you create a dummy function to act in place of Function B to
test your function. This dummy function gets called by another function. Such a dummy is called
a Stub.

To understand what a driver is, suppose you have finished Function B and is waiting for
Function A to be developed. In this case you create a dummy to call the Function B. This dummy
is called the driver.

FUNCTION A FUNCTION A
DRIVER
(Total marks (Total marks
(DUMMY) obtained by a
obtained by a
student) student)
 FUNCTION B
FUNCTION B
STUB (marks in
(marks in
(DUMMY) particular subject)
particular subject)

Drivers and stubs represent overhead that is, both are software that must be developed to test the
module but it will not be delivered to the customer. If the drivers and stubs are kept simple than
overhead will be relatively low. Unfortunately, many components cannot be adequately tested
with ‘simple’ overhead software. In such cases, complete testing can be postponed until the
integration test step (where driver or stubs are also used).

Unit testing is simplified when a component with high cohesion is designed. When only one
function is addressed by the component, the number or test cases is reduced and errors can be
more easily predicted and uncovered.

Integration testing

Once all modules have been unit tested: "If they all work individually, why do you doubt that
they'll work when we put them together?" The problem, or course, is putting them together --
interfacing. Data can be lost across an interface; one module can have an inadvertent, adverse
affect on another; sub-functions, when combined, may not produce the desired major function;
individually acceptable imprecision may be magnified to unacceptable levels; global data
structures can present problems. Sadly, the list goes on and on.

Integration Testing is a level of software testing where individual units are combined and tested
as a group

Integration testing is a systematic technique for constructing the program structure while at the
same time conducting tests to uncover errors associated with interfacing. The objective is to take
unit tested components and build a program structure that has been dictated by design.
 Approaches:

 Big Bang is an approach to Integration Testing where all or most of the units are
combined together and tested at one go. This approach is taken when the testing team
receives the entire software in a bundle. So what is the difference between Big Bang
Integration Testing and System Testing? Well, the former tests only the interactions
between the units while the latter tests the entire system.
 Top Down is an approach to Integration Testing where top level units are tested first and
lower level units are tested step by step after that. This approach is taken when top down
development approach is followed. Test Stubs are needed to simulate lower level units
which may not be available during the initial phases.
 Bottom Up is an approach to Integration Testing where bottom level units are tested first
and upper level units step by step after that. This approach is taken when bottom up
development approach is followed. Test Drivers are needed to simulate higher level units
which may not be available during the initial phases.
 Sandwich/Hybrid is an approach to Integration Testing which is a combination of Top
Down and Bottom Up approaches.

Top down Integration

Top down integration testingis an incremental approach to construction or program

structure. Modules are integrated by moving downward through the control hierarchy beginning
with the main control module (main program). Modules subordinate (and ultimately subordinate)
to the main control module are incorporated into the structure in either a depth-first or breadth-
first manner.

In depth first integration:For example, selecting the left hand path, components M1 M2
and M5 would be integrated first. Next, M8 or (ifnecessary proper functioning of M2) M6 would
be integrated. Then, the central and right hand control paths are built.

Breadth first integration: Incorporates all components directly sub-ordinate at each level, moving
across the structure horizontally., components M2, M3 and M4 ( a replacement of stub s4) would
be integrated first. The next control level M5, M6 and so on, follows.

Depth First Breadth First

Integration
Integration
 M1 M1

M2 M3 M4 M2 M3 M4

M6 M7 M5 M6 M7
M5

M8 M8
The integration process is performed in a series of five steps:

1. The main control module is used as a test driver and stubs are substituted for all
components directly sub-ordinate to the main control module.
2. Depending on the integration approach selected ( i.e., depth or breadth first), sub-ordinate
stubs are replaced one at a time with actual components.
3. Tests are conducted as each component is integrated.
4. On completion of each set of tests, another stub is replaced with the real components.
5. Regression testing may be conducted to ensure that new errors have not been introduced.
The process continues from step 2 until the entire program structure is built.

The top-down integration strategy verifies major control or decision points early in the test
process. In a well-factored program structure, decision making occurs at upper levels in the
hierarchy and is therefore encountered first. If major control problems do exist, early recognition
is essential. If depth-first integration is selected, a complete function of the software may be
implemented and demonstrated.

Top-down strategy sounds relatively uncomplicated, but in practice, logistical problems can
arise. The most common of these problems occurs when processing at low levels in the hierarchy
is required to adequately test upper levels. Stubs replace low-level modules at the beginning of
top-down testing; therefore, no significant data can now upward in the program structure. The
tester is left will three choices;

 Delay many tests until stubs are replaced with actual modules.
 Develop stubs that perform limited functions that simulate the actual module, or
 Integrate the software from the bottom of the hierarchy upward.
The first approach (delay tests until stubs are replaced by actual modules) causes us to loose
some control over correspondence between specific tests and incorporation of specific modules.
This can lead to difficulty in determining the cause of errors and tends to violate the highly
constrained nature of the top-down approach. The second approach is workable but can lead to
significant overhead, as stubs become more and more complex. The third approach is called
bottom-up testing.

Bottom-up Integration

Bottom-up integration testing, as its name implies, begins construction and testing with
atomic modules (i.e., components at the lowest levels in the program structure). Because
components are integrated from the bottom up, processing required for components subordinate
to a given level is always available and the need for stubs is eliminated.

A bottom-up integration strategy may be implemented with the following steps:

 Low-level components are combined into clusters (sometimes called builds) that perform
a specific software sub-function.
 A driver (a control program for testing) is written to coordinate test case input and output.
 The cluster is tested.
 Drivers are removed and clusters are combined moving upward in the program structure.
Integration follows the pattern illustrated in Figure below. Components are combined to form
clusters 1,2, and 3.

Each of the clusters is tested using a driver (shown as a dashed block). Components in
clusters 1 and 2 are subordinate to Ma. Drivers D1 and D2 are removed and the clusters are
interfaced directly to Ma. Similarly, driver D3 for cluster 3 is removed prior to integration with
module Mb. Both Ma and Mb will ultimately be integrated with component Mc.

As integration moves upward the need for separate test drivers lessens. In fact, if the top
two levels of program structure are integrated top down, the number of drivers can be reduced
substantially and integration of clusters is greatly simplified.
Example of Integration Testing:

A Media player where all the modules like audio, video and various formats are combined and
tested if the software is working properly or not.

Q13. TEST STRATEGIES FOR OBJECT ORIENTED SOFTWARE

 With object-oriented software, you can no longer test a single operation in isolation
(conventional thinking)
 Traditional top-down or bottom-up integration testing has little meaning
 Class testing for object-oriented software is the equivalent of unit testing for conventional
software
 Focuses on operations encapsulated by the class and the state behavior of the
class
 Drivers can be used
 To test operations at the lowest level and for testing whole groups of classes
 To replace the user interface so that tests of system functionality can be
conducted prior to implementation of the actual interface
 Stubs can be used
 In situations in which collaboration between classes is required but one or more
of
the collaborating classes has not yet been fully implemented
 Two different object-oriented testing strategies
 Thread-based testing
• Integrates the set of classes required to respond to one input or event for
the system
• Each thread is integrated and tested individually
• Regression testing is applied to ensure that no side effects occur
 Use-based testing
• First tests the independent classes that use very few, if any, server classes
• Then the next layer of classes, called dependent classes, are integrated
• This sequence of testing layer of dependent classes continues until the
entire system is constructed

VALIDATION TESTING

Validation testing follows integration testing

 The distinction between conventional and object-oriented software disappears
 Focuses on user-visible actions and user-recognizable output from the system
 Demonstrates conformity with requirements
  Designed to ensure that
 All functional requirements are satisfied
 All behavioral characteristics are achieved
 All performance requirements are attained
 Documentation is correct
 Usability and other requirements are met (e.g., transportability, compatibility,
error recovery, maintainability)
 After each validation test
 The function or performance characteristic conforms to specification and is
accepted
 A deviation from specification is uncovered and a deficiency list is created
 A configuration review or audit ensures that all elements of the software configuration
have been properly developed, cataloged, and have the necessary detail for entering the
support phase of the software life cycle

Alpha And Beta Testing

Alpha and beta testing are important testing phases for success of any software release.
Alpha Testing

This is a form of internal acceptance testing performed mainly by in-house software QA and
testing teams. Alpha testing is the last testing done by test teams at development site after the
acceptance testing and before releasing the software for beta test. Alpha testing can also be done
by potential users or customers of the application. But still this is a form of in-house acceptance
testing.

Beta Testing

This is a testing stage followed by internal full alpha test cycle. This is the final testing phase
where companies release the software for few external user groups outside the company test
teams or employees. This initial software version is called as beta version. Most companies
gather user feedback in this release.

The simple definition of beta testing – testing carried out by real users in real environment.

Q14. SYSTEM TESTING

In the world of software testing, system testing is the testing of a complete and fully
integrated software product.
 Usually software is only one element of a larger computer based system. Ultimately,
software is interfaced with other software/hardware systems. System testing is actually a series
of different tests whose sole purpose is to exercise the full computer based system.

System testing problem is “finger pointing” rather than indulging in such nonsense the software
engineer should anticipate potential interfacing problems and

 Design error handling paths that test all information coming from other elements of the
system
 Conduct series of tests that simulates bad data
 Record the results of tests to use as “evidence” if finger pointing does occur
 Participate in planning and design of system tests to ensure that software is adequately
tested

System testing falls under the black box testing category of software testing. White box
testing is the testing of the internal workings or code of a software application. In contrast, black
box or system testing is the opposite. System testing involves the external workings of the
software from the user's perspective.

Following types of testing should be considered during system testing cycle. The test types
followed in system testing differ from organization to organization however this list covers some
of the main testing types which need to be covered in system testing.

Recovery testing:Recovery testing is done to demonstrate a software solution is reliable,

trustworthy and can successfully recoup from possible crashes.

Examples of recovery testing:

1. While an application is running, suddenly restart the computer, and afterwards check the
validness of the application's data integrity.
2. While an application is receiving data from a network, unplug the connecting cable. After
some time, plug the cable back in and analyze the application's ability to continue receiving data
from the point at which the network connection disappeared.
3. Restart the system while a browser has a definite number of sessions. Afterwards, check that
the browser is able to recover all of them

Security testing:Security Testing tests the ability of the system/software to prevent

unauthorized access to the resources and data.

Security Testing needs to cover the six basic security concepts: confidentiality, integrity,
authentication, authorization, availability and non-repudiation.
Authentication
Authentication is a process of identifying the person before accessing the system.
It allows user to access the system information only if authentication check got passed.
Apart from Username & password combination, the authentication can be implemented
in different ways like asking secret question and answer, OTP (One Time Password) over
SMS, biometric authentication, Token based authentication like RSA Secure ID token
etc. It is also possible to use combinations of above options for authentication.
Authorization
Once the Authentication passed the Authorization comes in the picture to limit the
user as per the permission set for the user. The Authorization is generally implemented
on Access control list, user role based, user group based and define the permissions &
restrictions to specific user group or granting or revoking the privileges for the users.
Confidentiality
Confidentiality is to be carried out to check if unauthorized user and less
privileged users are not able to access the information.
Availability
 Assuring information and communications services will be ready for use when expected.
 Information must be kept available to authorized persons when they need it.
Integrity
Integrity is to make sure that the information received is not altered during the transit &
check if correct information presented to user is as per the user groups, privileges & restrictions.
Non-repudiation
Tracking who is accessing the systems and which of the requests were denied along with
additional details like the Timestamp and the IP address from where the requests came from.
Means confirmation sent by receiver to sender that the requested services or information was
successfully received as Digital confirmation e.g. Digital Certificates, this not only serves as
acknowledgement but also helps to validate both sender and receiver is genuine.
This is an example of a very basic security test which anyone can perform on a web
site/application:

 Log into the web application.

 Log out of the web application.
 Click the BACK button of the browser (Check if you are asked to log in again or if you
are provided the logged-in application.)

Security testing examples

  Password should be in encrypted format

 Application or System should not allow invalid users

 Check cookies and session time for application

 For financial sites, Browser back button should not work.

Q14. Stress testing

Stress testing is Negative testing where we load the software with large number of
concurrent users/processes which cannot be handled by the systems hardware resources. This
testing is also known as Fatigue testing, this testing should capture the stability of the
application by testing it beyond its bandwidth capacity

The goals of such tests may be to ensure the software does not crash in conditions of
insufficient computational resources (such as memory or disk space).

Stress Testing is performance testing type to check the stability of software when
hardware resources are not sufficient like CPU, memory, disk space etc.
Example:
As an example, a word processor like Writer1.1.0 by [Link] is utilized in development
of letters, presentations, spread sheets etc… Purpose of our stress testing is to load it with the
excess of characters.

To do this, we will repeatedly paste a line of data, till it reaches its threshold limit of handling
large volume of text. As soon as the character size reaches 65,535 characters, it would simply
refuse to accept more data. The result of stress testing on Writer 1.1.0 produces the result that, it
does not crash under the stress and that it handle the situation gracefully, which make sure that
application is working correctly even under rigorous stress conditions.

Performance testing

Performance testing is the process of determining the speed or effectiveness of a

computer, network, software program or device. This process can involve quantitative tests done
in a lab, such as measuring the response time or the number of MIPS (millions of instructions per
second) at which a system functions. Qualitative attributes such
as reliability, scalability and interoperability may also be evaluated. Performance testing is often
done in conjunction with stress testing.
 Load testing and performance testing are commonly said as positive testing where as stress
testing is said to be negative testing

Say for example if there is an application which can handle 25 simultaneous user logins at a
time. In load testing we will test the application for 25 users and check how the application is
working in this stage, in performance testing we will concentrate on the time taken to perform
the operation. Where as in stress testing we will test more than 25 users and the test will
continue to any number and we will check where the application is cracking the hardware
resources

Q15. SOFTWARE TESTING FUNDAMENTALS

Characteristics of Testable Software

 Operable
The better it works (i.e., better quality), the easier it is to test
 Observable
Incorrect output is easily identified; internal errors are automatically detected
 Controllable
The states and variables of the software can be controlled directly by the tester
 Decomposable
The software is built from independent modules that can be tested independently
 Simple
The program should exhibit functional, structural, and code simplicity
 Stable
Changes to the software during testing are infrequent and do not invalidate existing tests
 Understandable
The architectural design is well understood; documentation is available and organized
Test characteristics

 A good test has a high probability of finding an error

The tester must understand the software and how it might fail
 A good test is not redundant
Testing time is limited; one test should not serve the same purpose as another test
 A good test should be “best of breed”
Tests that have the highest likelihood of uncovering a whole class of errors should be used
 A good test should be neither too simple nor too complex
Each test should be executed separately; combining a series of tests could cause side
effects and mask certain errors
Testing techniques

Tests can be conducted based on two approaches –

 Functionality testing
 Implementation testing
When functionality is being tested without taking the actual implementation in concern it is
known as black-box testing. The other side is known as white-box testing where not only
functionality is tested but the way it is implemented is also analyzed.