CS366/DMIEC

DMI ENGINEERING COLLEGE

Aralvaimozhi

DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING

CCS366 Software testing and automation

Notes
(Regulation 21)

Prepared by,
Mrs.A.Anorelin, AP/CSE
CS366/DMIEC

CCS366 SOFTWARE TESTING AND AUTOMATION L T P C 2 0 2

3

COURSE OBJECTIVES:
•To understand the basics of software testing
•To learn how to do the testing and planning effectively
•To build test cases and execute them
•To focus on wide aspects of testing and understanding multiple
facets of testing
• To get an insight about test automation and the tools used for test
automation
UNIT I FOUNDATIONS OF SOFTWARE TESTING 6
Why do we test Software? Black-Box Testing and White-Box Testing, Software
Testing Life Cycle, V-model of Software Testing, Program Correctness and
Veri昀椀cation, Reliability versus Safety, Failures, Errors and Faults (Defects),
Software Testing Principles, Program Inspections, Stages of Testing: Unit Testing,
Integration Testing, System Testing

UNIT II TEST PLANNING 6

The Goal of Test Planning, High Level Expectations, Intergroup
Responsibilities, Test Phases, Test Strategy, Resource Requirements, Tester
Assignments, Test Schedule, Test Cases, Bug Reporting, Metrics and Statistics.

UNIT III TEST DESIGN AND EXECUTION 6

Test Objective Identi昀椀cation, Test Design Factors, Requirement identi昀椀cation,
Testable Requirements, Modeling a Test Design Process, Modeling Test Results,
Boundary Value Testing, Equivalence Class Testing, Path Testing, Data Flow
Testing, Test Design Preparedness Metrics, Test Case Design Effectiveness, Model-
Driven Test Design, Test Procedures, Test Case Organization and Tracking, Bug
Reporting, Bug Life Cycle.

UNIT IV ADVANCED TESTING CONCEPTS 6

Performance Testing: Load Testing, Stress Testing, Volume Testing, Fail-Over
Testing, Recovery Testing, Con昀椀guration Testing, Compatibility Testing,
Usability Testing, Testing the Documentation, Security testing, Testing in the Agile
Environment, Testing Web and Mobile Applications.

UNIT V TEST AUTOMATION AND TOOLS 6

Automated Software Testing, Automate Testing of Web Applications, Selenium:
Introducing Web Driver and Web Elements, Locating Web Elements, Actions
on Web Elements, Different Web Drivers, Understanding Web Driver Events,
Testing: Understanding Testing.xml, Adding Classes, Packages, Methods to Test,
Test Reports.

30 PERIODS
CS366/DMIEC

PRACTICAL EXERCISES:30 PERIODS

• Develop the test plan for testing an e-commerce web/mobile

application (www.amazon.in).
• Design the test cases for testing the e-commerce application
• Test the e-commerce application and report the defects in it.
• Develop the test plan and design the test cases for an inventory control system.
• Execute the test cases against a client server or desktop application and identify
the defects.
• Test the performance of the e-commerce application.
• Automate the testing of e-commerce applications using Selenium.
• Integrate TestNG with the above test automation.
• Mini Project:
a) Build a data-driven framework using Selenium and TestNG
b) Build Page object Model using Selenium and TestNG
c) Build BDD framework with Selenium, TestNG and Cucumber

COURSE OUTCOMES:
CO1: Understand the basic concepts of software testing and the need for software
testing
CO2: Design Test planning and different activities involved in test planning
CO3: Design effective test cases that can uncover critical defects in the application
CO4: Carry out advanced types of testing
CO5: Automate the software testing using Selenium and TestNG
TOTAL:60 PERIODS
TEXTBOOKS

• Yogesh Singh, “Software Testing”, Cambridge University Press,

2012
•
Unmesh Gundecha, Satya Avasarala, "Selenium
WebDriver 3 Practical Guide" - Second Edition 2018
REFERENCES
• Glenford J. Myers, Corey Sandler, Tom Badgett, The Art of
Software Testing, 3rd Edition, 2012, John Wiley & Sons, Inc.
• Ron Patton, Software testing, 2nd Edition, 2006, Sams Publishing
• Paul C. Jorgensen, Software Testing: A Craftsman’s Approach,
Fourth Edition, 2014, Taylor & Francis Group.
• Carl Cocchiaro, Selenium Framework Design in Data-Driven
Testing, 2018, Packt Publishing.
• Elfriede Dustin, Thom Garrett, Bernie Gaurf, Implementing
Automated Software Testing, 2009, Pearson Education, Inc.
• Satya Avasarala, Selenium WebDriver Practical Guide, 2014, Packt
Publishing.
• Varun Menon, TestNg Beginner's Guide, 2013, Packt Publishing
CS366/DMIEC

UNIT I FOUNDATIONS OF SOFTWARE TESTING

Why do we test Software? Black-Box Testing and White-Box Testing, Software

Testing Life Cycle, V-model of Software Testing, Program Correctness and
Varication, Reliability versus Safety, Failures, Errors and Faults (Defects),
Software Testing Principles, Program Inspections, Stages of Testing: Unit Testing,
Integration Testing, System Testing
1.1 Introduction

This chapter will discuss the fundamentals of testing, such as why testing is
required, its limitations, airs and purposes, as well as the guiding principles, step- by-
step methods and psychological concerns that testers must: take into mind. You will
be able to explain the fundamentals of testing after reading this chapter.

Software testing is a method for figuring out if the real piece of software meets
requirements and is error-free. It involves running software or system components
manually of automatically in order to evaluate one or more intriguing characteristics.
Finding faults; gaps or unfulfilled requirements in comparison to the documented
specifications is-the aim of software testing.

Some prefer to use the terms white box and black box testing to describe the concept
of software testing. To-put it simply, software testing is the process of validating an
application that is being tested (AUT). In this course, software testing is explained to
the audience and its importance is justified.

1.1.1 What is Software Testing

Software testing is the process of determining if a piece of software is accurate

by taking into account all of its characteristics (reliability, scalability, portability, Re-
usability and usability) and analyzing how its various components operate in order to
detect any bugs, faults or flaws.

Software testing delivers assurance of the software's fitness and offers a

detached viewpoint and purpose of the programmer. It entails testing each component
that makes up the necessary services to see whether or not it satisfies the set criteria.
Additionally, the procedure informs the customer about the software's caliber.

Testing is required because failure of the programmer at any point owing to a

lack of testing. would be harmful. Software cannot be released to the end user without
being tested.
CS366/DMIEC

1.1.2 What ‘is Testing

Testing is a collection of methods to evaluate an application's suitability for
use in accordance with a predetermined script, however testing is not able for detect
every application flaw. The basic goal of testing is to find application flaws so that
they may be identified and fixed. It merely shows that a product doesn't work in
certain particular circumstances, not that it works correctly under all circumstances.

Testing offers comparisons between software behavior and state and

mechanisms since mechanisms may identify problems in software. The method may
incorporate previous’ iterations of the same or similar items, comparable goods,
expected-purpose interfaces, pertinent standards or other criteria, but is not restricted
to these.

Testing includes both the analysis and execution of the code in different
settings and environments, as well as the whole code analysis. A testing team may be
independent from the development team in the present software development
scenario so that information obtained from testing may be utilized to improve the
software development process.

The intended audience's adoption of the programed, its user-friendly graphical

user interface, its robust functionality load test, etc., is all factors in its success. For
instance, the target ‘market for banking and a video game are very different. As a
result, an organization can determine if a software product it produces will be useful
to its customers and other audience members.

1.1.3 Why Software Testing is Important?

Programed testing is crucial because it allows any faults or mistakes in the

program to be found early and fixed before the software product is delivered.
Reliability, security and high performance are all ensured by well tested software,
which also leads to time savings, cost efficiency and customer pleasure.

1.1.4 What is the Need of Testing?

Software flaws may be costly or even harmful, thus testing instances when
software defects led to financial and personal loss is crucial. History is replete with

➢ Over 300,000 traders in the financial markets were impacted after a software
error caused the London Bloomberg terminal to collapse in April 2015. It
made the government delay a 3-billion-pound debt auction.
CS366/DMIEC

➢ Nissan recalled nearly 1 million: vehicles from the market because the
airbag sensory detectors’ software was flawed. Due to this software flaw,
two accidents have been documented.
➢ Starbucks' POS system malfunctioned, forcing them to shut nearly 60 % of its
locations in the United States and Canada. The shop once provided free coffee
since they couldn't complete the purchase. -
➢ Due to a technical error, some of Amazon's third-party sellers had them
product prices slashed to 1p. They suffered severe losses as a result.
➢ A weakness in windows 10. Due to a defect in the win32k system, users are
able to bypass security sandboxes thanks to this issue.
➢ In 2015, a software flaw rendered the F-35 fighter jet incapable of accurately
detecting “targets. On April 26, 1994; an airbus A300 operated by China
airlines crashed due to a software error, killing 264 unintentional people.
➢ Three patients died and three others were badly injured in 1985 when a
software glitch caused Canada's Therac-25 radiation treatment system to fail
and deliver deadly radiation doses to patients.
➢ In May 1996, a software error led to the crediting of 920 million US dollars.
to the bank accounts of 823 clients of a large U.S. bank.
➢ In April 1999, a software error resulted in the failure of a $1.2 billion
military satellite launch, making it the most expensive, accident in history.
1.1.5 What are the Benefits of Software Testing?

The following are advantages of employing software testing:

One of the key benefits of software testing is that it is cost-effective. Timely

testing of any IT project enables you to make long-term financial savings. If flaws
are found sooner in the software testing process, fixing them is less expensive.

Security: This perilous and delicate advantage of software testing. People are
searching for reliable goods. It assists in eradicating hazards and issues early.

Product quality: Any software product must meet these criteria. Testing guarantees
that buyers get a high-quality product.

Customer satisfaction: Providing consumers with contentment is the primary goal

of every product. The optimum user experience is made guaranteed of through U/UX
testing.
CS366/DMIEC

1.1.6 Type of Software Testing

1. Manual testing:

« The process of checking the functionality of an application as per the customer

needs without taking any help of automation tools is known as manual testing. While
performing the manual testing on any application, we do not need any specific
knowledge of any testing tool, rather than have a proper understanding of the product
so we can easily prepare the test document.

Manual testing can be further divided into three types of testing, which are as
follows:

➢ White box testing

➢ Black box testing
➢ Gray box testing.
2. Automation testing:

Automation testing is a process of converting any manual test cases into the
test scripts with the help of automation tools or any programming language is known
as automation testing. ‘With the help of automation testing, we can enhance the speed
of our test execution because here, we do not require any human efforts. We need to
write a test script and execute those scripts.
CS366/DMIEC

1.2 Black-Box Testing and White-Box Testing

Black box testing (also called functional testing) is testing that ignores the
internal mechanism of a system or component and focuses solely on the outputs
generated in response to selected inputs and execution conditions. White box testing
(also called structural testing and glass box testing) is testing that takes into account
the internal mechanism of a system or component.

1.2.1 What is White-Box Testing

Testing a system in a "black box" is doing so without knowing anything about
how it operates within. A tester inputs data and monitors the output produced by the
system being tested. This allows for the identification of the system's reaction time,
usability difficulties and reliability concerns as well as how the system reacts to
anticipated and unexpected user activities.
Because of the system's internal viewpoint, the phrase "white box" is
employed. The term “clear box," "white box" or "transparent box" refers to the
capability of seeing the software's inner workings through its exterior layer.

Developers carry it out before sending the program to. the testing team, who
then conducts black-box testing. Testing the infrastructure of the application is the
primary goal of white-box testing. As it covers unit testing and integration testing, it
is performed at lower levels. Given that it primarily focuses on the code structure,
pathways, conditions and ‘branches of a programed or piece of software, it
necessitates programming skills. Focusing on the inputs and outputs via the program
and enhancing its security are the main objectives of white-box testing:

It is also referred to as transparent testing, code-based testing, structural

testing and clear box testing. It is a good fit and is recommended for testing
algorithms.

1.2.1.1 Types of White Box Testing in Software Testing

White box testing is a type of software testing that examines the internal
structure and design of a program or application. The following are some common
types of white box testing:

1. Unit testing: Tests individual units or components of the software to ensure they
function as intended.
CS366/DMIEC

2. Integration testing: Tests the interactions between different units or components

of the software to ensure they work together correctly.

3. Functional testing: Tests the functionality of the software to ensure it meets the
requirements and specifications.
4. Performance testing: Tests the performance of the software under various loads
and conditions to ensure it meets performance requirements.

5. Security testing: Tests the software for vulnerabilities and weaknesses to ensure
it is secure.

6. Code coverage testing: Measures the percentage of code that is executed during
testing for ensure that all parts of the code are tested.

7. Regression testing: Tests the software after changes have been made to ensure
that the changes did not introduce new bugs or issues.

1.2.1.2 Techniques of White Box Testing

There are some techniques which is used for white box testing -

1. Statement coverage: This testing approach involves going over every statement
in the code to make sure that each one has been run at least once. As a result, the code
is checked line by line.

2. Branch coverage: Is a testing approach in which test cases are created to ensure
that each ranch is tested at léast once. This method examines all potential
configurations for the system.

3. Path coverage: Path coverage is a software testing 2pproach that defines and
covers all potential pathways. From system entrance to exit points, pathways are
statements that may ‘be executed. It takes a lot of time.

4. Loop testing: With the help of this technique, loops and values in both
independent and dependent code are examined. Errors often happen at the start and
conclusion of loops. This method included testing loops
• Concatenated loops
• Simple loops
• Nested loops
CS366/DMIEC

5. Basis path testing: Using this methodology, control flow diagrams are created
from code and subsequently calculations are made for cyclomatic complexity. For the
purpose of designing the fewest possible test cases, cyclomatic complexity specifies
the quantity of separate routes.

1.2.1.3 Advantages of White Box Testing

1. Complete coverage.
2. Better understanding of the system.
3. Improved code quality.
4. Increase efficiency.
5. Early detection of error.

1.2.1.4 Disadvantages of White Box Testing

1. This testing is very expensive and time-consuming.

2. Redesign of code needs test cases to be written again.

3. Missing functionalities cannot be detected.

4. This technique can be very complex and at times not realistic.

5. White-box testing requires a programmer with a high level of knowledge

due for the complexity of the level of testing that needs to be done.

1.2.2 What is Black Box Testing

Testing a system in a "black box" is doing so without knowing anything about how it

operates within. A tester inputs data and monitors the output produced by the system being

tested. This allows for the identification of the system's reaction time, usability difficulties

and reliability concerns as well as how the system reacts to anticipated and unexpected user

activities.

Because it tests a system from beginning to finish, black box testing is a potent

testing method. A tester may imitate user action to check if the system fulfills its

promises, much as end users "don't care” how a system is programmed or designed

and expect to get a suitable answer to their requests.

CS366/DMIEC

A black box test assesses every important subsystem along the

route, including the UVUX, database, dependencies and integrated systems, as well
as the web server or application server.

1.2.2.1 Black Box Testing Pros and Cons

S. No Pros Cons
1 Testers do not require technical Difficult to automate.
knowledge, programming of IT skills.

2 Testers do not need to learn Requires prioritization, typically

implementation details of the system. infeasible to tests all user paths.

3 Tests can be executed by Difficult to calculate test

crowdsourced or outsourced testers. coverages.

4 Low chance of false positives. If a test fails, it can be difficult to

understand the root cause of the
issues.
5 Tests have lower complexity, since Tests may be conducted at low
they simply model common user scale or on a non-production like
behavior environment.

1.2.2.2 Types of Black Box Testing

Black box testing can be applied to three main types of tests : Functional, non-
functional and regression testing.

1. Functional testing:
Specific aspects or operations of the program that is being tested may be tested
via black box testing. For instance, make sure that the right user credentials may be
used to log in and that the incorrect ones cannot.
Functional testing might concentrate on the most important features of the
program (smoke testing/sanity testing), on how well the system works as a whole
(system testing) or non the integration of its essential components.

2. Non-functional testing:

• Beyond features and functioning, black box testing allows for the inspection
of extra software components. A non-functional test examines "how" rather
than "if" the program can carry out a certain task.
• Black box testing may determine whether software is:
CS366/DMIEC

a) Usable and simple for its users to comprehend;

b) Performant under predicted or peak loads; Compatible with relevant devices,

screen sizes, browsers or operating systems;

c) Exposed to security flaws or frequent security threats.

3. Regression testing:

To determine if a new software version displays a regression or a decrease in

capabilities, from one version to the next. black box testing may be employed.
Regression testing may be used to evaluate both functional and non-functional
features of the program, such as when a particular feature no longer functions as
anticipated in the new version or when a 8 formerly fast-performing action
becomes much slower in the new version.

1.2.2.3 Black Box Testing Techniques

1. Equivalence partitioning:

Testing professionals may organize potential inputs into "partitions" and test
just one sample input from each category. For instance, it is sufficient for testers to
verify one birth date in the "under 18" group and one date in the "over 18" group if a
system asks for a user's birth date and returns the same answer for users under the age
of 18 and a different response for users over 18.

2. Boundary value analysis:

Testers can determine if a system responds differently around a certain

boundary value. For instance, a particular field could only support values in the range
of 0 and 99.

Testing personnel may concentrate on the boundary values (1, 0, 99 and 100)
to determine if the system is appropriately accepting and rejecting inputs.

1.3 Decision Table Testing

Numerous systems provide results depending on a set of parameters. Once

rules” that are combinations of criteria have been identified, each rule's conclusion
can then be determined and test cases may then be created for each r
CS366/DMIEC

1.3.1 Differences between Black Box Testing vs White Box Testing:

Black Box Testing White Box Testing

It is a way of software testing in which the It is a way of testing the software in which
internal structure or the program or the code the tester has knowledge about the internal
is hidden and nothing is known about it. structure or the code or the program of the
software.
Implementation of code is not needed for Code implementation is necessary for white
black box testing. box testing.
It is mostly done by software testers. It is mostly done by software developers.
No knowledge of implementation is needed. Knowledge of implementation is required.

It can be referred to as outer or external It is the inner or the internal software testing.
software testing.
It is a functional test of the software. It is a structural test of the software.
This testing can be initiated based on the This type of testing of software is started after
requirement specifications document. a detail design document.
No knowledge of programming is required. It is mandatory to have knowledge of
programming.
It is the behavior testing of the software. It is the logic testing of the software.
It is applicable to the higher levels of testing It is generally applicable to the lower levels of
of software. software testing.
It is also called closed testing. It is also called as clear box testing.
It is least time consuming. It is most time consuming.
It is not suitable or preferred for algorithm
It is suitable for algorithm testing.
testing.
Can be done by trial and error ways and Data domains along with inner or internal
methods. boundaries can be better tested.
Example: Search something on google by Example: By input to check and verify loops
using keywords
Black-box test design techniques-
White-box test design techniques-
• Decision table testing
• Control flow testing
• All-pairs testing
• Data flow testing
• Equivalence partitioning
• Branch testing
• Error guessing

Types of Black Box Testing: Types of White Box Testing:

• Functional Testing • Path Testing
• Non-functional testing • Loop Testing
• Regression Testing • Condition testing
It is less exhaustive as compared to It is comparatively more exhaustive than black
white box testing. box testing.
CS366/DMIEC

1.4 Software Testing Life Cycle

A testing technique called the Software Testing Life Cycle (STLC) may
effectively help you satisfy software quality requirements. Systematic testing is
mandated by STLC and is carried out in stages. Although STLC and Software
Development Life Cycle (SDLC) are sometimes misunderstood, STLC is more
concerned with testing and SDLC is consumed with the whole development process.
Continue reading for 2 detailed analyses of STLC's six stages.

Lifecycle: What is it?

• Simply said, a lifecycle is the progression of changes from one form to

another. Any physical or intangible object is susceptible to these alterations.
Everything has a lifespan. from creation through death or retirement. Software
is a comparable example of an entity. Testing includes actions that need to be
carried out in a certain order, much as building software does.
• The testing life cycle is a phenomenon that refers to the systematic and
planned execution of testing operations.
1.4.1 What is the STLC (Software Testing Life Cycle)?

The term "Software Testing Life Cycle" refers to a testing procedure with
particular phases that must be carried out in a certain order to guarantee that the
quality objectives have been reached.

Each step of the. STLC process is completed in a planned and orderly manner.
Goals and deliverables are varied for each phase. The STLC stages vary depending
on the organization, but the fundamentals are the same.

Below are the phases of STLC:

1. Requirements phase

2. Planning phase

3. Analysis phase

4. Design phase
5. Implementation phase

6. Execution phase

7. Conclusion phase

8. Closure phase
CS366/DMIEC

1. Requirement phase: Analyses and research the requirements throughout this

phase of the smaller sub-conditions. STLC: Participate in brainstorming discussions
with other teams to see if the criteria can - Locate and collect the test data.be tested.
The scope of the testing is determined at this step. Inform the team during this -
Identify the test environment and set it up. phase if any feature cannot be tested so
that the mitigation approach may be prepared. - Develop the traceability metrics for
requirements.

2. The planning phase: Is the initial stage of the testing procedure’ in real-world -
Produce metrics for test coverage circumstances. The actions and resources that will
help us achieve the testing goals.

3. Analysis Phase: The "WHAT" to be tested is determined in this STLC step.

Basically, the satisfied before you begin your execution. Execute the test cases and in
the event of after requirements document, product hazards and other test bases are
used to determine the test discrepancy, report the faults. Fill up your traceability
metrics simultaneously to monitor circumstances. The requirement should be able to
be linked back to the test condition.

• Testing levels and depth.

• The product's complexity.
• Project- and product-related risks.
• The life cycle of software development is included.
• Test administration.
• The team's abilities and expertise.
• The stakeholder’s accessibility.
5. Implementation phase: The construction of thorough test cases is the main
undertaking identified at this phase. We also strive to determine the metrics and the
procedure for in this STLC phase. Determine the test cases’ order of importance and
which test cases will collecting and monitoring such indicators during planning. be
included in the regression suite. It is crucial to do a review to confirm the accuracy of
What is the foundation for the planning? only prerequisites? the test cases prior to
finalizing them. Don't forget to sign off on the test cases before NO, is the response.

6. Execution phase: As its name implies, this is the stage of the software testing life
cycle - Risk management and mitigation, as well as risk analysis. when actual
execution occurs.
CS366/DMIEC

7. Conclusion Phase: The exit criteria and reporting are the main topics of this
STLC phase. We need to try to accurately capture the test circumstances in writing.
You may, for instance, include the test condition "User should be able to make a
payment" for an e-commerce web application. The user should be allowed to make
payments through NEFT, debit cards and credit cards or you might specify it by
specifying it.

8. Closure phase: The following tasks are part of the closure activities:

• Verify that the test has been completed. Whether all test scenarios are run or
intentionally mitigated. Verify that no faults of severity 1 have been opened.
• Hold meetings to discuss lessons learned and produce a paper detailing
them. (Include what worked well, where changes are needed and what may
be done better.)
1.5 V-Model of Software Testing

Also known as the verification and validation model, the V-model. This
requires that each stage of the SDLC be completed before moving on to the next. The
waterfall model's sequential design approach is also followed. The device's testing is
scheduled concurrently with the relevant stage of development.
CS366/DMIEC

Verification is a static analysis technique (review) carried out without actually

running any code. To determine 7if certain criteria are met, the product development
process is evaluated.
Testing is done by running code and validation comprises dynamic analysis methods
(functional and non-functional). After the development phase is. complete, the
software is categorized through the validation step to see whether it satisfies the needs
and expectations of the client.

Therefore, the V - model features validation stages on one side and verification phases
on the other. Coding phase joins the verification and validation processes in a V-
shape. As a result, it is known as V - model.

Play video in backward skip 10s there are many stages in the V - model's verification
phase:
1. Business requirement analysis: This is the initial phase in which customer-side
product needs are understood. To fully comprehend the expectations and precise
needs of the consumer, this step involves comprehensive discussion.

2. System design: System engineers utilize the user requirements document to

analyze and comprehend the business of the proposed system at this level.

3. Architecture design: The first step in choosing an architecture is to have a solid

understanding of everything that will be included, such as the list of modules, a short

description of each module's operation, the linkages between the modules’ interfaces,

any dependencies, database tables, architectural diagrams, technological details, etc.

A certain step includes the integration testing model.
4. Module design: The system is divided into manageable modules during the
module design phase. Low-level design, which is the specification of the modules’
intricate Design.

5. Coding step: The coding step ‘is started after designing. It is determined on a
programming language that will work best based on the criteria. For coding, there are
certain rules and standards. The final build is enhanced for greater performance prior
to checking it into the repository and the code undergoes several code reviews to
verify its performance.
CS366/DMIEC

There are many stages in the V - model's validation phase:

1. Unit testing: Unit Test Plans (UTPs) are created in the V - model's module design
phase. To get rid of problems at the unit or code level, these UTPs are run. The
smallest thing that can exist on its own is a unit, such a program module. Unit testing
ensures that even the tiniest component can operate properly when separated from
other scripts or units.
2. Integration testing: During the architectural design phase, integration test plans
are created. These experiments demonstrate that separate groups may live and interact
with one another.

3. System testing: During the system design phase, plans for system tests are
created. System test plans, in contrast to unit and integration test plans, are created by
the client's business team. System testing makes ensuring that an application
developer's requirements are satisfied.

4. Acceptance testing: The examination of business requirements is connected to

acceptance testing. The software product is tested in a user environment. Acceptance
tests highlight any system compatibility issues that may exist within the user
environment. Additionally, it identifies non-functional issues like load and
performance flaws in the context of actual user interaction.

When to use V - model?

• When the requirement is well defined and not ambiguous.

• The V-shaped model should be used for small to medium-sized projects
where requirements are clearly defined and fixed.
• The V-shaped model should be chosen when sample technical resources are
available with essential technical expertise.
Advantage (Pros) of V - model:

• Easy to understand.
• Testing methods like planning, test designing happens well before coding.
• This saves a lot of time. Hence a higher chance of success over the waterfall
model
• Avoids the downward flow of the defects.
• Works well for small plans where requirements are easily understood.
CS366/DMIEC

Disadvantage (Cons) of V - model:

• Very rigid and least flexible.

• Not good for a complex project.
• Software is developed during the implementation stage, so no early
prototypes of the software are produced.
• If any changes happen in the midway, then the test documents along with the
required documents, has to be updated.

1.6 Program Correctness and Verification

One may question why we need to discuss program correctness given that this
book is about software testing. There are several causes, some of which are listed
below:

• The goal of software testing is to run the potential program on a set of input
data and determine if it acts according to- specification. Software testing
includes the study of correctness since it is only possible to analyze a
program's behavior if we are aware of what constitutes a proper behavior.
• In particular, it leads to making assumptions about the behavior of the
program at particular points in its execution and then verifying (or disproving)
these assumptions. The same assumptions can be checked at run-time during
testing, providing us with useful information as we attempt to diagnose the
program or establish its correctness. Therefore, the abilities we acquire while
we attempt to demonstrate the correctness of a program assist us to be
better/more efficient testers.
• Program testers and program providers often make kind remarks about
how testing and proving are complimentary while scrupulously ignoring one
another (and one other methodologies). Complementarity, however, is more
complex than first seems. A testing technique or a proving method is often
rendered useless not by any inherent quality of the approach but father by
being used incorrectly.
1.7 Reliability Versus Safety

The term "Software Reliability" Operational - dependability. It is defined as

a system or component's capacity to carry out its essential tasks under constant
circumstances for a certain amount of time.
CS366/DMIEC

The chance that a software system completes its assigned job in a certain
environment for a predetermined number of input instances, assuming that the
hardware and the input are error-free, is another definition of software reliability.

Software reliability, together with functionality, usability, performance,

serviceability, capability, install ability, maintainability and documentation, is a
crucial component of software quality. Software reliability is challenging to
accomplish because of how complicated software has become. System engineers
often push complexity into the software layer due to the quick increase in system size
and simplicity of doing so by updating the software, despite the fact that any system
with a high degree of complexity that contains software will be difficult to attain a
specific level of dependability.
Large next-generation aircraft, for instance, will have more than 1 million
source lines of software on board; next-generation air traffic control systems will have
between 1 and 2 million lines; the upcoming international space station will have
more than 2 million lines on board and more than 10 million lines of ground support
software; and a number of significant life-critical defense systems will have more
than 5 million source lines of software. Software complexity has an inverse
relationship with software dependability, but a direct relationship with other
important aspects of program quality, such as functionality and capacity.

1.8 Failures, Errors and Fault

1. Software failures

• Before describing the steps needed to analyses the dependability and safety of
software, it is critical to comprehend what a software failure entail. The
random or wear-related failure behavior. we see in hardware is not present in
software. As long as the same input and computer states are present, software
will always operate in the same manner.
• System failures may be brought on by software due to implementation or
design flaws. Wrong assumptions about how a system will operate, such as
the assumption that input A always comes after input B, are a common source
of design mistakes.
• Symbols that are unclear, such as ‘g' instead of 'G," are a common source of
implementation mistakes. Software flaws can only result in failures if they are
discovered while being used.
CS366/DMIEC

• Therefore, flaws in commonly used code will result in failures more often
than flaws in seldom used code, albeit both may be significant. It is especially
crucial to examine and verify seldom used code in applications that are
mission- or safety-critical.
2. What is an Error?

Error is a condition that arises when a developer or member of the

development team does not comprehend the concept of a need, and this
‘misunderstanding results in defective code.

Error is the phrase used to describe this circumstance and was mostly created
by the developers. Wrong logic, grammar or loops may produce errors that affect the
end-user experience.

• The difference between predicted and actual outcomes is used to compute it.
• It arises for a variety of causes, such as application challenges brought on by
design, code or system specification problems.
3. What’s a fault?
Sometimes due to specific conditions Tike a lack of finances or failing to take
the necessary precautions When a softwire error occurs, it signifies that the logic to
manage the application's problems was not included. Although this is a bad condition,
it often results from incorrectly specified stages or a lack of data definitions.

• It results in a warning in the program; it is an application program's

unexpected behavior.
• If a bug isn't fixed, it can prevent the deployed code from functioning properly.
• In rare circumstances, a tiny mistake might cause a high-end error.
• Adopting programming methods, development approaches, peer review and
code analysis are only a few strategies to avoid errors.
1.9 software Testing Principles

Software testing is a process that involves putting software or an application

to use in order to find faults or flaws. Following certain guidelines can help us test
software or applications without creating any problems and it will also save the test
engineers' time and effort as they put their time and effort into doing so. We will learn
about the seven fundamental tenets of software testing in this part.
CS366/DMIEC

Let us see the seven different testing principles, one by one:

• Testing shows the presence of defects.
• Exhaustive testing is not possible.
• Early testing.
• Defect clustering.
• Pesticide paradox.
• Testing is context-dependent.
• Absence of errors fallacy.

1. Testing shows the presence of defects:

• The application will be put through testing by the test engineer to ensure that
there are no bugs or flaws. We can only pinpoint the existence of problems in
the application or program when testing. The main goal of testing is to find
any flaws that might prevent the product from fulfilling the client's needs by
using a variety of methods and testing techniques. Since the entire test should
be able to be traced back to the customer requirement.
• Testing reduces the number of flaws in any program, but this does not
imply that the application is defect-free since sometimes software seems to be
bug-free despite extensive testing. But if the end-user runs into flaws that
weren't discovered during testing, it's at the point of deployment on the
production server.
CS366/DMIEC

2. Exhaustive testing is not possible:

It might often appear quite difficult to test all the modules and their features
throughout the real testing process using effective and ineffective combinations of the
input data. Therefore, because it requires endless decisions and the majority of the
hard labor is unsuccessful, extensive testing is preferred instead. As a result, we may
finish this sort of variation in accordance with the significance of the modules as
doing such testing scenarios would violate the product timeframes.

3. Early testing:
• Here, early testing refers to the idea that all testing activities should begin in
the early stages of the requirement analysis stage of the software development
life cycle in order to identify the defects. If we find the bugs at an early stage,
we can fix them right away, which could end up costing us much less than if
they are discovered in a later phase of the testing process.
• Since we will need the requirement definition papers in order to conduct
testing, if the requirements are mistakenly specified now, they may be
corrected later, perhaps during the development process.

4. Defect clustering:

• The defect clustering specified that we can identify the quantities of problems
that are associated to a limited number of modules during the testing
procedure: We have a number of explanations for this, including the
possibility of intricate modules, difficult code and more.
• According to the pareto principle, which Suggests that we may determine
that approximately, these kinds of software or applications will follow,
roughly? Twenty percent of the modules contain eighty percent of the
complexity. This allows us to locate the ambiguous modules, but it has
limitations if the same tests are. run often since they will not be able to spot
any newly introduced flaws.
5. Pesticide paradox:

• This rule said that if the same set of test cases were run again over a given
period of time, the tests would not be able to discover any new problems in
the program or application.
CS366/DMIEC

• Reviewing all the test cases periodically are crucial to overcoming these
pesticide contradictions. Additionally, in order to incorporate many
components of the application or program, new and different tests must be
created, which aids in the discovery of additional flaws.
6. Testing is context-dependent:

The testing is a context-dependent concept that asserts that a variety of

markets, including "e-commerce websites, business websites and others, are
available. Every application has its own requirements, features and functionality,
therefore there is a clear technique to test both commercial and e-commerce websites.
We will use a variety of testing methodologies, as well as numerous approaches,
techniques and procedures, to examine this sort of application.
As a result, testing is dependent on the application context. Program Inspections.
The idea that testing is context-dependent asserts that a variety of markets, including
e-commerce websites: and other commercial websites, are, available. Due to the
unique requirements, features and functioning of each application, there is a specific
approach to test both commercial and e-commerce websites. We will use a range
of testing techniques, distinct methodologies and several ways to examine this sort
of application. Testing thus relies on the application context.

Steps of inspection:
CS366/DMIEC

1. Planning: The planning phase starts when the entry criteria for the inspection state
are ‘met. A moderator verifies that the product entry criteria are met.

2. Overview: In the overview phase, a presentation is given to the inspector with some
background information needed to review the software product properly.

3. Preparation: This is considered an individual activity. In this part of the process,

the inspector collects all the materials needed for inspection, reviews that material
and notes any defects.

4. Meeting: The moderator conducts the meeting. In the meeting, the defects are
collected and reviewed.

5. Rework: The author performs this part of the process in response fo defect
disposition determined at the meeting.

6. Follow-up: In follow-up, the moderator makes the corrections and then compiles
the inspection management and defects summary report.

Characteristics of inspection:

• An experienced moderator who is not the author generally directs the

inspection. The task of the moderator is to conduct a document's peer review.
• Inspection is most formal and is guided by rules and checklists.
• Entry and exit criteria are ‘used in this evaluation procedure.
• A pre-meeting preparation is necessary.
• An inspection report is created and sent to the author so they may take the
necessary action.
• A formal follow-up procedure is utilized after an inspection to ensure that
remedial action is taken promptly and on schedule.
• The purpose of inspection is to bring in improvements to the process, not
only to find problems.
CS366/DMIEC

1.10 Stages of Testing

A software development-approach known as unit testing involves checking the

functionality of the smallest testable components or units, of an application one by
one. Unit tests are carried out by software developers and sometimes by QA
personnel. Unit testing's primary goal is to separate written code for testing to see
whether it functions as intended.

• Unit testing is a part of Test-Driven Development (TDD), a methodical

strategy that carefully constructs a product via ongoing testing and
refinement. Prior to using additional testing techniques like integration
testing, this testing approach is also the initial level of software testing.
• To make sure a unit doesn't depend on any external code or functionalities,
unit tests are often isolated. Unit tests should be run often by teams, whether
manually or more frequently automatically.

How unit tests work:

• Three steps make up a unit test: Planning, developing test cases and running
the test itself. Developers or QA experts prepare and examine the unit test in
the first stage. They then go on to writing test cases and scripts. The code is
tested in the third stage.
• ‘For test-driven development to work, unit tests must first be written that fail.
As soon as the test succeeds, they create code and restructure the application.
TDD often produces a code base that is clear and predictable.
CS366/DMIEC

• To confirm that the code has no dependencies, each test case is run
separately in an isolated environment. The software developer should utilize
a testing framework to record any failed tests and write criteria to validate
each test case.
• The creation of tests for every line of code would be time-consuming for
developers. The code that could influence how the program being created
behaves should be the focus of the tests that developers write.
• Only those properties that are essential to the operation of the unit being
evaluated are included in unit testing.
• This enables developers to make modifications to the source code without
worrying about how they could affect the operation of other components or
the program as a whole right away.
• Teams may use integration testing to assess bigger program components
after every unit in the program operates as effectively and error- free as
feasible.
• Unit tests may be run manually or automatically by developers. An intuitive
document outlining each stage in the process may be developed for those
using a manual technique, however automation testing is the most popular
approach for unit testing.
• Automated methods often create test cases using a testing framework. In
addition to presenting a summary of the test cases, these frameworks are also
configured to flag and report any failed test cases.
Unit testing advantages:

‘There are many advantages to unit testing, including the following:

• Compound mistakes happen less often the sooner an issue is discovered.

• Fixing issues as they arise is often less expensive than waiting until they
become serious, Simplified debugging procedures.
• The codebase can be modified easily by developers,
• Code ray be transferred to new projects and reused by developers.
Unit testing disadvantages:

‘While unit testing is integral to any software development and testing strategy; there
are some aspects to be aware of. Disadvantages to unit testing include the following:
CS366/DMIEC

• Not all bugs will be found during tests.

• Unit testing does not identify integration flaws; it just checks data sets and
their functionality.
• To test one line of code, more lines of test code may need to be developed,
which might require additional time.
• To successfully apply unit testing, developers may need to pick up new
skills, such as how to utilize certain automated software tools.
1.11.2 Integration Testing
What’s integration testing?
The second stage of the software testing process, after unit testing, is known as
integration testing. Integration testing is the process of inspecting various parts or
units of g software project to reveal flaws and ensure that they function as intended.

The typical software project often comprises of multiple software modules, many
of which were created by various programmers. Integration testing demonstrates to
the group how effectively these dissimilar components interact. In spite of the fact
that each component.

Why perform integration testing?

• There are many particular reasons why developers should do integration

testing, in addition to the basic reality that they must test all software programs
before making them available to the general public.
• Errors might result from incompatibility between program components.
• Every software module must be able to communicate with the database and
requirements are subject to change as a result of customer feedback. Though
if they haven't been extensively tested yet, those additional needs should be.
• Every software developer has their own conceptual framework and coding
logic. Integrity testing guarantees that these diverse elements work together
seamlessly.
• Modules often interface with third-party APIs or tools, thus we require
integration testing to confirm that the data these tools receive is accurate.
• There may be possible hardware compatibility issues.
Advantages of integration testing

• Integration testing ensures that every integrated module functions correctly.

• Integration testing uncovers interface errors.
CS366/DMIEC

• Testers can initiate integration testing once a module is completed and

doesn’t require waiting for another module to be done and ready for testing.
• Testers can detect bugs, defects and security issues.
• Integration testing provides testers with a comprehensive analysis of the
whole system, dramatically reducing the likelihood of severe connectivity
issues.
Challenges of integration testing:

Unfortunately, integration testing has some difficulties to overcome as well.

• Questions will arise about how components from two distinct systems
produced by two different suppliers will impact and interact with one another
during testing.
• Integrating new and old systems requires extensive testing and possible
revisions.
• Integration testing needs testing not just the integration connections but the
environment itself, adding another level of complexity to the process.
• This is because integration testing requires testing not only the integration
links but the environment itself.

1.11.3 System Testing

• System testing is a sort of software testing done on a whole integrated system

to determine if it complies with the necessary criteria.
• Integration testing successful components are used as input during system
testing. Integration testing's objective is to find any discrepancies between the
Integrated components.
• System testing finds flaws in the integrated modules as well as the whole
system. A component or system's observed behavior during testing is the
outcome of system testing. System testing is done on the whole system under
the guidance of either functional or system requirement specifications or
under the guidance of both.
• The design, behavior and customer expectations of the system are all tested
during system testing. Beyond the parameters specified in the Software
Requirements Specification (SRS), it is used to test the system.
CS366/DMIEC

• In essence, system testing is carried out by a testing team that is separate

from the development team and helps to objectively assess the system's
quality. It has been tested in both functional and non- functional ways. Black-
box testing is what system testing is. After integration testing but before
acceptance testing, system testing is carried out.
Process for system testing: The steps for system testing are as follows:

Setup of the test environment: Establish a test environment for higher-quality

testing.

Produce a test case: Produce a test case for the testing pes

Produce test data: Produce the data-that will be put to the test.

Execute test case: Test cases are carried out after the production of the test case
cand the test data.
Defect reporting: System flaws are discovered.

Regression testing: This technique is used to examine the consequences of the

testing procedure's side effects.
Log defects: In this stage, defects are corrected.

Retest: If the first test is unsuccessful, a second test is conducted.

Types of system testing:

Performance testing: is a sort of software testing used to evaluate the speed,

scalability, stability and dependability of software applications and products. ws
Load testing: This sort of software testing is used to ascertain how a system or
software product will behave under high loads.
Stress testing: Stress testing is a sort of software testing carried out to examine the
system's resilience under changing loads.
Advantages of system testing:

• The testers don't need to have further programming experience to do this

testing.
• "It wilts test the complete product or piece of software, allowing us to
quickly find any faults or flaws that slipped through integration and unit
testing.
• The testing environment resembles a real-world production or commercial
setting.
• It addresses the technical and business needs of customers and uses various
test scrips to verify the system's full operation.
CS366/DMIEC

•
Following this testing, the product will have practically all potential flaws or
faults fixed, allowing the development team to safely go on to acceptance
testing.
Disadvantages of system testing:

• Because this testing involves checking the complete product or piece of

software, it takes longer than other testing methods.
• Since the testing involves testing the complete piece of software, the cost
will be considerable.
• Without a proper debugging tool, the hidden faults won't be discovered.
CS366/DMIEC

TWO MARK QUESTIONS

1. What is software testing?

Software testing can be stated as the process of verifying and validating

whether a software or application is bug - free, meets the technical requirements as
guided by its design and development and meets the user requirements effectively
and. efficiently by handling all the exceptional and boundary cases.

The process of software testing aims not only at finding faults in the existing
software but also at finding measures to improve the software in terms of efficiency,
accuracy and usability. It mainly aims at measuring the specification, functionality
and performance of a software program or application.

2. What is black - box testing?

The technique of testing in which the tester doesn’t have access to the source
code of the software 4nd is conducted at the software interface without any concern
with the internal logical structure of the software is known as black - box testing.

3. What is white - box testing?

The technique of testing in which the tester is aware of the. internal

workings of the product, has access tots source code and is conducted by making
sure that all internal operations are performed according to the specifications is
known as white box testing.

4. What is V - model of software testing?

V Model in Software testing is an SDLC model where the test execution

takes place in a hierarchical manner. The execution process makes a V-shape. It is
also called a verification and validation model. that undertakes the testing process
for every development phase.

5. What are different levels of software testing?

Software level testing can be majorly classified into four levels:

1. Unit testing: A level of the software testing process where individual units /
components of a software / system are tested. The purpose is to validate that each unit
of the software performs as designed.
CS366/DMIEC

2. Integration testing: A level of the software testing process where individual units
are combined and tested as a group. The purpose of this level of testing is to expose
faults in the interaction between integrated units.
3. System testing: A level of the software testing process where a complete,
integrated system / software is tested. The purpose of this test is to evaluate the
system's compliance with the specified requirements.

4. Acceptance testing: A level of the software testing process where a system is

tested for acceptability. The purpose of this test is to evaluate the system’s
compliance. with the business requirements and assess whether it is acceptable for
delivery.

6. What is Software testing principles?

1. Testing shows presence of defects

2. Exhaustive testing is not possible

3. Early testing

4. Defect clustering

5. Pesticide paradox

6. Testing is context dependent

7. Absence of errors fallacy

7. What are different types of software testing?

Software Testing can be broadly classified into two types:

1. Manual testing: Manual testing includes testing software manually, i.e., without
using any automation tool or any script. In this type, the tester takes over the role of
an end- user and tests the software to identify any unexpected behavior or bug. There
are different stages for manual testing such as unit testing, integration testing, system
testing and user acceptance testing.

Testers use test plans, test cases, or test scenarios to test software to ensure the
completeness of testing. Manual testing also includes exploratory testing, as testers
explore the software to identify errors in it.
CS366/DMIEC

2. Automation testing: Automation testing, which is also known as test automation,

is when the tester writes scripts and uses another software to test the product. This
process involves the automation of a manual process. Automation testing is used to
re-run the test scenarios quickly and repeatedly, that were performed manually in
manual testing.

Apart from regression testing, automation testing is also used to test the
application from a load, performance and stress point of view. It increases the test
coverage, improves accuracy and saves time and money when compared to manual
testing.

8. What is system testing?

System testing is a type of software testing that is performed on a complete
integrated system to evaluate the compliance of the system with the corresponding
requirements. In system testing, integration testing passed components are taken as
input. The goal of integration testing. is to detect any irregularity between the units
that are integrated together. System testing detects defects within both the integrated
units and the whole system. The result of system testing is the observed behavior of
a component or a system when it is tested.

9. What is integration testing?

Integration testing is the second level of the software testing process comes
after unit testing. In this testing, units or individual components of the software are
tested in a group. The focus of the integration testing level is to expose defects at
the time of interaction between integrated components or units.

10. Define Software Engineering?

Software Engineering is a discipline that produces error free software with in a time
and budget.

11. D e f in e s oftw are Tes t in g?

Testing can be described as a process used for revealing defects in software, and for
establishing that the software has attained a specified degree of quality with respect
to selected attributes.
CS366/DMIEC

12) Why do we need software testing?

• Preventing bugs,
• Cost-effective
• Product-Quality
• Security
13 ) D i f f e ren t i ate b e tw ee n ver i f i ca t i o n an d val id a t i on ? ( U . Q
Nov/ D e c 200 9 )?

Verification Validation
1.Verification is the process 1.
of evaluating s o f t w a r e s y s t e m o r Verification is the process of evaluating
component to determine whether the software system or component during
products of a given development phase or at the end of the, the development
satisfy the conditions imposed at the phase satisfies the conditions imposed
start of that phase. at the start of that phase.
2.Verification is usually associated 2.Verification is usually associated
with activities such as inspections and with Traditional execution _based
reviews of the s/w deliverables. testing, i.e. Exercising the code with
testcases.

14. Define the term Testing?

• Testing is generally described as a group of procedures carried out to

evaluate some aspect of a piece of software.
• Testing can be described as a process used for
r e v e a l i n g d e f e c t s i n software, and for establishing that the software
has attained a specified degree of quality with respect to selected attributes.

15. Differentiate between testing and debugging?

Testing Debugging
1.Testing as a dual-purpose process 1.Debugging or fault localization is the
Reveal defects and to evaluate quality process of Locating the fault or defect
attributes Repairing the code, and Retesting the
code.
CS366/DMIEC

16. List the members of the critical groups in a testing process?

• Manager
• Developer/Tester
• User/Client
17. Define Error?
An error is mistake or misconception or misunderstanding on the part of a
software developer.
18. Define Faults (Defects)?
A fault is introduced into the software as the result of an error. It is an anomaly
in the software that may cause nit to behave incorrectly, and not according to its
specification.

19. Define failures?

A failure is the inability of a software or component to perform its required
functions within specified performance requirements.

20. Distinguish between fault and failure. (U.Q May/June 2009)?

FAULT FAILURE
1. A fault is introduced i nt o the 2. A f a i l u r e is t h e inability of a
software as the result of an error. It is software or component to perform its
an anomaly in the software that may required functions within specified
cause nit to behave incorrectly, and not performance requirements.
according to its specification.

21. Define Test Cases?

• A test case in a practical sense is attest related item which contains the
following information.
• A set of test inputs. These are data items received from an external source by
the code under test.
• The external source can be hardware, software, or human. Execution
conditions. These are conditions required for running the test, for example, a
certain state of a database, or a configuration of a hardware device. Expected
outputs. These are the specified results to be produced by the code under test.
CS366/DMIEC

22. Write short notes on Test, Test Set, and Test Suite?

• A Test is a group of related test cases, or a group of related test cases and
test procedure.
• A group of related tests is sometimes referred to as a test.
• A group of related tests that are associated with a database, and are usually
run together, is sometimes referred to as a test.

23. Define Test Bed?

A test bed is an environment that contains all the hardware and software
needed to test a software component or a software system.

24. Define Software Reliability?

Software Reliability is defined as the probability of failure-free software

operation for a specified period of time in a specified environment.

25. Define Software Safety?

Software Safety is defined as the probability of mishap-free software

operation for a specified period of time in a specified environment.

26. What is program Inspection?

A code inspection is a set of procedures and error-detection techniques for group

code reading. Most discussions of code inspections focus on the procedures, forms
to be filled out.

27. Define coupling?

The coupling is the measure of the degree of interdependence between units.

Two units with high coupling are strongly connected and thus, dependent on each
other.
CS366/DMIEC

28. Compare Black-Box and White Box Testing?

Black-Box Testing White Box Testing
Black box testing, the tester is no The White box approach focuses on
Knowledge of its inner structure (i.e. the inner structure of the software to
how it works) The tester only has be tested. Black box approach is
knowledge of what it does (Focus only usually applied large size piece of
input & output) The White box approach software. White box approach is
focuses on the inner structure of the usually applied small size piece of
software to be tested. software.
Black box approach is usually applied Black box testing sometimes called
large size piece of software. White box functional or specification testing. White
approach is usually applied small size piece box sometimes called clear or glass box
of software. Black box testing sometimes testing
called functional or specification testing.

29. What is System Testing?

A system is defined as a combination of the software, hardware and other
associated parts that together provide product features and solutions. System
testing ensures that each system function works as expected and it also tests for
non-functional requirements like performance, security, reliability, stress, load,
etc.

Part- B & C
1. S t a t e and expl ai n S oftw a r e t es t i ng p r i n c i p l e s ?

2. Explain in detail the tester’s role in a software development organization?

3. Explain in detail Black-Box and White-box Testing?

4. Illustrate with an example the following Black-Box testing Techniques.

i) Boundary Value Analysis

ii. Equivalence Partitioning

5. Explain in detail about V-Model of Software Testing?

6. Explain in detail about Software Testing Life cycle?

7.Expl ai n about various s t ages of T e s t i n g ?
8.Illustrate with an example the following White-Box testing Techniques?