What is testing?

1. Zuliar Efendi
Program Studi S1 Sistem Informasi
Fakultas Sains dan Teknologi
Universitas Islam Negeri Sultan Syarif Kasim Riau

2. Let's use an analogy to help us: driving tests.
 In a driving test, the examiner critically assesses the candidate's driving, noting
every mistake, large or small, made by the driver under test.
 The examiner takes the driver through a route which tests many possible driving
activities, such as road junctions of different types, control and maneuvering of the
car, ability to stop safely in an emergency, and awareness of the road, other road
users and hazards. Some of the activities must be tested.
 For example, in the UK, an emergency stop test is always carried out, with the
examiner simulating the moment of emergency by hitting the dashboard at which
point the driver must stop the car quickly, safely and without loss of control.

3.  At the end of the test, the examiner makes a judgment about the driver's
performance. Has the driver passed the test or failed? The examiner
bases the judgment on the number and severity of the failures identified,
and also whether the driver has been able to meet the driving
requirements.
 A single severe fault is enough to fail the whole test, but a small number
of minor faults might still mean the test is passed. Many minor faults
would reduce the confidence of the examiner in the quality
Cont…

4.  Process – Testing is a process rather than a single activity – there are a series of
activities involved.
 All life cycle activities – the thought process of designing tests early in the life cycle
can help to prevent defects from being introduced into code. We sometimes refer to
this as 'verifying the test basis via the test design'. The test basis includes documents
such as the requirements and design specifications.
 Both static and dynamic – tests where the software code is executed to demonstrate
the results of running tests (often called dynamic testing) we can also test and find
defects without exe cuting code. This is called static testing. This testing includes
reviewing of documents (including source code) and static analysis. This is a useful and
cost effective way of testing.

5.  Planning – Activities take place before and after test execution. We need to manage the
testing; for example, we plan what we want to do; we control the test activities; we report on
testing progress and the status of the software under test; and we finalize or close testing
when a phase completes.
 Preparation – We need to choose what testing we'll do, by selecting test con ditions and
designing test cases.
 Evaluation – As well as executing the tests, we must check the results and evaluate the
software under test and the completion criteria, which help us decide whether we have
finished testing and whether the software product has passed the tests.
 Software products and related work products – We don't just test code. We test the
requirements and design specifications, and we test related documents such as operation,
user and training material. Static and dynamic testing are both needed to cover the range of
products we need to test.
Cont…

6.  Planning and preparation - Both the examiner and the tester need a plan of action and need
to prepare for the test, which is not exhaustive, but is repre sentative and allows risk-based
decisions about the outcome.
 Static and dynamic - Both dynamic (driving the car or executing the software) and static
(questions to the driver or a review of the software) tests are useful.
 Evaluation - The examiner and the tester must make an objective evaluation, log the test
outcome and report factual observations about the test.
 Determine that they satisfy specified requirements – The examiner and tester both check
against requirements to carry out particular tasks successfully.
 Demonstrate that they are fit for purpose - The examiner and the tester are not evaluating for
perfection but for meeting sufficient of the attributes required to pass the test.
 Detect defects - The examiner and tester both look for and log faults.

7. Testing Principle - Early testing
Testing activities should start as early as possible in the software or system development life cycle
and should be focused on defined objectives.
We can use both dynamic testing and static testing as a means for achieving similar test
objectives. Both provide information to improve both the system to be tested, and the
development and testing processes. We mentioned above that testing can have different goals
and objectives, which often include:
• finding defects;
• gaining confidence in and providing information about the level of quality;
• preventing defects.

8. A main focus of reviews and other static tests is to carry out testing as early
as possible, finding and fixing defects more cheaply and preventing defects
from appearing at later stages of this project. These activities help us find
out about defects earlier and identify potential clusters. Additionally, an
important outcome of all testing is information that assists in risk assess-
ment; these reviews will contribute to the planning for the tests executed
later in the software development life cycle. We might also carry out root
cause analysis to prevent defects and failures happening again and perhaps
to identify the cause of clusters and potential future clusters.

9. Testing Principle - Pesticide paradox
If the same tests are repeated over and over again, eventually the same set
of test cases will no longer find any new bugs. To overcome this 'pesticide
paradox', the test cases need to be regularly reviewed and revised, and
new and different tests need to be written to exercise different parts of the
software or system to potentially find more defects.

10. When a test finds a defect that must be fixed, a programmer must do some work to locate the
defect in the code and make the fix. In this process, called debugging, a programmer will examine
the code for the immediate cause of the problem, repair the code and check that the code now
executes as expected. The fix is often then tested separately (e.g. by an independent tester) to
confirm the fix. Notice that testing and debugging are different activities. Developers may test their
own fixes, in which case the very tight cycle of identifying faults,
debugging, and retesting is often loosely referred
to as debugging. However, often following the
debugging cycle the fixed code is tested
independently both to retest the fix itself and to
apply regression testing to the surrounding
unchanged software.

11. Testing Principle - Testing shows presence of defects
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, it is not a
proof of correctness.
If we don't find defects does that mean the users will
accept the software?
Testing Principle - Absence of errors fallacy
Finding and fixing defects does not help if the system
built is unusable and does not fulfill the users' needs
and expectations.

12. Graham et.al (2006)

13. http://sif.uin-suska.ac.id/ http://fst.uin-suska.ac.id/
http://www.uin-suska.ac.id/
Visit