STQA NOTES SYMCA

UNIT-2
Testing in the Software Lifecycle and Test
Level
What is V and V model?
 This model is an extension of the waterfall model.
 V – V model is also known as Verification and Validation model.
 This model is based on the association of the testing phase for each corresponding
development stage.
 It determines the complex relationship between each phase of the software development is
associated with testing.
How V – V model works?
 Every single phase in the software development life cycle, there is directly associated testing
phase.
 This is a complete ordered model where next phase starts only after completion of the
previous phase.
Objectives of V – V model

1. Reduce the Risks.

2. Ensure software product quality.
3. Reduce cost of system development process.
4. Assessment of whether or not the system is useful and usable.

 In the above V – V model diagram, it defines the different phases in V – V model of SDLC.
 At this model, the testing phases of the development phase is panned in parallel. There are
verification phases on one side and Validation phases on the other side of the V – V model.

Page 6 of 88
 STQA NOTES SYMCA

 The left side (Verification) analyzes and determines the requirements of the software to be
developed and the right side (Validation) includes the testing activities. Both the left and
right branches work concurrently and also established a relationship.
Advantages of V – V model
 The processes are completed one at a time.
 This model is easy to understand and simple to use.
 This model is also working well for smaller software project, where requirements are
understood very well.
 Each phase has specific deliverables and a review process.
 It covers all functional areas.
 It contains instructions and recommendations, which provide a detailed explanation of the
problems involved.
Disadvantages of V – V model
 In this model, there is a possibility of high risk and uncertainty.
 This model is not useful for long and ongoing projects.
 It is not suitable for the projects where requirements are at a moderate to high risk of
changing.
This model is not good for complex and object oriented projects.

W Model

W Model

From the testing point of view all of the models are deficient in various ways. The test activities first
start after the implementation. The connection between the various test stages and the basis for the
test is not clear. The tight link between test, debug and change tasks during the test phase is not
clear.

Page 7 of 88
STQA NOTES SYMCA

In the models presented above, there usually appears an unattractive task to be carried out after
coding. In order to place testing on an equal footing, a second 'V' dedicated to testing is integrated
into the model. Both 'V's put together give the 'W' of the 'W-Model'.
The W Model removes the vague and ambiguous lines linking the left and right legs of the V and
replaces them with parallel testing activities, shadowing each of the development activities.

As the project moves down the left leg, the testers carry out static testing(i.e. inspections and
walkthroughs) of the deliverables at each stage. Ideally prototyping and early usability testing would
be included to test the system design of interactive systems at a time when it would be easy to solve
problems. The emphasis would then switch to dynamic testing once the project moves into the
integration leg.

There are several interesting aspects to the W Model. Firstly, it drops the arbitrary and unrealistic
assumption that there should be a testing stage in the right leg for each development stage in the
left leg. Each of the development stages has its testing shadow, within the same leg.

The illustration shows a typical example where there are the same number of stages in each leg, but
it's possible to vary the number and the nature of the testing stages as circumstances require
without violating the principles of the model.

Also, it explicitly does not require the test plan for each dynamic test stage to be based on the
specification produced in the twin stage on the left hand side. There is no twin stage of course, but
this does address one of the undesirable by-products of a common but unthinking adoption of the V
Model; a blind insistence that test plans should be generated from these equivalent documents, and
only from those documents.

A crucial advantage of the W Model is that it encourages testers to define tests that can be built into
the project plan, and on which development activity will be dependent, thus making it harder for
test execution to be squeezed at the end of the project.

However, starting formal test execution in parallel with the start of development must not mean
token reviews and sign-offs of the documentation at the end of each stage. Commonly under the V
Model, and the Waterfall, test managers receive specifications with the request to review and sign
off within a few days what the developers hope is a completed document. In such circumstances test
managers who detect flaws can be seen as obstructive rather than constructive. Such last minute
"reviews" do not count as early testing.

Component Testing
 Component testing is a method where testing of each component in an application is done
separately. Suppose, in an application there are 5 components. Testing of each 5
components separately and efficiently is called as component testing.
 Component testing is also known as module and program testing. It finds the defects in the
module and verifies the functioning of software.
 Component testing is done by the tester.
 Component testing may be done in isolation from rest of the system depending on the
development life cycle model chosen for that particular application. In such case the missing
software is replaced by Stubs and Drivers and simulate the interface between the software
components in a simple manner.
 Let’s take an example to understand it in a better way. Suppose there is an application
consisting of three modules say, module A, module B and module C. The developer has

Page 8 of 88
STQA NOTES SYMCA

developed the module B and now wanted to test it. But in order to test the module B
completely few of it’s functionalities are dependent on module A and few on module C. But
the module A and module C has not been developed yet. In that case to test the module B
completely we can replace the module A and module C by stub and drivers as required.
 Stub: A stub is called from the software component to be tested. As shown in the diagram
below ‘Stub’ is called by ‘component A’.
 Driver: A driver calls the component to be tested. As shown in the diagram below
‘component B’ is called by the ‘Driver’.

Below is the diagram of the component testing:

 As discussed in the previous article of the ‘Unit testing’ it is done by the developers where
they do the testing of the individual functionality or procedure. After unit testing is
executed, component testing comes into the picture. Component testing is done by the
testers.
 Component testing plays a very important role in finding the bugs. Before we start with the
integration testing it’s always preferable to do the component testing in order to ensure that
each component of an application is working effectively.
 Integration testing is followed by the component testing.

Integration Testing

Integration testing tests integration or interfaces between components, interactions to

different parts of the system such as an operating system, file system and hardware or
interfaces between systems.

 Also after integrating two different components together we do the integration testing.
As displayed in the image below when two different modules ‘Module A’ and ‘Module
B’ are integrated then the integration testing is done.

Page 9 of 88
STQA NOTES SYMCA

 Integration testing is done by a specific integration tester or test team.

 Integration testing follows two approach known as ‘Top Down’ approach and ‘Bottom
Up’ approach as shown in the image below:

Below are the integration testing techniques:

1. Big Bang integration testing:

In Big Bang integration testing all components or modules are integrated simultaneously,
after which everything is tested as a whole. As per the below image all the modules from
‘Module 1’ to ‘Module 6’ are integrated simultaneously then the testing is carried out.

Advantage: Big Bang testing has the advantage that everything is finished before integration
testing starts.

Page 10 of 88
STQA NOTES SYMCA

Disadvantage: The major disadvantage is that in general it is time consuming and difficult to trace
the cause of failures because of this late integration.
2. Top-down integration testing: Testing takes place from top to bottom, following the control flow
or architectural structure (e.g. starting from the GUI or main menu). Components or systems are
substituted by stubs. Below is the diagram of ‘Top down Approach’:

Advantages of Top-Down approach:

 The tested product is very consistent because the integration testing is basically
performed in an environment that almost similar to that of reality
 Stubs can be written with lesser time because when compared to the drivers then
Stubs are simpler to author.

Disadvantages of Top-Down approach:

 Basic functionality is tested at the end of cycle

3. Bottom-up integration testing: Testing takes place from the bottom of the control flow
upwards. Components or systems are substituted by drivers. Below is the image of ‘Bottom
up approach’:

Page 11 of 88
STQA NOTES SYMCA

Advantage of Bottom-Up approach:

 In this approach development and testing can be done together so that the product or
application will be efficient and as per the customer specifications.

Disadvantages of Bottom-Up approach:

 We can catch the Key interface defects at the end of cycle

 It is required to create the test drivers for modules at all levels except the top control

Incremental testing:

 Another extreme is that all programmers are integrated one by one, and a test is
carried out after each step.
 The incremental approach has the advantage that the defects are found early in a
smaller assembly when it is relatively easy to detect the cause.
 A disadvantage is that it can be time-consuming since stubs and drivers have to be
developed and used in the test.
 Within incremental integration testing a range of possibilities exist, partly depending
on the system architecture.

Functional incremental: Integration and testing takes place on the basis of the functions and
functionalities, as documented in the functional specification.

System Testing

 In system testing the behavior of whole system/product is tested as defined by the scope of
the development project or product.
 It may include tests based on risks and/or requirement specifications, business process, use
cases, or other high level descriptions of system behavior, interactions with the operating
systems, and system resources.
 System testing is most often the final test to verify that the system to be delivered meets the
specification and its purpose.
 System testing is carried out by specialist’s testers or independent testers.
 System testing should investigate both functional and non-functional requirements of the
testing.
Acceptance Testing

 After the system test has corrected all or most defects, the system will be delivered to the
user or customer for Acceptance Testing or User Acceptance Testing (UAT).
 Acceptance testing is basically done by the user or customer although other stakeholders
may be involved as well.
 The goal of acceptance testing is to establish confidence in the system.
 Acceptance testing is most often focused on a validation type testing.
 Acceptance testing may occur at more than just a single level, for example:
 A Commercial Off the shelf (COTS) software product may be acceptance tested when it is
installed or integrated.

Page 12 of 88
STQA NOTES SYMCA

 Acceptance testing of the usability of the component may be done during

component testing.
 Acceptance testing of a new functional enhancement may come
before system testing.
 The types of acceptance testing are:
 The User Acceptance test: focuses mainly on the functionality thereby
validating the fitness-for-use of the system by the business user. The user
acceptance test is performed by the users and application managers.
 The Operational Acceptance test: also known as Production acceptance test
validates whether the system meets the requirements for operation. In most of
the organization the operational acceptance test is performed by the system
administration before the system is released. The operational acceptance test
may include testing of backup/restore, disaster recovery, maintenance tasks and
periodic check of security vulnerabilities.
 Contract Acceptance testing: It is performed against the contract’s acceptance
criteria for producing custom developed software. Acceptance should be
formally defined when the contract is agreed.
 Compliance acceptance testing: It is also known as regulation acceptance
testing is performed against the regulations which must be adhered to, such as
governmental, legal or safety regulations.

What is Functional Testing?

Functional Testing is the type of testing done against the business requirements of application. It is a
black box type of testing.
It involves the complete integration system to evaluate the system’s compliance with its specified
requirements. Based on the functional specification document this type of testing is to be carried
out. In actual testing, testers need to verify a specific action or function of the code. For functional
testing either manual testing or automation tools can be used but functionality testing would be
easier using manual testing only. Prior to non Functional testing the Functional testing would be
executed first.
Five steps need to be keeping in mind in the Functional testing:
 Preparation of test data based on the specifications of functions
 Business requirements are the inputs to functional testing
 Based on functional specifications find out of output of the functions
 The execution of test cases
 Observe the actual and expected outputs
To carry out functional testing we have numerous tools available, here is the list of Functional
testing tools.
In the types of functional testing following testing types should be cover:
 Unit Testing
 Smoke testing
 Sanity testing
 Integration Testing

 Interface Testing
 System Testing
 Regression Testing
 UAT

Page 13 of 88
STQA NOTES SYMCA

Unit Testing

A unit test is the smallest testable part of an application like functions, classes, procedures,
interfaces. Unit testing is a method by which individual units of source code are tested to
determine if they are fit for use.

 Unit tests are basically written and executed by software developers to make sure that
code meets its design and requirements and behaves as expected.
 The goal of unit testing is to segregate each part of the program and test that the individual
parts are working correctly.
 This means that for any function or procedure when a set of inputs are given then it should
return the proper values. It should handle the failures gracefully during the course of
execution when any invalid input is given.
 A unit test provides a written contract that the piece of code must assure. Hence it has
several benefits.
 Unit testing is basically done before integration as shown in the image below.

Method Used for unit testing: White Box Testing method is used for executing the unit test.

 When Unit testing should be done?

 Unit testing should be done before Integration testing.
 By whom unit testing should be done?
 Unit testing should be done by the developers.

Advantages of Unit testing:

1. Issues are found at early stage. Since unit testing are carried out by developers where they test
their individual code before the integration. Hence the issues can be found very early and can be
resolved then and there without impacting the other piece of codes.
2. Unit testing helps in maintaining and changing the code. This is possible by making the codes less
interdependent so that unit testing can be executed. Hence chances of impact of changes to any
other code gets reduced.
3. Since the bugs are found early in unit testing hence it also helps in reducing the cost of bug fixes.
Just imagine the cost of bug found during the later stages of development like during system testing
or during acceptance testing.
4. Unit testing helps in simplifying the debugging process. If suppose a test fails then only latest
changes made in code needs to be debugged.

Page 14 of 88
STQA NOTES SYMCA

Sanity Testing

 Sanity testing is usually performed when any minor bug is fixed or when there is a small
change in the functionality. It is a kind of software testing which is done by the testers to
ensure that the functionality is working as expected.
 Sanity testing is narrow and deep. Unlike Smoke testing, Sanity testing is focused on one or
two functionalities whereas smoke testing is done to ensure that all the major features of
the project is working fine.
 After the changes or fixes are done in the code the software build is available to the testers.
Post installation of the build the testers will do the Sanity testing of the changed
functionality instead of doing the entire regression testing which will take more time.
 If the bug fixes and the changed functionalities are not working as expected then the testers
should not accept the build. This failure is caught early in the stage because of the sanity
testing.

Few points about Sanity testing:

 It is a surface level testing which follows narrow and deep approach concentrating on
the detailed testing of some limited features
 In sanity testing the testers verifies the commands and functions and all the menus in
the product
 It is a subset of regression testing
 It is performed when we do not have enough time for detailed testing
 Sanity testing is usually not scripted
 Sanity testing is brief or quick testing in order to ensure that the changes are working
as expected and as per the specification documents
 Sanity testing checks the minor bug fixes and the functionality changes are working at
the same time it also ensures that the related functionality is intact.

Advantages of Sanity testing:

 It saves lots of time and effort because Sanity testing is focused on one or few areas of
functionality
 There is no effort put in towards it’s documentation because it’s usually unscripted
 It helps in identifying the dependent missing objects.
 It is used to verify that a small functionality of the application is still working fine
after a minor change.

Disadvantages of Sanity testing:

 Sanity testing focuses only on the commands and functions of the software
 It does not go to the design structure level so it’s very difficult for the developers to
understand as how to fix the issues found during the sanity testing
 In sanity testing the testing is performed only for some limited features so if there is
any issue in other functionalities then it will be difficult to catch them
 Sanity testing is usually unscripted so future references are not available

Page 15 of 88
STQA NOTES SYMCA

Difference between Smoke testing and Sanity testing:

Smoke testing Sanity testing
The main objective of Smoke testing is to The main objective of Sanity testing is to verify
verify the stability of the entire system the rationality of the system
Smoke testing is executed to ensure that Sanity testing is executed to verify that the
the basic functionalities are working as new functionality or the bug fixes are working
expected as expected
Smoke testing is wide and shallow
Sanity testing is narrow and deep approach
approach
Smoke testing is usually scripted or
Sanity testing is usually unscripted
documented
Smoke testing is performed by the testers
Sanity testing is usually performed by the
and it can also be performed by the
testers
developers
Smoke testing is like general health Sanity testing is like a specialized health
checkup of the software checkup of the software
Whereas sanity testing is performed after the
Smoke testing is performed earlier
Smoke testing

What is non Functional Testing?

 The non Functional Testing is the type of testing done against the non functional
requirements. Most of the criteria are not consider in functional testing so it is used
to check the readiness of a system. Non-functional requirements tend to be those that
reflect the quality of the product, particularly in the context of the suitability perspective of
its users. It can be started after the completion of Functional Testing. The non functional
tests can be effective by using testing tools.
 The testing of software attributes which are not related to any specific function or user
action like performance, scalability, security or behavior of application under certain
constraints.
 Non functional testing has a great influence on customer and user satisfaction with the
product. Non functional testing should be expressed in a testable way, not like “the system
should be fast” or “the system should be easy to operate” which is not testable.
 Basically in the non functional test is used to major non-functional attributes of software
systems. Let’s take non functional requirements examples; in how much time does the
software will take to complete a task? or how fast the response is.

Following testing should consider in non functional testing types:

 Availability Testing
 Baseline testing
 Compatibility testing
 Compliance testing
 Configuration Testing
 Documentation testing
 Endurance testing
 Ergonomics Testing
 Interoperability Testing

Page 16 of 88
STQA NOTES SYMCA

 Installation Testing
 Load testing
 Localization testing and Internationalization testing
 Maintainability Testing
 Operational Readiness Testing
 Performance testing
 Recovery testing
 Reliability Testing
 Resilience testing
 Security testing
 Scalability testing
 Stress testing
 Usability testing
 Volume testing

Baseline Testing

 It is one of the type of non-functional testing.

 It refers to the validation of documents and specifications on which test cases would
be designed. The requirement specification validation is baseline testing.
 Generally a baseline is defined as a line that forms the base for any construction or for
measurement, comparisons or calculations.
 Baseline testing also helps a great deal in solving most of the problems that are
discovered. A majority of the issues are solved through baseline testing.

Compatibility Testing

 It is a type of non-functional testing.

 Compatibility testing is a type of software testing used to ensure compatibility of the
system/application/website built with various other objects such as other web browsers,
hardware platforms, users (in case if it’s very specific type of requirement, such as a user
who speaks and can read only a particular language), operating systems etc. This type of
testing helps find out how well a system performs in a particular environment that includes
hardware, network, operating system and other software etc.
 It is basically the testing of the application or the product built with the computing
environment.
 It tests whether the application or the software product built is compatible with the
hardware, operating system, database or other system software or not.

Compliance Testing

 It is a type of non-functional software testing.

 It is related with the IT standards followed by the company and it is the testing done
to find the deviations from the company prescribed standards.
 It determines, whether we are implementing and meeting the defined standards.
 We should take care while doing this testing, Is there any drawbacks in standards
implementation in our project and need to do analysis to improve the standards.
 Its basically an audit of a system carried out against a known criterion.

Documentation Testing

Page 17 of 88
STQA NOTES SYMCA

Documentation testing is a non-functional type of software testing.

 It is a type of non-functional testing.

 Any written or pictorial information describing, defining, specifying, reporting, or
certifying activities, requirements, procedures, or results’. Documentation is as
important to a product’s success as the product itself. If the documentation is poor,
non-existent, or wrong, it reflects on the quality of the product and the vendor.
 As per the IEEE Documentation describing plans for, or results of, the testing of a
system or component, Types include test case specification, test incident report, test
log, test plan, test procedure, test report. Hence the testing of all the above mentioned
documents is known as documentation testing.
 This is one of the most cost effective approaches to testing. If the documentation is
not right: there will be major and costly problems. The documentation can be tested in
a number of different ways to many different degrees of complexity. These range
from running the documents through a spelling and grammar checking device, to
manually reviewing the documentation to remove any ambiguity or inconsistency.
 Documentation testing can start at the very beginning of the software process and
hence save large amounts of money, since the earlier a defect is found the less it will
cost to be fixed.

Endurance Testing

Endurance testing is a nonfunctional type of software testing.

 It is a type of non-functional testing.

 It is also known as Soak testing.
 Endurance testing involves testing a system with a significant load extended over a
significant period of time, to discover how the system behaves under sustained use.
For example, in software testing, a system may behave exactly as expected when
tested for 1 hour but when the same system is tested for 3 hours, problems such as
memory leaks cause the system to fail or behave randomly.
 The goal is to discover how the system behaves under sustained use. That is, to ensure
that the throughput and/or response times after some long period of sustained activity
are as good as or better than at the beginning of the test.
 It is basically used to check the memory leaks.

Load Testing

 Load testing is a type of non-functional testing.

 A load test is type of software testing which is conducted to understand the behavior
of the application under a specific expected load.
 Load testing is performed to determine a system’s behavior under both normal and at
peak conditions.
 It helps to identify the maximum operating capacity of an application as well as any
bottlenecks and determine which element is causing degradation. E.g. If the number
of users are increased then how much CPU, memory will be consumed, what is the
network and bandwidth response time.
 Load testing can be done under controlled lab conditions to compare the capabilities
of different systems or to accurately measure the capabilities of a single system.

Page 18 of 88
STQA NOTES SYMCA

 Load testing involves simulating real-life user load for the target application. It helps
you determine how your application behaves when multiple users hits it
simultaneously.
 Load testing differs from stress testing, which evaluates the extent to which a system
keeps working when subjected to extreme workloads or when some of its hardware or
software has been compromised.
 The primary goal of load testing is to define the maximum amount of work a system
can handle without significant performance degradation.
 Examples of load testing include:
 Downloading a series of large files from the internet.
 Running multiple applications on a computer or server simultaneously.
 Assigning many jobs to a printer in a queue.
 Subjecting a server to a large amount of traffic.
 Writing and reading data to and from a hard disk continuously.

Maintainability Testing

It basically defines that how easy it is to maintain the system. This means that how easy it is to
analyze, change and test the application or product.
Maintainability testing shall use a model of the maintainability requirements of the
software/system. The maintainability testing shall be specified in terms of the effort required to
effect a change under each of the following four categories:

 Corrective maintenance – Correcting problems. The maintainability of a system can

be measured in terms of the time taken to diagnose and fix problems identified within
that system.
 Perfective maintenance – Enhancements. The maintainability of a system can also be
measured in terms of the effort taken to make required enhancements to that system.
This can be tested by recording the time taken to achieve a new piece of identifiable
functionality such as a change to the database, etc. A number of similar tests should be
run and an average time calculated. The outcome will be that it is possible to give an
average effort required to implement specified functionality. This can be compared
against a target effort and an assessment made as to whether requirements are met.
 Adaptive maintenance – Adapting to changes in environment. The maintainability of
a system can also be measured in terms on the effort required to make required
adaptations to that system. This can be measured in the way described above for
perfective maintainability testing.
 Preventive maintenance – Actions to reduce future maintenance costs. This refers to
actions to reduce future maintenance costs.

Performance Testing

 It is a type of non-functional testing.

 Performance testing is testing that is performed, to determine how fast some aspect of a
system performs under a particular workload.
 It can serve different purposes like it can demonstrate that the system meets performance
criteria.
 It can compare two systems to find which performs better. Or it can measure what part of
the system or workload causes the system to perform badly.

Page 19 of 88
STQA NOTES SYMCA

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

Recovery Testing

 It is a type of non-functional testing.

 Recovery testing is done in order to check how fast and better the application can
recover after it has gone through any type of crash or hardware failure etc.
 Recovery testing is the forced failure of the software in a variety of ways to verify
that recovery is properly performed.
 For example: When 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 was broken.
 Example: Restart the system while a browser has a definite number of sessions and
check whether the browser is able to recover all of them or not.

Reliability Testing

Reliability Testing is about exercising an application so that failures are discovered and
removed before the system is deployed. The purpose of reliability testing is to determine
product reliability, and to determine whether the software meets the customer’s reliability
requirements.

 According to ANSI, Software Reliability is defined as: the probability of failure-free

software operation for a specified period of time in a specified environment. Software
Reliability is not a direct function of time. Electronic and mechanical parts may become
“old” and wear out with time and usage, but software will not rust or wear-out during
its life cycle. Software will not change over time unless intentionally changed or
upgraded.
 Reliability refers to the consistency of a measure. A test is considered reliable if we get
the same result repeatedly. Software Reliability is the probability of failure-free
software operation for a specified period of time in a specified environment. Software
Reliability is also an important factor affecting system reliability.
 Reliability testing will tend to uncover earlier those failures that are most likely in actual
operation, thus directing efforts at fixing the most important faults.
 Reliability testing may be performed at several levels. Complex systems may be tested
at component, circuit board, unit, assembly, subsystem and system levels.

Software reliability is a key part in software quality. The study of software reliability can be
categorized into three parts:

1.Modelling
2.Measurement
3. Improvement

1. Modeling:
Software reliability modeling has matured to the point that meaningful results can be obtained by
applying suitable models to the problem. There are many models exist, but no single model can

Page 20 of 88
STQA NOTES SYMCA

capture a necessary amount of the software characteristics. Assumptions and abstractions must be
made to simplify the problem. There is no single model that is universal to all the situations.
2. Measurement:
Software reliability measurement is naive. Measurement is far from commonplace in software, as in
other engineering field. “How good is the software, quantitatively?” As simple as the question is,
there is still no good answer. Software reliability can not be directly measured, so other related
factors are measured to estimate software reliability and compare it among products. Development
process, faults and failures found are all factors related to software reliability.
3. Improvement:
Software reliability improvement is hard. The difficulty of the problem stems from insufficient
understanding of software reliability and in general, the characteristics of software. Until now there
is no good way to conquer the complexity problem of software. Complete testing of a moderately
complex software module is infeasible. Defect-free software product can not be assured. Realistic
constraints of time and budget severely limits the effort put into software reliability improvement.

Security Testing

 It is a type of non-functional testing.

 Security testing is basically a type of software testing that’s done to check whether the
application or the product is secured or not. It checks to see if the application is vulnerable
to attacks, if anyone hack the system or login to the application without any authorization.
 It is a process to determine that an information system protects data and maintains
functionality as intended.
 The security testing is performed to check whether there is any information leakage in the
sense by encrypting the application or using wide range of software’s and hardware’s and
firewall etc.
 Software security is about making software behave in the presence of a malicious attack.
 The six basic security concepts that need to be covered by security testing are:
confidentiality, integrity, authentication, availability, authorization and non-repudiation.

Scalability Testing

 It is a type of non-functional testing.

 Testing the ability of a system, a network, or a process to continue to function well when it is
changed in size or volume in order to meet a growing need.
 It is the testing of a software application for measuring its capability to scale up in terms of
any of its non-functional capability like load supported, the number of transactions, the data
volume etc.
 Example: An ecommerce site may be able to handle orders for up to 100 users at a time but
scalability testing can be performed to check if it will be able to handle higher loads during
peak shopping seasons.

Stress Testing

 It is a type of non-functional testing.

 It involves testing beyond normal operational capacity, often to a breaking point, in
order to observe the results.
 It is a form of software testing that is used to determine the stability of a given
system.

Page 21 of 88
STQA NOTES SYMCA

 It put greater emphasis on robustness, availability, and error handling under a

heavy load, rather than on what would be considered correct behavior under normal
circumstances.
 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).

Usability Testing

In usability testing basically the testers tests the ease with which the user interfaces can be
used. It tests that whether the application or the product built is user-friendly or not.

 Usability Testing is a black box testing technique.

 Usability testing also reveals whether users feel comfortable with your application or
Web site according to different parameters – the flow, navigation and layout, speed
and content – especially in comparison to prior or similar applications.
 Usability Testing tests the following features of the software.

— How easy it is to use the software.

— How easy it is to learn the software.
— How convenient is the software to end user.

Usability testing includes the following five components:

 Learnability: How easy is it for users to accomplish basic tasks the first time they encounter
the design?
 Efficiency: How fast can experienced users accomplish tasks?
 Memorability: When users return to the design after a period of not using it, does the user
remember enough to use it effectively the next time, or does the user have to start over
again learning everything?
 Errors: How many errors do users make, how severe are these errors and how easily can
they recover from the errors?
 Satisfaction: How much does the user like using the system?

Benefits of usability testing to the end user or the customer:

— Better quality software

— Software is easier to use
— Software is more readily accepted by users
— Shortens the learning curve for new users

Advantages of usability testing:

 Usability test can be modified to cover many other types of testing such
as functional testing, system integration testing, unit testing, smoke testing etc.
 Usability testing can be very economical if planned properly, yet highly effective and
beneficial.
 If proper resources (experienced and creative testers) are used, usability test can
help in fixing all the problems that user may face even before the system is finally
released to the user. This may result in better performance and a standard system.

Page 22 of 88
STQA NOTES SYMCA

 Usability testing can help in discovering potential bugs and potholes in the system
which generally are not visible to developers and even escape the other type of
testing.

Usability testing is a very wide area of testing and it needs fairly high level of understanding of this
field along with creative mind. People involved in the usability testing are required to possess skills
like patience, ability to listen to the suggestions, openness to welcome any idea, and the most
important of them all is that they should have good observation skills to spot and fix the issues or
problems.

Volume testing

 It is a type of non-functional testing.

 Volume testing refers to testing a software application or the product with a certain
amount of data. E.g., if we want to volume test our application with a specific
database size, we need to expand our database to that size and then test the
application’s performance on it.
 “Volume testing” is a term given and described in Glenford Myers’ The Art of
Software Testing, 1979. Here’s his definition: “Subjecting the program to heavy
volumes of data. The purpose of volume testing is to show that the program
cannot handle the volume of data specified in its objectives” – p. 113.
 The purpose of volume testing is to determine system performance with increasing
volumes of data in the database.

Regression Testing

When any modification or changes are done to the application or even when any small
change is done to the code then it can bring unexpected issues. Along with the new changes it
becomes very important to test whether the existing functionality is intact or not. This can be
achieved by doing the regression testing.

 The purpose of the regression testing is to find the bugs which may get introduced
accidentally because of the new changes or modification.
 During confirmation testing the defect got fixed and that part of the application started
working as intended. But there might be a possibility that the fix may have introduced or
uncovered a different defect elsewhere in the software. The way to detect these
‘unexpected side-effects’ of fixes is to do regression testing.
 This also ensures that the bugs found earlier are NOT creatable.
 Usually the regression testing is done by automation tools because in order to fix the defect
the same test is carried out again and again and it will be very tedious and time consuming
to do it manually.
 During regression testing the test cases are prioritized depending upon the changes done to
the feature or module in the application. The feature or module where the changes or
modification is done that entire feature is taken into priority for testing.
 This testing becomes very important when there are continuous modifications or
enhancements done in the application or product. These changes or enhancements should
NOT introduce new issues in the existing tested code.
 This helps in maintaining the quality of the product along with the new changes in the
application.

Page 23 of 88
STQA NOTES SYMCA

Types of Regression testing techniques:

We have four types of regression testing techniques. They are as follows:

1) Corrective Regression Testing: Corrective regression testing can be used when there is no change
in the specifications and test cases can be reused.
2) Progressive Regression Testing: Progressive regression testing is used when the modifications are
done in the specifications and new test cases are designed.
3) Retest-All Strategy: The retest-all strategy is very tedious and time consuming because here we
reuse all test which results in the execution of unnecessary test cases. When any small modification
or change is done to the application then this strategy is not useful.
4) Selective Strategy: In selective strategy we use a subset of the existing test cases to cut down the
retesting effort and cost. If any changes are done to the program entities, e.g. functions, variables
etc., then a test unit must be rerun. Here the difficult part is to find out the dependencies between a
test case and the program entities it covers.

When to use it:

Regression testing is used when:

 Any new feature is added

 Any enhancement is done
 Any bug is fixed
 Any performance related issue is fixed

Advantages of Regression testing:

 It helps us to make sure that any changes like bug fixes or any enhancements to the
module or application have not impacted the existing tested code.
 It ensures that the bugs found earlier are NOT creatable.
 Regression testing can be done by using the automation tools
 It helps in improving the quality of the product.

Disadvantages of Regression testing:

 If regression testing is done without using automated tools then it can be very tedious
and time consuming because here we execute the same set of test cases again and
again.
 Regression test is required even when a very small change is done in the code because
this small modification can bring unexpected issues in the existing functionality.

Page 24 of 88