UNIT-3

Software Testing
 Software Testing –

- Software testing is a procedure to verify whether the actual results are same as of
the expected results.
- Software testing is performed to provide assurance that the software system does
not contain any defects.
- Defects mean errors which are detected by tester when actual result of our
software module is not identical as expected result.
- Software testing helps us to find out whether all user requirements are fulfilled by
our software or not.
- Software quality depends on; at what extend software fulfils user requirements and
number of defects occurred in software.
- Software testing is used to give assurance that we deliver quality product to
customer.
- To perform software testing we create test cases and test data.
- Test Case is a collection of actions which applied on our software product to check
specific feature or functionality of it.
- Collection of test cases is called as test suit.
- Test data is the input provided to modules which are present in our software
product.
- Test data represents the data which effects execution of the particular module.
- Sometime test data is used for positive testing.
- That means it is used to check that a provided set of input for given function
generate expected result or not.
- Sometime test data is used for negative testing. That means test data is used to test
the capability of our software modules to handle unexpected input.

 Principles of Software Testing

There are seven Testing principles which are as follows:
1. Complete testing of software is not possible
- Complete testing of software is not possible. Rather we require performing the
best possible amount of testing with the help of risk assessment of the application.
- Risk assessment is the process of guessing module where defects may occur and
test that module to find out those defects.
- Because we have not that much amount of time to test each and every module
from our software complete testing of software is not possible.
2. Defect clustering
- This principle states that about 80% of defects are found in 20% of modules.
- Using experience we can find out such risky modules.
- But this approach has its own drawbacks such as if we run similar test cases
repetitively such test cases does not find any new defect.
3. Pesticide Paradox
 - If we use same test cases repetitively for testing then after particular point we
cannot find new defect.
- To solve this problem the test cases required to be reviewed and revised on regular
basis and include new test cases to help in finding new defects.
- Testers cannot use only existing testing mechanism.
- He should try to improve the existing methods to find out more defects.
- But after performing testing you can never claim your product is bug free.
4. Testing shows presence of defects
- Testing process can show that the defects are present in the system under test but
it cannot prove that there are no defects.
- Even after testing we cannot guarantee that system is 100% error free.
- Objectives of testing process are as follows:
(i) Finding defects which are created by developer while developing software.
(ii) Providing information about quality of software under test.
(iii) To ensure that system meets the business and the user requirements.
(iv) To gain customer's confidence by providing them a qualitative product.
5. Absence of error
- The software which is 99% bug free can be still unusable if it is tested for wrong
requirements i.e. absence of error does not help if system does not satisfy user's
need and requirement.
6. Early Testing
- Testing must be started as early as possible in the Software Development Life Cycle
(SDLC).
- Therefore any bug in the requirements or design phase are find out in early phases
of software testing.
- It is less costly to correct that bug in early stages of testing.
- It is suggested that we can start detecting the bug at time when requirements are
gathered.
7. Testing is context dependent
- Testing is context dependent specifies that the way tester test an online shopping
site will be different from the way he /she test stand-alone application.

 Objectives of Software Testing

Following are some important objectives of Software Testing:

1. Finding defects which can be generated by the programmer while doing coding of
software.
2. Report the detected defects to developer for correction and after correction retest
the software product to give assurance that software does not contain any defect.
3. Software testing is done to give assurance that our software product fulfills all
requirements of end user.
4. To give assurance that we deliver quality software to our end user.
5. To make sure that it satisfies requirements present in the BRS (Business
Requirement Specification) and SRS (System Requirement Specifications).
 6. To get the confidence of the customers by giving them a quality software product
which must be user friendly and fulfils all the requirements and expectations of
customer.

 Software Testing Life Cycle, Phases of Testing

- Software testing life cycle is a sequence of various activities which helps to certify
software system.
- Software testing process activities are: Requirement analysis Test planning Test
case development environment up Test execution Test cycle closures.
- Each of the activity of software testing process has defined entry and exit criteria.
- Entry criteria: Entry criterions of testing are prerequisite conditions that must be
satisfied before testing begins.
- Exit criteria: An Exit criterion of testing describes the conditions that must be
satisfied before testing is concluded.

- Phases of Testing process

 Strategic Approach to Software Testing

- As we have seen Testing is a considered as a set of activities which can be planned

in advance and implemented systematically.
- Hence a there is need to define template for software testing which will be a series
of steps in which specific test case design techniques as well as testing methods can
be placed.
- There are number of software testing strategies available from which following
characteristics are expected:
 For effective testing there is need of effective technical reviews. This helps to
eliminate errors before testing commences.
 Testing begins with component level and proceeds "outward toward the
incorporation of the whole computer-based system.
  Different testing techniques are considered as suitable for different software
engineering approaches and a different point in time.
 In case of small projects software developer conducts the testing but for large
projects there is need of an independent test group.
 Testing and debugging are considered as two distinct activities but it is
necessary to accommodate debugging in any testing strategy.
- For a strategy of software testing it is important to accommodate low-level tests
which are required to verify that implementation of a small source code segment as
well as high-level tests which are used to validate most important system functions
against customer requirements is correct.
- A strategy must offer guidance for the practitioner (newcomer) and a set of
milestones for the well experienced manager.
- Since the execution of steps regarding the test strategy is done at a time when
there is increase in deadline pressure progress must be measurable and problems
should be identified as early as possible.

 Verification and Validation

 Organizing for Software Testing
- For every software project there is an essential conflict of interest that occurs as
testing begins. The people who have built the software are now asked to test the
software.
- This seems harmless in itself after all who knows the program better than its
developers? Unfortunately these same developers have a devolved interest in
demonstrating that the program is error free that it works according to customer
requirements and that it will be completed on schedule and within budget.
- From a psychological point of view software analysis and design (along with
coding) are constructive tasks.
- The software engineer analyzes models and then creates a computer program and
its documentation.
- From the point of view of the builder testing can be considered to be
(psychologically) destructive.
- So the builder treads lightly designing and executing tests that will demonstrate
that the program works rather than uncovering errors. Unfortunately errors will
be present.
- There are often a number of misconceptions those can be erroneously inferred
from the preceding discussion:
1) That the developer of software should do no testing at all
2) That the software should be "tossed over the wall" to strangers who will
test it harshly
3) That testers get involved with the project only when the testing steps are
about to begin. Each of these statements is incorrect.
- The software developer is always responsible for testing the individual units
(components) of the program.
- Only after the software architecture is completed one Independent Test Group
(ITG) is involved.
- The role of an Independent Test Group (ITG) is to remove the inherent problems
associated with letting the builder test the thing that has been built.
- Independent testing removes the conflict of interest that may otherwise be
present.
- After all ITG personnel are paid to find errors.
- The ITG is part of the software development project team in the sense that it
becomes involved during analysis and design and stays involved (planning and
specifying test procedures) throughout a large project.
- Software Testing Strategy –
- The software process can be
considered as the spiral.
- In the beginning the role of software
is defined by the system engineering
and proceed to software requirements
analysis in which there is
establishment of the information
domain function behavior
performance constraints and
validation criteria for software.
- Moving towards inward in the spiral
we come to design and at the end to coding.
- It is possible to view a strategy for software testing in the context of the spiral.
- Unit testing gets started at the vortex of the spiral and focus on all of the software
units such as component class or WebApp content object which are implemented
in source code.
- Testing continues by traversing outward direction along the spiral to integration
testing.
- Here the main concentration is on designing and building the software architecture.
- Taking next turn outward on the spiral we can observe validation testing in which
requirements which are set as part of requirements modeling are validated against
the respective software which has been developed.
- At last we reach at system testing where testing of the software as well as other
system elements is done as a whole
- For testing any computer software we have to spiral out in a clockwise direction
along updates which enhances the scope of testing with each and every turn
- Practically testing is an implementation of four steps in a sequence.
 The Big Picture

- Software engineering has become a very important part of computer science so

much so that today's programmers or software engineers.
- As software becomes larger the teams working on it have grown and good
communication skills have become even more important than in the past.
- Furthermore computer systems are only useful if they make things better for
humans so developers need to be good at understanding the users they are
developing software for.
- As computers become smaller and cheaper we have gone from having shared
computers that humans have to queue up to use to having multiple digital devices
for each person.
- Now it's the devices that have to wait until the human is ready. In a digital system
the human is the most important part.
- "Big picture" is a relative term:
o For the junior software engineer writing code correctly and quickly is part of
the big picture project delivery.
o For the senior associate it is about contributing to the overall project with his
team.
o For the manager it is about contributing to the client.
o For the company it is about building good business relationships based on
mutual trust and co-operation
o For the clients it is about giving value to their own customers.

 Criteria for Completion of Testing

- The completion criteria are the conditions that are specified for stopping the
testing. Sometimes it becomes very difficult to say when the testing phase is
completed and when the product can be released.
- The stop-test criteria are as follows:
-
o All the planned testing have been executed and completed successfully. Also
it has been passed.
o All the specified goals have been achieved.
o All the defects have been removed and all the errors have been uncovered
and resolved successfully.
o Detection of defects have been completed within stipulated time.
o The project time has run out.
o When we are not able to detect any known serious defects
o When the specified coverage has been successfully attained.
 Strategic Issues.

- Following issues must be addressed if a successful software testing strategy is to be

implemented:
1. Specify product requirements in a quantifiable manner long before testing
commences
- Although the overriding objective of testing is to find errors a good testing
strategy also assesses other quality characteristics such as portability
maintainability and usability.
- These should be specified in a way that is measurable so that testing results are
unambiguous.
2. State testing objectives explicitly
- The specific objectives of testing should be stated in measurable terms. For
example test coverage mean time to failure the cost to find and fix defects
remaining defect density or frequency of occurrence and test work-hours per
regression test all should be stated within the test plan.

3. Understand the users of the software and develop a profile for each user
category
- Use-cases that describe the interaction scenario for each class of user can
reduce overall testing effort by focusing testing on actual use of the product.

4. Develop a testing plan that emphasizes "rapid cycle testing"

- The feedback generated from these rapid cycle tests can be used to control
quality levels and the corresponding test strategies.

5. Build "robust" software that is designed to test itself

- Software should be designed in a manner that uses antibugging techniques. That
is software should be capable of diagnosing certain classes of errors. In addition
the design should accommodate automated testing and regression testing

6. Use effective formal technical reviews as a filter prior to testing

- Formal technical reviews can be as effective as testing in uncovering errors. For
this reason reviews can reduce the amount of testing effort that is required to
produce high-quality software.

7. Conduct formal technical reviews to assess the test strategy and test cases
themselves
- Formal technical reviews can uncover inconsistencies omissions and outright
errors in the testing approach.
- This saves time and also improves product quality.
8. Develop a continuous improvement approach for the testing process
 - The test strategy should be measured. The metrics collected during testing
should be used as part of a statistical process control approach for software
testing.

 Test Strategies for Conventional Software, Unit Testing, Integration

Testing,
- For the conventional software there are various test strategies available for use.
- In first one the team waits for a product development to be completed and
then start conducting tests.
- In another approach the developer conducts the test on a daily basis as the
development proceeds and one part of the program is completed.
- These strategies are chosen by the development team based on the product and
convenience of the team.
- The choice may among two approaches discussed above.
- The team starts with an incremental view of testing and test individual program
units. Then moving ahead with integration of the units and finalizing the tests of
overall system.
- Different types of tests are mentioned as follows:
1. Unit Testing
2. Integration Testing
3. Regression Testing
4. Smoke Testing

1. Unit Testing
- In unit testing the main focus is on assessment of smallest unit of the product
design like component of the software or module. The unit testing has limited
scope and it emphasises on internal processing and data structures. Multiple
modules and components can be tested in parallel Unit test
- Unit Testing is a level of software testing
where individual units/components of a
software are tested. The purpose is to
validate that each unit of the software
performs as designed.
- A unit is the smallest testable part of any
software. It usually has one or a few
inputs and usually a single output.
- When is it performed? -- Unit Testing is
the first level of software testing and is performed prior to Integration Testing
- Who performs it? -- It is normally performed by software developers themselves
or their peers. In rare cases it may also be performed by independent software
testers.
- Stubs and Drivers In Unit Testing-
 (1) Stubs- Assume we have 3 modules Module A Module B and Module C
Module A is ready and we need to test it but module A calls functions from
Module B and C which are not ready so developer will write a dummy
module which simulates B and C and returns values to module A. This
dummy module code is known as stub..
(2) Drivers- Now suppose we have Modules B and C ready but Module A which
calls functions from Module B and C is not ready so developer will write a
dummy piece of code for Module A which will return values to Module B
and C. This dummy piece of code is known as driver.

- Unit Testing Tasks/Aspects of the software tested in unit testing

1. Unit Test Plan 5. Unit Test Cases/Scripts.
2. Prepare 6. Unit Test. Perform
3. Review 7. Rework
4. Baseline

- Unit Testing Benefits

 Unit testing increases confidence in changing/ maintaining code.
 If good unit tests are written and if they are run every time any code is
changed we will be able to promptly catch any defects introduced due to
the change.
 Also if codes are already made less interdependent to make unit testing
possible the unintended impact of changes to any code is less
 Codes are more reusable. In order to make unit testing possible codes
need to be modular. This means that codes are easier to reuse.
 Development is faster. If there is no unit testing in place developer writes
the code and performs that fuzzy "developer test' (Developer set some
breakpoints fire up the GUI provides a few inputs that hopefully hit the
code and hope that are all is set) But if there is unit testing in place
developer/tester writes the test write the code and run the test.
 Writing tests takes time but the time is compensated by the less amount of
time it takes to run the tests; there is no need to fire up the GUI and
provide all those inputs.
 And also unit tests are more reliable than 'developer tests'. Development
is faster in the long run too.
 The effort required to find and fix defects found during unit testing is very
less in comparison to the effort required to fix defects found during system
testing or acceptance testing
 The cost of fixing a defect detected during unit testing is lesser in
comparison to that of defects detected at higher levels.
 Debugging is easy. When a test fails only the latest changes need to be
debugged. With testing at higher levels changes made over the span of
several days/weeks/months need to be scanned.

2. Integration Testing
- Integration testing is used for constructing the
software architecture.
- It is a systematic approach for conducting tests
to uncover interfacing errors.
- The main objective behind integration testing is
to accept all the unit tested components and
integrate into a program structure as given by
the design.
- Integration testing is a method of software testing in which all units of software
under test are integrated and tested as a single group
- It is always done after unit testing is applied.
- It mainly focuses on testing data communication among all units of system.
- It makes use of mythologies as Big bang approach and incremental approach
- Incremental approach can be either top-down bottom-up or combination of
both
- The main objective of integration testing is to determine faults in
communication between integrated units

 Following are objectives of Integration Testing:

- A Module is developed by software developer whose level of understanding
and programming logic may not be same as of other software developers
from project team
- So while performing Integration Testing we required to check whether
software module works efficiently with other modules or not
- While developing single module there is risk of changes in requirements by
the clients.
- We may not perform unit testing for this new requirements and so
performing integration testing of software is needed
- There is possibility that interfaces (through which operations on database
are done) present between software modules and database may contain
error.
- There is possibility of error occurrence due to external hardware interfaces.
- There is possibility of raising issues if exceptions are not handled property
- For all these reasons we need to perform integration testing.
  Software Testing - Validation Testing
The process of evaluating software during the development process or at
the end of the development process to determine whether it satisfies
specified business requirements.

Validation Testing ensures that the product actually meets the client's
needs. It can also be defined as to demonstrate that the product fulfills its
intended use when deployed on appropriate environment.

Validation Testing - Workflow:

Validation testing can be best demonstrated using V-Model. The
Software/product under test is evaluated during this type of testing.
 Activities:
1. Unit Testing
2. Integration Testing
3. System Testing
4. User Acceptance Testing

 What is Verification Testing ?

Verification is the process of evaluating work-products of a development
phase to determine whether they meet the specified requirements.

verification ensures that the product is built according to the requirements

and design specifications. It also answers to the question Are we building
the product right?

Verification Testing - Workflow:

verification testing can be best demonstrated using V-Model. The artefacts such as test Plans requirement
specification design code and test cases are evaluated.

Activities:

1. Reviews
2. Walkthroughs
3. Inspection
Difference between verification and validation testing

Verification Validation

We check whether we are developing the We check whether the developed product
right product or not. is right.

Verification is also known as static Validation is also known as dynamic

testing. testing.

Verification includes different methods like Validation includes testing like functional
Inspections, Reviews, and Walkthroughs. testing, system testing, integration, and
User acceptance testing.

It is a process of checking the work- It is a process of checking the software

products (not the final product) of a during or at the end of the development
development cycle to decide whether the cycle to decide whether the software
product meets the specified requirements. follow the specified business
requirements.

Quality assurance comes under Quality control comes under validation

verification testing. testing.

The execution of code does not happen in In validation testing, the execution of code
the verification testing. happens.

In verification testing, we can find the In the validation testing, we can find those
bugs early in the development phase of bugs, which are not caught in the
the product. verification process.

Verification testing is executed by the Validation testing is executed by the

Quality assurance team to make sure that testing team to test the application.
the product is developed according to
customers' requirements.

Verification is done before the validation After verification testing, validation testing
testing. takes place.

In this type of testing, we can verify that In this type of testing, we can validate that
the inputs follow the outputs or not. the user accepts the product or not.
Differences between the Alpha testing and Beta testing are:

Sr. Alpha Testing Beta Testing

No.

1. Alpha testing performed by a team of Beta testing performed by clients or

highly skilled testers who are usually end-users in a real-time environment,
the internal employee of the who is not an employee of the
organization. organization.

2. Alpha testing performed at the Beta testing doesn't need any lab
developer's site; it always needs a environment or the testing
testing environment or lab environment; it is performed at a
environment. client's location or end-user of the
product.

3. Reliability or security testing not Reliability, security, and robustness

performed in-depth in alpha testing. checked during beta testing.

4. Alpha testing involves both white box Beta testing uses only black-box
and black-box techniques. testing.

5. Long execution cycles maybe require Only a few weeks are required for the
for alpha testing. execution of beta testing.

6. Critical issues or fixes can be identified Most of the issues or feedback is

by developers immediately in alpha collecting from the beta testing will be
testing. implemented for the future versions of
the product.

7. Alpha testing performed before the At the time of software product

launch of the product into the market. marketing.

8. Alpha testing focuses on the product's Beta testing concentrates on the

quality before going to beta testing. quality of the product, but gathers
users input on the product and ensures
that the product is ready for real-time
users.

9. Alpha testing performed nearly the end Beta testing is a final test before
of the software development. shipping a product to the customers.

10. Alpha testing is conducting in the Beta testing reversed of alpha testing.
presence of developers and the
 absence of end-users.

Black Box Testing vs. White Box Testing vs.

Grey Box Testing
Index Black Box Testing White Box Testing Grey Box Testing

1 Knowledge of internal Knowledge of internal Partially Knowledge of

working structure (Code) is working structure the internal working
not required for this type of (Coding of software) is structure is required.
testing. Only GUI (Graphical necessarily required
User Interface) is required for this type of testing.
for test cases.

2 Black Box Testing is also White Box Testing is Grey Box Testing is
known as functional testing, also known as also known as
data-driven testing, and structural testing, translucent testing as
closed box testing. clear box testing, the tester has limited
code-based testing, knowledge of coding.
and transparent
testing.

3 The approach towards White Box Testing is If the tester has

testing includes trial proceeded by verifying knowledge of coding,
techniques and error the system boundaries then it is proceeded
guessing method because and data domains by validating data
tester does not need inherent in the domains and internal
knowledge of internal coding software as there is no system boundaries of
of the software. lack of internal coding the software.
knowledge.

4 The testing space of tables The testing space of The testing space of
for inputs (inputs to be used tables for inputs tables for inputs
for creating test cases) is (inputs to be used for (inputs to be used for
pretty huge and largest creating test cases) is creating test cases) is
among all testing spaces. less as compared to smaller than Black
Black Box testing. Box and White Box
testing.

5 It is very difficult to discover It is simple to discover Difficult to discover

hidden errors of the software hidden errors because the hidden error.
because errors can be due to it can be due to Might be found in user
internal working which is internal working which level testing.
unknown for Black Box is deeply explored in
 testing. White Box testing.

6 It is not considered for It is well suitable and It is not considered for

algorithm testing. recommended for algorithm testing.
algorithm testing.

7 Time consumption in Black White Box testing Test cases designing

Box testing depends upon takes a long time to can be done in a short
the availability of the design test cases due time period.
functional specifications. to lengthy code.

8 Tester, developer and the Only tester and Tester, developer and
end user can be the part of developer can be a the end user can be
testing. part of testing; the end the part of testing.
user can not involve.

9 It is the least time- The entire testing less time consuming

consuming process among process is the most than White Box
all the testing processes. time consuming testing.
among all the testing
processes.

10 Resilience and security Resilience and security Resilience and

against viral attacks are against viral attacks security against viral
covered under Black Box are not covered under attacks are not
testing. White Box testing. covered under Grey
Box testing.

11 The base of this testing is The base of this Testing based on high-
external expectations testing is coding which level database
internal behavior is is responsible for diagrams and
unknown. internal working. dataflow diagrams.

12 It is less exhaustive than It is most exhaustive Partly exhaustive;

White Box and Grey Box between Black Box depends upon the
testing methods. and Grey Box testing type of test cases are
methods. coding based or GUI
based.
Object-oriented Testing in Software Testing

Object Oriented testing can be performed at different levels to detect the issues. At the
algorithmic level, a single module of every class should be tested. As discussed earlier, testing
of classes is the main concern of the Object Oriented program. Every class gets tested as an
individual entity at the class level. Generally, programmers who are creating the classes are
involved in testing. Test cases for Object-Oriented Testing in Software Testing can be
constructed based on the requirement specifications, programming language, and models.

Once class-level testing is done, Cluster level testing will be performed. Cluster-level testing is
the integration of individual classes. The main purpose of doing integration testing is to verify
the interconnection between classes and how well they perform interclass interactions. Thus,
Cluster level testing can be viewed as integration testing of classes.

Once Cluster level testing is performed, system-level testing begins. At this level, integration
between clusters can be taken care of. Also, at each level regression testing is a must after
every new release.