0% found this document useful (0 votes)
136 views

Software Testing Is A Way To Assess The Quality of The Software and To Reduce The Risk of Software Failure in Operation

Software testing is a process used to evaluate software quality and reduce failure risks. It involves various activities beyond just test execution, like planning, design, and reporting. Testing checks if requirements are met and if the system meets user needs. The ultimate goal is to find defects, improve quality, and provide information for stakeholders to assess risk and make decisions. Exhaustive testing is impossible, so risk analysis is used to focus testing efforts. Early testing saves time and money by finding defects sooner.

Uploaded by

Nikita Sushir
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
136 views

Software Testing Is A Way To Assess The Quality of The Software and To Reduce The Risk of Software Failure in Operation

Software testing is a process used to evaluate software quality and reduce failure risks. It involves various activities beyond just test execution, like planning, design, and reporting. Testing checks if requirements are met and if the system meets user needs. The ultimate goal is to find defects, improve quality, and provide information for stakeholders to assess risk and make decisions. Exhaustive testing is impossible, so risk analysis is used to focus testing efforts. Early testing saves time and money by finding defects sooner.

Uploaded by

Nikita Sushir
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 4

1. What is Testing?

Software systems are an integral part of life, from business applications (e.g., banking) to consumer products
(e.g., cars).
Most people have had an experience with software that did not work as expected. Software that does not work
correctly can lead to many problems, including loss of money, time, or business reputation, and even injury or
death.
Software testing is a way to assess the quality of the software and to reduce the risk of software failure
in operation.
A common misperception of testing is that it only consists of running tests, i.e., executing the software and
checking the results.
● Software testing is a process which includes many different activities; test execution (including checking
of results) is only one of these activities.
The test process also includes activities such as test planning, analyzing, designing, and implementing tests,
reporting test progress and results, and evaluating the quality of a test object.
● Dynamic testing:
Some testing does involve the execution of the component or system being tested; such testing is called
dynamic testing.
● Static testing:
Other testing does not involve the execution of the component or system being tested; such testing is
called static testing.

So, testing also includes reviewing work products such as requirements, user stories, and source code.
Another common misperception of testing is that it focuses entirely on verification of requirements, user stories,
or other specifications.
While testing does involve checking whether the system meets specified requirements, it also involves
validation, which is checking whether the system will meet user and other stakeholder needs in its operational
environment(s).

Typical Objectives of Testing For any given project, the objectives of testing may include:
● To prevent defects by evaluate work products such as requirements, user stories, design, and code (To
evaluate work product )
● To verify whether all specified requirements have been fulfilled
● To check whether the test object is complete and validate if it works as the users and other stakeholders
expect
● To build confidence in the level of quality of the test object
● To find defects and failures thus reduce the level of risk of inadequate software quality
● To provide sufficient information to stakeholders to allow them to make informed decisions, especially
regarding the level of quality of the test object
● To comply with contractual, legal, or regulatory requirements or standards, and/or to verify the test
object’s compliance with such requirements or standards

Seven Testing Principles:


A number of testing principles have been suggested over the past 50 years and offer general guidelines
common for all testing.
1. Testing shows the presence of defects, not their absence:
Testing can show that defects are present, but cannot prove that there are no defects. Testing reduces
the probability of undiscovered defects remaining in the software but, even if no defects are found,
testing is not a proof of correctness.
2. Exhaustive testing is impossible :
Testing everything (all combinations of inputs and preconditions) is not feasible except for trivial cases.
Rather than attempting to test exhaustively, risk analysis, test techniques, and priorities should be used
to focus test efforts.
3. Early testing saves time and money :
To find defects early, both static and dynamic test activities should be started as early as possible in the
software development lifecycle. Early testing is sometimes referred to as shift left. Testing early in the
software development life cycle helps reduce or eliminate costly changes (see section 3.1).
4. Defects cluster together :
A small number of modules usually contains most of the defects discovered during pre-release testing,
or is responsible for most of the operational failures. Predicted defect clusters, and the actual observed
defect clusters in test or operation, are an important input into a risk analysis used to focus the test effort
(as mentioned in principle 2).
5. Beware of the pesticide paradox(IMP)
If the same tests are repeated over and over again, eventually these tests no longer find any new
defects. To detect new defects, existing tests and test data may need changing, and new tests may
need to be written. (Tests are no longer effective at finding defects, just as pesticides are no longer
effective at killing insects after a while.) In some cases, such as automated regression testing, the
pesticide paradox has a beneficial outcome, which is the relatively low number of regression defects.
6. Testing is context dependent :
Testing is done differently in different contexts. For example, safety-critical industrial control software is
tested differently from an e-commerce mobile app. As another example, testing in an Agile project is
done differently than testing in a sequential software development lifecycle project (see section 2.1).
7. Absence-of-errors is a fallacy:
Some organizations expect that testers can run all possible tests and find all possible defects, but
principles 2 and 1, respectively, tell us that this is impossible. Further, it is a fallacy (i.e., a mistaken
belief) to expect that just finding and fixing a large number of defects will ensure the success of a
system. For example, thoroughly testing all specified requirements and fixing all defects found could still
produce a system that is difficult to use, that does not fulfill the users’ needs and expectations, or that is
inferior compared to other competing systems.

Test Process :
There is no one universal software test process, but there are common sets of test activities without
which testing will be less likely to achieve its established objectives. These sets of test activities are a
test process.
The proper, specific software test process in any given situation depends on many factors. Which test
activities are involved in this test process, how these activities are implemented, and when these
activities occur may be discussed in an organization’s test strategy.
Test Process in Context Contextual factors that influence the test process for an organization, include,
but are not limited to:
Software development lifecycle model and project methodologies being used
Test levels and test types being considered
Product and project risks Business domain
Operational constraints, including but not limited to:
o Budgets and resources
o Timescales
o Complexity
o Contractual and regulatory requirements
Organizational policies and practices
Required internal and external standards
The following sections describe general aspects of organizational test processes in terms of the following:
● Test activities and tasks
● Test work products
● Traceability between the test basis and test work products
It is very useful if the test basis (for any level or type of testing that is being considered) has measurable
coverage criteria defined. The coverage criteria can act effectively as key performance indicators (KPIs)
to drive the activities that demonstrate achievement of software test objectives (see section 1.1.1).
For example, for a mobile application, the test basis may include a list of requirements and a list of
supported mobile devices. Each requirement is an element of the test basis. Each supported device is
also an element of the test basis. The coverage criteria may require at least one test case for each
element of the test basis. Once executed, the results of these tests tell stakeholders whether specified
requirements are fulfilled and whether failures were observed on supported devices.

You might also like

pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy