CCS366 SOFTWARE TESTING AND AUTOMATION LTPC202 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
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
1. Yogesh Singh, “Software Testing”, Cambridge University Press,
2012
2. Unmesh Gundecha, Satya Avasarala, "Selenium
WebDriver 3 Practical Guide" - Second Edition 2018
REFERENCES
1. Glenford J. Myers, Corey Sandler, Tom Badgett, The Art of
Software Testing, 3rd Edition, 2012, John Wiley & Sons, Inc.
2. Ron Patton, Software testing, 2nd Edition, 2006, Sams Publishing
3. Paul C. Jorgensen, Software Testing: A Craftsman’s Approach,
Fourth Edition, 2014, Taylor & Francis Group.
4. Carl Cocchiaro, Selenium Framework Design in Data-Driven
Testing, 2018, Packt Publishing.
5. Elfriede Dustin, Thom Garrett, Bernie Gaurf, Implementing
Automated Software Testing, 2009, Pearson Education, Inc.
6. Satya Avasarala, Selenium WebDriver Practical Guide, 2014, Packt
Publishing.
7. Varun Menon, TestNg Beginner's Guide, 2013, Packt Publishing.

CO’s PO’s PSO’s

1 2 3 4 5 6 7 8 9 10 11 12 1 2 3
1 3 3 2 1 2 - - - 1 1 3 2 3 2 3
2 2 3 1 1 1 - - - 2 2 1 2 1 2 3
3 2 2 1 3 1 - - - 1 3 1 2 2 3 2
4 2 1 3 2 1 - - - 1 1 1 2 3 1 2
5 2 2 1 3 1 - - - 1 3 2 1 2 1 3
AVg. 2.2 2.2 1.6 2 1.2 - - - 1.2 2 1.6 1.8 2.2 1.8 2.6
CO’s-PO’s & PSO’s MAPPING
1 - low, 2 - medium, 3 - high, ‘-' - no correlation

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 Veri昀椀cation, 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.

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 behaviour 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 softwaré 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
programme 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. .
➢ 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 their
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.

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.

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

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

programme (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 programme can carry out a certain task.
• Black box testing may determine whether software is:

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 programme, 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 rule.

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 It is a way of testing the software in
the internal structure or the program or which the tester has knowledge about the
the code is hidden and nothing is known internal structure or the code or the
about it. program of the software.
Implementation of code is not needed for Code implementation is necessary for
black box testing. white box testing.
It is mostly done by software testers. It is mostly done by software developers.
No knowledge of implementation is Knowledge of implementation is
needed. required.
It can be referred to as outer or external It is the inner or the internal software
software testing. 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
requirement specifications document. after a detail design document.
No knowledge of programming is It is mandatory to have knowledge of
required. 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 It is generally applicable to the lower
testing of software. levels of 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
It is suitable for algorithm testing.
algorithm 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 Example: By input to check and verify
by using keywords loops
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:

 Black Box Testing White Box Testing

• Functional Testing • Path Testing

• Non-functional testing • Loop Testing
• Regression Testing • Condition testing

It is less exhaustive as compared to white It is comparatively more exhaustive than

box testing. black box testing.

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 analysis 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 vary 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
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.
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 leamed 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.

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

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 programme 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 programme 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
programme 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 programme or establish its correctness. Therefore, the
abilities we acquire while we attempt to demonstrate the correctness of a
programme assist us to be better/more efficient testers. :
• Programme testers and programme 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.
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, installability, 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 programme 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. 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 programme; it is an application program's
unexpected
• behaviour.
• 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.
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 programme 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 amount of flaws in any programme, 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.

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 labour 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 programme or application.
• Reviewing all the test. cases periodically is crucial to overcoming these
pesticide contradictions. Additionally, in order to incorporate many
components of the application or programme, 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

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.
1.11 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.
• To confirm that the code has no dependencies, each test case is run
separately in an isolated environment. The software developer should utilise
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 programme 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 effect the operation of other components or
the programme as a whole right away.
• Teams may use integration testing to assess bigger programme components
after every unit in the programme 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:
• 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
programmes before making them available to the general public.
• Errors might result from incompatibility between programme 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.
• 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.
• 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.
• 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.

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

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

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 into the 2. A failure is the 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.

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 test 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. Compare Black-Box and White Box Testing?

Black Box Testing White Box Testing

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

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

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 ex pl 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 . Ex pl ai n about vari ous s t ages of Tes t i ng?
8.Illustrate with an example the following White-Box testing Techniques?