Software Testing and Process

1. Software Testing
and Process..
BY GOURAV KALBALIA
1

2. Various types of testing in a
Software..
 Testing Concepts
 Testing Process
 Black-Box Testing
 White-Box Testing
 Metrics Testing
2

3. Testing Concepts…
 Error, Fault and Failure
 Test Case, Test Suite and Test Harness
 Psychology of Testing
 Level of Testing
3

4.  Error refers to the discrepancy between a computed value and
the true, or theoretically correct value.
 It is the difference between the actual output of a software and
the correct output.
 Error is also used to refer to human action that results in software
containing a defect or fault
4

5.  Fault is a condition that causes a system to fail in performing its required
function.
 A fault is the basic reason for software malfunction and is practically
synonymous with the commonly used term bug, or the somewhat more
general term defect.
 Failure is the inability of a system or component to perform a required
function according to its specifications.
 A software failure occurs if the behaviour of the software is different from
the specified behaviour.
 Failures may be caused by functional or performance factors.
5

6.  Presence of an error (in the state) implies that a failure must have
occurred, and the observance of a failure implies that a fault
must be present in the system.
 However, the presence of a fault does not imply that a failure
must occur. The presence of a fault in a system only implies that
the fault has a potential to cause a failure.
6

7. Test Case, Test Suite, and Test
Harness
 A test case (often called a test) can be considered as comprising a
set of test inputs and execution conditions, which are designed to
exercise the SUT(software under testing) in a particular manner.
 A test case also specifies the expected outcome from executing
the SUT under the specified execution conditions and test inputs.
 A testing framework is also sometimes called a test harness. A test
harness or a test framework makes the life of a tester simpler by
providing easy means of defining a test suite, executing it, and
reporting the results.
7

8.  There is another level of testing, called regression testing.
 It is performed when some changes are made to an
existing system.
 Besides ensuring the desired behaviour of the new services,
testing has to ensure that the desired behaviour of the old
services is maintained.
 Complete regression testing of large systems can take a
considerable amount of time, even if automation is used.
8

9. Psychology of Testing
 There are a number of heuristics and rules of thumb for deciding the
test cases, selecting test cases is still a creative activity that relies on
the ingenuity of the tester.
 Because of this, the psychology of the person performing the
testing becomes important
9

10. Levels of Testing
 Testing detect the faults
remaining from earlier stages, in
addition to the faults introduced
during coding itself.
 At each level of testing aims to
test different aspects of the
system.
 The basic levels are attempt to
detect different types of faults.
10

11.  The first level of testing is called unit
testing, it is essentially for verification of
the code produced by individual
programmers.
 Then next level of testing is called
integration testing. Many unit tested
modules are combined into subsystems,
which are then tested.
 The goal here is to see if the modules
can be integrated properly.
11

12.  In System testing and acceptance testing
the entire software system is tested.
 The goal is to see if the software meets its
requirements.
 This is often a large exercise, which for
large projects may last many weeks or
months.
 Acceptance testing is often performed
with realistic data of the client to
demonstrate that the software is working
satisfactorily.
 Acceptance testing tests if the system
satisfactorily solves the problems for which
it was commissioned.
12

13. Testing Process…
 Testing is a quality control activity which focuses on identifying
defects (which are then removed).
 For each software unit testing, the test cases will have to be
designed and then executed. Overall, testing in a project is a
complex task which also consumes the maximum effort.
Hence, testing has to be done properly in a project
 The testing process for a project consists of three high-level
tasks—
 Test planning,
 Test case design,
 Test execution.
13

14.  Test case design is a major activity in the testing process. Careful
selection of test cases that satisfy the criterion and approach
specified is essential for proper testing
 Another reason for specifying the test cases in a document or a
script is that by doing this, the tester can see the testing of the unit in
totality and the effect of the total set of test cases. This type of
evaluation is hard to do in on-the-fly testing where test cases are
determined as testing proceeds. It also allows optimizing the number
of test cases as evaluation of the test suite may show that some test
cases are redundant
14

15.  In a project, testing commences with a test plan and terminates with
successful execution of acceptance testing.
 A test plan is a general document for the entire project that defines the
scope, approach to be taken, and the schedule of testing, as well as
identifies the test items for testing and the personnel responsible for the
different activities of testing.
 The test planning can be done well before the actual testing commences
and can be done in parallel with the coding and design activities. The inputs
for forming the test plan are:
 Project plan,
 Requirements document
 Architecture or design document.
 A test plan should contain the following:
 Test unit specification – Features to be tested – Approach for testing – Test
deliverables – Schedule and task allocation
15

16. Test Plan and Design
 The test plan focuses on how the
testing for the project will proceed,
which units will be tested, and what
approaches (and tools) are to be
used during the various stages of
testing.
 Test case design has to be done
separately for each unit. Based on
the approach specified in the test
plan, and the features to be tested,
the test cases are designed and
specified for testing the unit.
 In a round of testing, the outcome
of all the test cases is recorded (i.e.,
pass or fail).
16

17. Test Case Execution
 With the specification of test cases, the next step in the testing process is to
execute them
 Executing the test cases may require construction of driver modules or stubs. It
may also require modules to set up the environment as stated in the test plan
and test case specifications. Only after all these are ready can the test cases be
executed.
 During test case execution, defects are found. These defects are then fixed and
tesing is done again to verify the fix. To facilitate reporting and tracking of
defects found during testing (and other quality control activities), defects found
are often logged.
 During test case execution, defects are found. These defects are then fixed and
tesing is done again to verify the fix. To facilitate reporting and tracking of
defects found during testing (and other quality control activities), defects found
are often logged.
 Defect logging and tracking is considered one of the best practices for
managing a project , and is followed by most software organizations.
17

18.  There are some good reasons why test cases are specified before
they are used for testing. It is known that testing has severe
limitations and the effectiveness of testing depends very heavily on
the exact nature of the test cases. It is therefore important to ensure
that the set of test cases used is of high quality.
 a formal document or work product is needed, for review of test
cases, the test case specification document is required. This is the
primary reason for documenting the test cases.
18

19.  A defect can be found by anyone
at anytime. When a defect is
found, it is logged in a defect
control system, along with
sufficient information about the
defect.
 The defect is then in the state
“submitted,”
 Now The assigned person does the
debugging and fixes the reported
defect.
 Then defect enters the “fixed”
state. However, a defect that is
fixed is still not considered as fully
done.
19

20.  The successful fixing of the defect is verified.
This verification may be done by another
person (often the submitter), or by a test
team, and typically involves running some
tests.
 Once the defect fixing is verified, then the
defect can be marked as “closed.” In other
words, the general life cycle of a defect has
three states—submitted, fixed, and closed, A
defect that is not closed is also called open.
 Besides using the log for tracking defects, the
data in the log can also be used for analysis
purposes
20

21.  The successful fixing of the defect is
verified. This verification may be done by
another person (often the submitter), or
by a test team, and typically involves
running some tests. Once the defect
fixing is verified, then the defect can be
marked as “closed.”
 In other words, the general life cycle of a
defect has three states—submitted,
fixed, and closed, A defect that is not
closed is also called open.
 Besides using the log for tracking
defects, the data in the log can also be
used for analysis purposes
21

22. Thank You
22