Unit 1

Q. What is Software Testing?

Software testing is the process of evaluating and verifying that a software product
or application does what it is supposed to do. The benefits of testing include
preventing bugs, reducing development costs and improving performance.

Testing includes an examination of code and also the execution of code in various
environments, conditions as well as all the examining aspects of the code. In the
current scenario of software development, a testing team may be separate from
the development team so that Information derived from testing can be used to
correct the process of software development.

Software testing provides an independent view and objective of the software and
gives surety of fitness of the software. It involves testing of all components under
the required services to confirm that whether it is satisfying the specified
requirements or not. The process is also providing the client with information
about the quality of the software.

Software testing isn’t a single thing. Instead, it comes in many different

variations, which you can categorize according to several criteria. For instance,
you can categorize testing types into manual or automated testing. When it comes
to the automated variety, tests can be code-based or codeless and you can also
have hybrid approaches that mix the best of both worlds. Tests can also be
categorized regarding how much they know about the internal implementation of
the system under test. Regarding this criteria, we can classify tests as white-box,
black-box or grey-box. Finally, we can also group tests into functional and non-
functional tests, depending on whether they validate the business requirements
for the application.
Q. Explain Software Engineering Activity.

A software engineering activity is a group of related tasks in software

development. Each activity has input work products and output work products.
Think of an activity like a factory machine. Input work products go in and output
work products are the result.

Testing as an Engineering Activity

This is an exciting time to be a software developer. Software systems are

becoming more challenging to build. They are playing an increasingly important
role in society. People with software development skills are in demand. New
methods, techniques, and tools are becoming available to support development
and maintenance tasks. Because software now has such an important role in our
lives both economically and socially, there is pressure for software professionals
to focus on quality issues. Poor quality software that can cause loss of life or
property is no longer acceptable to society. Failures can result in major losses.
Conditions demand software development staffs with interest and training in the
areas of software product and process quality. Highly qualified staff ensure that
software products are built on time, within budget, and are of the highest quality
with respect to attributes such as reliability, correctness, usability, and the ability
to meet all user requirements. Using an engineering approach to software
development implies that:

1. The development process is well understood.

2. Projects are planned.
3. Life cycle models are defined.
4. Standards are in place for product and process.
5. Measurements are employed to evaluate product and process quality.
6. Components are reused.
7. Validation and verification processes play a key role in quality
determination.
8. Engineers have proper education, training, and certification.
Q. Explain Testing as a Process and Testing Axioms.

Starting the test process without a plan is not a good idea to achieve the goal.
So, the first and foremost process in software testing is test planning and
control.

Good testing is based on the good test plan that we have prepared. Once the design
process is completed, test implementation and execution activity should take
place for better test coverage. Exit criteria is evaluated to conclude the testing. It
varies from project to project. Better Implementation of the test plan drives us to
success. Test planning and control involves the following activities,

• Define test strategy and approach.

• Define the scope of testing
• Identify the objectives and risk associated with the testing
• Plan resources, test environments and workstations etc.
• State all assumptions and conditions
• Identify the test tasks
• Identify test tools
• Plan testing budget
• Plan tests for specific testing like (System testing, Performance testing etc.)
• Schedule time for test analysis, design, implementation, and closure process.
 Q. What is Testing Axioms (The Realities of
Software Testing)?

Axioms means a rule or principle that most people believe to be true so the
following are testing axioms in software testing.
1. It is impossible to test a program completely.

2. Software testing is a risk-based exercise.

3. Testing cannot show the absence of bugs.

4. The more bugs you find, the more bugs there are.

5. Not all bugs found will be fixed.

6. It is difficult to say when a bug is indeed a bug.

7. Specifications are never final.

8. Software testers are not the most popular members of a project.

9. Software testing is a disciplined and technical profession.

Axiom 1: It is impossible to test a program completely

• How many test cases do you need to exhaustively test: – PowerPoint – A

calculator – MS Word – Any interesting software!
• The only way to be absolutely sure software works is to run it against all possible
inputs and observe all of its outputs
• The number of possible inputs is very large.
• The number of possible outputs is very large.
• The number of paths through the software is very large
Axiom 2: Software testing is a risk-based exercise

If you do not test the software for all inputs (a wise choice) you take a risk.

• Hopefully you will skip a lot of inputs that work correctly.

• What if you skip inputs that cause a fault? Risk: financial loss, security, loss of
money, loss of life! That is a lot of pressure for a tester! Software testing is a risk-
based exercise

• If you try to test too much, the development cost becomes prohibitive.

• If you test too little, the probability of software failure increases and as we
discussed, software failures can cost us big time!

Axiom 3: Testing cannot show the absence of bugs

• Program testing can be used to show the presence of bugs, but never to show
their absence!

Axiom 4: The more bugs you find, the more bugs there are

• Bugs appear in groups, where you see one you will likely find more,

• Why? Programmers can have bad days Programmers tend to make the same
mistakes some bugs are just the tip of the iceberg.

Axiom 5: not all bugs found will be fixed

Why wouldn’t you fix a bug you knew about? There’s not enough time, it’s not
really a bug

• Specifications can be wrong, it’s just not worth it

• Bugs in fringe features may have to wait

• Why not charge the customer for bug fixes in the next release (sound familiar?)
Axiom 6: It is difficult to say when a bug is indeed a bug
• If there is a problem in the software but no one ever discovers it, is it a bug?
Parody of “if a tree falls in the forest does it really make a noise?”

• Bugs that are undiscovered are called latent bugs.

Axiom 7: Specifications are never final

Building a product based on a “moving target” specification is fairly unique to

software development.

Fig: Testing axioms

Axiom 8: Software Testers are Not the Most Popular Members in a
Project

Do’s of a tester:

• Finding bugs in the software

• Finding the bugs correctly and in the less time
• Make sure that all bugs can be fixed as early as possible.
• Don’ts of a tester:
• Don't post the bad news to the developing team earlier
• Make sure to double check even though you can't find if you can inform
them.
• Act like a professional to other team members
• Control your enthusiasm if you are a tester

Axioms 9: Software Testing is Somewhat Disciplined and

Technical Profession
Reasons:

• We can say that it is a disciplined activity because it goes through

step by step procedure
• If we miss one step we may get the test errors
• We can say it is a technical profession because we are using

I. sophisticated tools
II. advanced technologies
III. rewarding career growth

• if software is simple and more manageable software testers are

untrained, we can't find bugs in the software
• If we put millions of money on the team we couldn't get a single test
error in it.
Q. What is Basic principles of software testing?

Software testing is a procedure of implementing software or the application to

identify the defects or bugs. For testing an application or software, we need to
follow some principles to make our product defects free, and that also helps the
test engineers to test the software with their effort and time. Here, in this section,
we are going to learn about the seven essential principles of software testing.

1. Testing shows the presence of defects

By doing testing on any application, we can decrease the number of bugs, which
does not mean that the application is defect-free because sometimes the software
seems to be bug-free while performing multiple types of testing on it. But at the
time of deployment in the production server, if the end-user encounters those bugs
which are not found in the testing process.
2. Exhaustive Testing is not possible

Sometimes it seems to be very hard to test all the modules and their features with
effective and non- effective combinations of the inputs data throughout the actual
testing process. Hence, instead of performing the exhaustive testing as it takes
boundless determinations and most of the hard work is unsuccessful. So we can
complete this type of variations according to the importance of the modules
because the product timelines will not permit us to perform such type of testing
scenarios.

3. Early Testing

Here early testing means that all the testing activities should start in the early
stages of the software development life cycle's requirement analysis stage to
identify the defects because if we find the bugs at an early stage, it will be fixed
in the initial stage itself, which may cost us very less as compared to those which
are identified in the future phase of the testing process.

4. Defect clustering

The defect clustering defined that throughout the testing process, we can detect
the numbers of bugs which are correlated to a small number of modules. We have
various reasons for this, such as the modules could be complicated; the coding
part may be complex, and so on.

5. Pesticide paradox (Concepts)

This principle defined that if we are executing the same set of test cases again and
again over a particular time, then these kinds of the test will not be able to find
the new bugs in the software or the application. To get over these pesticide
paradoxes, it is very significant to review all the test cases frequently. And the
new and different tests are necessary to be written for the implementation of
multiple parts of the application or the software, which helps us to find more bugs.

6. Testing is context-dependent

Testing is a context-dependent principle states that we have multiple fields such

as e-commerce websites, commercial websites, and so on are available in the
market. There is a definite way to test the commercial site as well as the e-
commerce websites because every application has its own needs, features, and
functionality. To check this type of application, we will take the help of various
kinds of testing, different technique, approaches, and multiple methods.
Therefore, the testing depends on the context of the application.

The chance when the application is tested beside the incorrect requirements,
identified the flaws, and fixed them on a given period would not help as testing
is done on the wrong specification, which does not apply to the client's
requirements. The absence of error fallacy means identifying and fixing the bugs
would not help if the application is impractical and not able to accomplish the
client's requirements and needs.

Q. Explain the Tester role in software development organization

The tester’s job is to

1. Reveal defects,
2. Find weak points,
3. Inconsistent behaviour,
4. Circumstances where the software does not work as expected.

It is difficult for developers to effectively test their own code. A tester needs very
good programming experience in order to understand how code is constructed,
and to know where and what types of, defects could occur.

A tester should work with the developers to produce high-quality software that
meets the customers’ requirements.

Teams of testers and developers are very common in industry, and projects should
have a correct developer/tester ratio. The ratio will vary depending on

1. Available resources
2. Type of project,
3. TMM level (Testing maturity model)
4. Nature of the project
5. Project Schedules

A testers also need to work with requirements engineers to make sure that
requirements are testable, and to plan for system and acceptance test. Testers also
need to work with designers to plan for integration and unit test. Test
managers need to cooperate with project managers in order to develop reasonable
test plans, and with upper management to provide input for the development and
maintenance of organizational

1. Testing standards
2. Polices
3. Goals

Testers also need to cooperate with software quality assurance staff and software
engineering process group members. Testers are a part of the development group.
They concentrate on testing. They may be part of the software quality assurance
group. Testers are specialists, their main function is to plan, execute, record, and
analyse tests. They do not debug software. When defects are detected during
testing, software should be returned to the developers.

The developers locate the defect and repair the code. The developers have a
detailed understanding of the code, and they can perform debugging better.
Testers need the support of management. Testers ensure that developers release
code with few or no defects, and that marketers can deliver software that satisfies
the customers’ requirements, and is reliable, usable, and correct.

Q. What is Origins of Defects and Cost of defects?

The term defect and its relationship to the terms error and failure in the context
of the software development domain. Defects have detrimental effects on
software users, and software engineers work very hard to produce high-quality
software with a low number of defects. But even under the best of development
circumstances errors are made, resulting in defects being injected in the software
during the phases of the software life cycle. Defects as shown in figure stem from
the following sources.

Education: The software engineer did not have the proper educational
background to prepare the software artifact. She did not understand how to do
something. For example, a software engineer who did not understand the
precedence order of operators in a particular programming language could inject
a defect in an equation that uses the operators for a calculation.

Communication: The software engineer was not informed about something by

a colleague. For example, if engineer 1 and engineer 2 are working on interfacing
modules, and engineer 1 does not inform engineer 2 that a no error checking code
will appear in the interfacing module he is developing, engineer 2 might make an
incorrect assumption relating to the presence/absence of an error check, and a
defect will result.

Transcription: The software engineer knows what to do, but makes a mistake in
doing it. A simple example is a variable name being misspelled when entering
the code.

Process: The process used by the software engineer misdirected her actions. For
example, a development process that did not allow sufficient time for a detailed
specification to be developed and reviewed could lead to specification defects.
Q. Explain Cost of Defects?

The cost of defects can be measured by the impact of the defects

and when we find them. Earlier the defect is found lesser is the cost of
defect. For example if error is found in the requirement specifications
during requirements gathering and analysis, then it is somewhat cheap
to fix it. The correction to the requirement specification can be done
and then it can be re-issued.

In the same way when defect or error is found in the design during
design review then the design can be corrected and it can be re-issued.
But if the error is not caught in the specifications and is not found till
the user acceptance then the cost to fix those errors or defects will be
way too expensive.

If the error is made and the consequent defect is detected in

the requirements phase then it is relatively cheap to fix it.

Fig: Cost of Defects

Cost per Test is a cost accounting module. It calculates the cost of reagents,
supplies, tester, equipment and indirect costs associated with a test procedure to
produce a Cost per Billable Test. Cost accounting is an accounting process that
measures all of the costs associated with production, including both fixed and
variable costs. The purpose of cost accounting is to assist management in
decision-making processes that optimize operations based on efficient cost
management.

Q. Explain the types of defects.

Types of Defects: Following are some of the basic types of defects in the
software development:
1. Arithmetic Defects: It include the defects made by the developer in some
arithmetic expression or mistake in finding solution of such arithmetic
expression. This type of defects are basically made by the programmer due
to access work or less knowledge. Code congestion may also lead to the
arithmetic defects as programmer is unable to properly watch the written
code.
2. Logical Defects: Logical defects are mistakes done regarding the
implementation of the code. When the programmer doesn’t understand the
problem clearly or thinks in a wrong way then such types of defects happen.
Also while implementing the code if the programmer doesn’t take care of the
corner cases then logical defects happen. It is basically related to the core of
the software.
3. Syntax Defects: Syntax defects means mistake in the writing style of the
code. It also focuses on the small mistake made by developer while writing
the code. Often the developers do the syntax defects as there might be some
small symbols escaped. For example, while writing a code in C++ there is
possibility that a semicolon (;) is escaped.
4. Multithreading Defects: Multithreading means running or executing the
multiple tasks at the same time. Hence in multithreading process there is
possibility of the complex debugging. In multithreading processes
sometimes there is condition of the deadlock and the starvation is created
that may lead to system’s failure.
5. Interface Defects: Interface defects means the defects in the interaction of
the software and the users. The system may suffer different kinds of the
interface testing in the forms of the complicated interface, unclear interface
or the platform based interface.
6. Performance Defects: Performance defects are the defects when the
system or the software application is unable to meet the desired and the
expected results. When the system or the software application doesn’t fulfil
the user’s requirements then that is the performance defects. It also includes
the response of the system with the varying load on the system.
7. Software error: A software error occurs during the development of the
software. This error can be in the form of a grammatical error, a logical error
where the outcome of a sequence of executions will not result in what was
intended or a misinterpretation of the user requirements in the actual written
code. It may be in the form of user documentation not matching the software
applications operation. An error may or may not be
detected during the coding or testing of the program before it is released to a
customer.
8. Software Fault: A software fault occurs as a result of an error that remains
in the executing program. Not all faults however are detected and the
software may continue executing without any obvious problems. There are
cases where software faults go undetected for many years of a programs
existence.
9. Software Failure: A software failure is a fault that results in a detectable
problem; hence it is referred to as a failure. A failure would cause the
application to malfunction in an obvious manner that warrants the attention
of system maintenance.

Q. Explain Defects classes in detailed?

Software Defect is some kind of error, flaw or some kind of mistake from
the development team which prevent the software from the smooth
working. It directly affect software quality, software quality is something
how smooth and reliable your software is. Smoothness and reliability is
how less defects your software have.
Categories of defects:
Categories of defects are: Errors of commissions, Errors of omissions,
Errors of clarity, and Error of speed and capacity.
These are explained as following below.
1. Error of Commission:
Commission means instruction or some kind of command given. Now
the error in commission means the error in made in command or
instruction. For example, suppose I wrote a loop which I was trying to
run 10 times but I command it to run more than 10 times by mistake
this is the error of commission.

2. Errors of Omissions:
As name is already describing error of omission is something which
happens accidentally. Omission word means something left out or
executed. Practical most common example of this error is suppose we
make a function in programming open its bracket but forget to close at
the end.

3. Error of Clarity:
The most common error in the natural languages. This error happens
due to miss understanding between the developer and client. It travels
most of the time from the requirements to the software.

4. Error of Speed or Capacity:

The name of the error is itself enough I think to tell about it this error.
Your software is working fine but not working in the required time
this is the error of speed. When it comes to capacity it can be relevant
to memory. For example, a small integer is declared where the long
integer was required.
Q. Explain the Defect Repository in detailed.

Fig: Defect repository table

Defects can be classified in many ways. It is important for an organization

to follow a single classification scheme and apply it to all projects.

Some defects will fit into more than one class or category. Because of this
problem, developers, testers, and SQA staff should try to be as consistent as
possible when recording defect data.

The defect types and frequency of occurrence should be used in test

planning, and test design. Execution-based testing strategies should be
selected that have the strongest possibility of detecting particular types of
defects. The four classes of defects are as follows,

• Requirements and specifications defects

• Design defects
• Code defects
• Testing defects
Defect Repository to increase the effectiveness of their testing and
debugging processes, software organizations need to initiate the creation of
a defect database, or defect repository. The defect repository supports
storage and retrieval of defect data from all projects in a centrally accessible
location.

Requirements and specifications defects

1. Functional Description Defects

The overall description of what the product does, and how it should behave
(inputs/outputs), is incorrect, ambiguous, and/or incomplete.

2. Feature Defects
Features refer to functional aspects of the software that map to functional
requirements as described by the users and clients. Features also map to quality
requirements such as performance and reliability. Feature defects are due to
feature descriptions that are missing, incorrect, incomplete, or superfluous.

3. Feature Interaction Defects

These are due to an incorrect description of how the features should interact. For
example, suppose one feature of a software system supports adding a new
customer to a customer database. This feature interacts with another feature that
categorizes the new customer. The classification feature impacts on where the
storage algorithm places the new customer in the database, and also affects
another feature that periodically supports sending advertising information to
customers in a specific category. When testing us certainly want to focus on the
interactions between these features.
4. Interface Description Defects
These are defects that occur in the description of how the target software is to
interface with external software, hardware, and users. For detecting many
functional description defects, black box testing techniques, which are based on
functional specifications of the software, offer the best approach. In Chapter 4 the
reader will be introduced to several black box testing techniques such as
equivalence class partitioning, boundary value analysis, state transition testing,
and cause-and-effect graphing, which are useful for detecting functional types of
detects. Random testing and error guessing are also useful for detecting these
types of defects. The reader should note that many of these types of defects can
be detected early in the life cycle by software reviews. Black box-based tests can
be planned at the unit, integration, system, and acceptance levels to detect
requirements/specification defects. Many feature interaction and interfaces
description defects are detected using black box-based test designs at the
integration and system levels.

2. Design Defects
Design defects occur when system components, interactions between system
components, interactions between the components and outside software
/hardware, or users are incorrectly designed. This covers defects in the design of
algorithms, control, logic, data elements, module interface descriptions, and
external software/hardware/user interface descriptions.
When describing these defects we assume that the detailed design description for
the software modules is at the pseudo code level with processing steps, data
structures, input/output parameters, and major control structures defined. If
module design is not described in such detail then many of the defects types
described here may be moved into the coding defects class.

1. Algorithmic and Processing Defects

These occur when the processing steps in the algorithm as described by the
pseudo code are incorrect. For example, the pseudo code may contain a
calculation that is incorrectly specified, or the processing steps in the algorithm
written in the pseudo code language may not be in the correct order. In the latter
case a step may be missing or a step may be duplicated.
Another example of a defect in this subclass is the omission of error condition
checks such as division by zero. In the case of algorithm reuse, a designer may
have selected an inappropriate algorithm for this problem (it may not work for all
cases).
2. Control, Logic, and Sequence Defects
Control defects occur when logic flow in the pseudo code is not correct. For
example, branching too soon, branching to late, or use of an incorrect branching
condition. Other examples in this subclass are unreachable pseudo code elements,
improper nesting, improper procedure or function calls. Logic defects usually
relate to incorrect use of logic operators, such as less than (<) greater than (>),
etc. These may be used incorrectly in a Boolean expression controlling a
branching instruction. These are associated with incorrect design of data
structures. For example, a record may be lacking a field, an incorrect type is
assigned to a variable or a field in a record, an array may not have the proper
number of elements assigned, or storage space may be allocated incorrectly.
Software reviews and use of a data dictionary work well to reveal these types of
defects.

3. Coding Defects
Coding defects are derived from errors in implementing the code. Coding defects
classes are closely related to design defect classes especially if pseudo code has
been used for detailed design. Some coding defects come from a failure to
understand programming language constructs, and miscommunication with the
designers. Others may have transcription or omission origins. At times it may be
difficult to classify a defect as a design or as a coding defect. It is best to make a
choice and be consistent when the same defect arises again.
1. Algorithmic and Processing Defects
Adding levels of programming detail to design, code-related algorithmic and
processing defects would now include unchecked overflow and underflow
conditions, comparing inappropriate data types, converting one data type to
another, incorrect ordering of arithmetic operators (perhaps due to
misunderstanding of the precedence of operators), misuse or omission of
parentheses, precision loss, and incorrect use of signs.

2. Control, Logic and Sequence Defects

On the coding level these would include incorrect expression of case statements,
incorrect iteration of loops (loop boundary problems), and missing paths.
3. Typographical Defects
These are principally syntax errors, for example, incorrect spelling of a variable
name that are usually detected by a compiler self-reviews, or peer reviews.
4. Initialization Defects
These occur when initialization statements are omitted or are incorrect. This may
occur because of misunderstandings or lack of communication between
programmers, and/or programmers and designers, carelessness, or
misunderstanding of the programming environment.
4. Testing Defects
Defects are not confined to code and its related artifacts. Test plans, test cases,
test harnesses, and test procedures can also contain defects. Defects in test plans
are best detected using review techniques.

1. Test Harness Defects

In order to test software, especially at the unit and integration levels, auxiliary
code must be developed. This is called the test harness or scaffolding code. The
test harness code should be carefully designed, implemented, and tested since it
a work product and much of this code can be reused when new releases of the
software are developed. Test harnesses are subject to the same types of code and
design defects that can be found in all other types of software.

2. Test Case Design and Test Procedure Defects

These would encompass incorrect, incomplete, missing, inappropriate test cases,
and test procedures. These defects are again best detected in test plan reviews
sometimes the defects are revealed during the testing process itself by means of
a careful analysis of test conditions and test results. Repairs will then have to be
made.

Q. What is Defect prevention strategies?

Defect Prevention (DP) is a strategy applied to the software development life
cycle that identifies root causes of defects and prevents them from recurring. It is
the essence of Total Quality Management (TQM). It is basically defined as a
measure to ensure that defects being detected so far, should not appear or occur
again. For facilitating communication simply among members of team, planning
and devising defect prevention guidelines, etc., Coordinator is mainly
responsible.
Coordinator is mainly responsible to lead defect prevention efforts, to facilitate
meetings, to facilitate communication between team members and management,
etc. DP board generally has quarterly plan in which sets some goals at
organization level. To achieve these goals, various methods or activities are
generally used and carried out to achieve and complete these goals.

Strategies/Methods of Defect Prevention

For defect prevention, there are different methods that are generally used
over a long period of time. These methods or activities are given below:

• Software Requirement Analysis

The main cause of defects in software products is due to error in
software requirements and designs. Software requirements and design
both are important, and should be analysed in an efficient way with
more focus. Software requirement is basically considered an integral
part of Software Development Life Cycle (SDLC). These are the
requirements that basically describes features and functionalities of target
 product and also conveys expectations or requirement of users from
software product.
Therefore, it is very much needed to understand about software
requirements more carefully, If requirements are not understood well
by tester and developers, then there might be chance of occurring of
issue or defect in further process. Therefore, it is essential to analyse
and evaluate requirements in more appropriate and proper manner.
• Review and inspection
Review and inspection, both are essential and integral part of software
development. They are considered as powerful tools that can be used to
identify and remove defects if present before there occurrence and
impact on production. Review and inspection come in different levels
or stages of defect prevention to meet different needs. They are used in
all software development and maintenance methods. There are two
types of review i.e. self-review and peer-review.
• Defect Logging and Documentation:
After successful analysis and review, there should be records
maintained about defects to simply complete description of defect.
This record can be further used to have better understanding of
defects. After getting knowledge and understanding of defect, then
only one can take some effective and required measures and actions to
resolve particular defects so that defect cannot be carried further to
next phase.
• Root Cause Analysis:
Root cause analysis is basically analysis of main cause of defect. It
simply analysis what triggered defect to occur. After analysing main
cause of defect, one can find best way to simply avoid occurrence of
such types of defects next time.
In software testing, defect resolution is a step-by-step procedure for
resolving issues. The defect resolution process begins with the test manager
assigning defects to developers, who then schedule the defect to be resolved
according to priority. Defects are then fixed, and developers deliver a
resolution report to the test manager. This method makes it simple to correct
and track issues.
Q. Explain the Advantages of software testing.

1. Customer Satisfaction

The prime goal of any service-based organization is to serve the best

features and experience to their customers, customer satisfaction is the
only goal for the success and popularity of an application. Software testing
helps in building the trust and satisfaction of the customer by assuring a
defect-free application. UI testing enhances customer satisfaction.
Software Testing tries to uncover all possible defects and test an
application as per customer requirements. For example, e-commerce is
dependent on the customer, and a satisfied customer will improve its
market value and earnings.

2. Cost Effective
If an application works without any fault and with low maintenance will
save a big amount for the owner. Software testing helps in early defect
detection and fixing them to make a more successful and good return
application. Every application demands maintenance and the application
owner spends a good amount to maintain the working and functionality of
the application. By testing an application, the maintenance area reduces
too many folds and hence saves money. Software testing helps in saving
the money of the developing organization by detecting defects in the early
stages of the software which becomes easy and economical for the
developer to redesign the module instead of detecting bugs after the
complete development of the software.
3. Quality Product
The main focus of software testing is to deliver a quality product to its
clients which results in a satisfied client. The quality of a product can only
be maintained when it is bug-free and meet all the user requirements.

To meet the product qualities, if an application works with other related

applications then it must undergo compatibility testing.
During software testing, an application undergoes several testing
techniques to make a quality end product and the testing team tries their
best by writing test cases and test scenarios to validate defect-free free
applications.
4. Low Failure
Failure of an application impacts its working and brand value. Software
testing helps in knowing the cases where a particular application is most
likely to fail. For example, an e-commerce application is more likely to fail
when there is heavy traffic and load. This type of application goes through
stress testing to check the highest possible limit of the application to handle
the load. Software testing makes an application more robust and reliable.

5. Bug-Free Application

The main task of software testing is to identify bugs and inform them the
concerned developing team to fix. When a bug is fixed, testers recheck the
bug to identify its status. A bug-free application means an application with
no glitches, faults, or defects and works effectively and smoothly. The only
demand of an application is that it functions as per requirements and does
not behave unusually due to defects. A 100% bug-free application is
practically not possible but the testing team tries to identify as many as
possible bugs in the application by creating test scenarios. Software testing
follows the STLC process to detect a bug.

6. Security
The main concern of the digital world is Security. A secure system always
remains on the priority list of customers. Owners pay multiple dollars to
make their systems secure from hackers, malicious attacks, and other
thefts. Security testing technique is used to identify the security level of
the application and testers try to find loopholes to break the security of an
application. In the case of bank applications, security is the foremost
requirement as it deals with customer money, and bank applications always
remain on top of the thefts.

7. Easy Recovery

Recovery means when an application fails it restarts functioning as usual

by consuming less time. An application is successful when it recovers very
quickly and performs its normal functions. Software testing helps in
identifying the recovery rate of an application with the total time it is using
to recover. During testing, testers test an application to identify case
scenarios where any application is mostly likely to fail and how much time
it is taking to recover. Testers inform the development team and developers
make changes in the internal coding to make the fast recovery of an
application.
Q. Explain the Test Design techniques.

Fig: Test design techniques

Software Testing Design Techniques help you design better test cases. Since
exhaustive testing is not possible; Manual Testing Techniques help reduce
the number of test cases to be executed while increasing test coverage. They
help identify test conditions that are otherwise difficult to recognize.

• Boundary Value Analysis (BVA)

Boundary value analysis is based on testing at the boundaries between

partitions. It includes maximum, minimum, inside or outside boundaries,
typical values and error values.

It is generally seen that a large number of errors occur at the boundaries of

the defined input values rather than the centre. It is also known as BVA and
gives a selection of test cases which exercise bounding values.

This black box testing technique complements equivalence partitioning.

This software testing technique base on the principle that, if a system works
well for these particular values then it will work perfectly well for all values
which comes between the two boundary values.

• Equivalence Class Partitioning

Equivalent Class Partitioning allows you to divide set of test condition into
a partition which should be considered the same. This software testing
method divides the input domain of a program into classes of data from
which test cases should be designed.

The concept behind this Test Case Design Technique is that test case of a
representative value of each class is equal to a test of any other value of the
same class. It allows you to identify valid as well as invalid equivalence
classes.

• Decision Table Based Testing

A decision table is also known as to Cause-Effect table. This software
testing technique is used for functions which respond to a combination of
inputs or events. For example, a submit button should be enabled if the user
has entered all required fields.

The first task is to identify functionalities where the output depends on a

combination of inputs. If there are large input set of combinations, then
divide it into smaller subsets which are helpful for managing a decision
table.

For every function, you need to create a table and list down all types of
combinations of inputs and its respective outputs. This helps to identify a
condition that is overlooked by the tester.

• Error Guessing
Error Guessing is a software testing technique based on guessing the error
which can prevail in the code. The technique is heavily based on the
experience where the test analysts use their experience to guess the
problematic part of the testing application. Hence, the test analysts must be
skilled and experienced for better error guessing.
The technique counts a list of possible errors or error-prone situations. Then
tester writes a test case to expose those errors. To design test cases based on
this software testing technique, the analyst can use the past experiences to
identify the conditions.

**************************