SE Quality Management1 PDF

Download as pdf or txt
Download as pdf or txt
You are on page 1of 5

Software Testing

The stage at which software testing happens depends solely on the process model used. In case of
waterfall model, testing happens immediately after implementation whereas in other process model,
testing happens during requirement gathering/ elicitation, design and implementation. But regardless of
the process model used, testing principles are the same.

Related Terms in Software Testing

1. Defect: This simply means there is a deficiency in work product. Where the work product does
not meet its requirement/ specification.
2. Fault: This is a defect in source code. It can be an incorrect step, process, or data definition in a
program. Bug is a common term within a software engineering team. Fault is the formal
definition of a bug. Fault and bug can be used interchangeably.
3. Failure: This is an event where system or system component does not perform a required
function within specified limit. Failures are caused by fault.

From these definitions, the only thing that testing reveals is failure i.e. an undesired effect in system’s
service but it is the faults that must be repaired.

Define Software Testing

Software testing is a process that checks that the result the system developed produces == expected
result stated in the requirement document. If this is true, you say the system is defect free.

Software Testing Life Cycle (STLC)


Software Testing Life Cycle (STLC) is a sequence of specific test activities
conducted during the testing process to ensure software quality goals are met.
STLC involves both verification and validation activities. Contrary to popular
belief, Software Testing is not just a single/isolate activity, i.e. testing. It
consists of a series of activities carried out methodologically to help certify
your software product. STLC stands for Software Testing Life Cycle.

Testing requires planning which is regarded as a test plan. A test plan is a document that guides the
entire testing effort on scope, deliverable, roles and responsibilities, tools, testing method, activities,
schedules, success criteria, risk assessment etc.

Test scenario is a summarized description of what to test in a particular use case rather than how to test
it.

Test Cases is as a result of single test scenario. Test cases are detailed step by step description of
sequence for achieving a test scenario outcome. It includes sequence of testing steps, preconditions,
input data, expected output, actual output and post conditions. The Table 1 below gives an insight of
what a test case looks like for a flight reservation system.
Table 1: This is a test case for a flight reservation use case

Test scripts: There are different opinions of what a test script is.

Opinion 1: A test script is a run of test case generated by a specific data. In the flight reservation use
case, this could be a run of test cases generated by using the same username and password.

Opinion 2: Test scripts are seen as automation scripts. That is that test scripts are used to automate the
run of test cases and then interpreted by automation tools. VBScript is an example of scripting language
used to automate test cases.

V-Shaped Model
This is a software process model just like waterfall, agile and other software process models. It is more
of a variation of waterfall model with emphasis on testing to not be considered after but during and
through requirements to coding. The V stands for verification and validation. Since this is a variation of
the waterfall model where each phase has to end before the next phase begins. In the v-shaped model
the only addition is that each phase goes through certain tests to verify and validate before going to the
next phase then after the coding phase these tests are performed in reverse order. Figure 1 below gives
an illustration of how the V-shaped model works.
Figure 1: The V shaped model

Verification vs Validation

Verification is an attempt to ensure that the product is built correctly. Verification also ensures that the
output of an activity meets the specification imposed by previous activities. Therefore, verification
checks that the product conforms with the requirements and design specification.

Verification answers the question “Are we building the product right?”

Verification happens at development phase.

Validation on the other hand ensures that the right product is built i.e. that the product fulfills its
intended purpose.

Validation answers the question “Are we building the right product?”

Validation happens at testing phase.

Software Testing Levels

Unit Testing/ Component Testing/ Module Testing

This is the process of testing individual components in the system. This process involves verifying that
each unit meets its specification according to the specification document. This is a defect testing process
so its goal is to expose faults in these components. Unit testing is usually considered as a coding practice
rather than a testing practice because as soon as source code blocks needs to be tested a unit test is
written. For most systems, the developers of components are responsible for component testing.
Component testing by developers is usually based on an intuitive understanding of how the components
should operate.
There are different types of component that may be tested at this stage such as:

1. Individual functions or methods within an object

2. Object classes that have several attributes and methods

3. Composite components made up of several different objects or functions.

Integration Testing
This is sometimes called string testing. Here, components are brought together to interact and this
interaction of components is tested against specification.

Strategies for integration testing are:

1. Top down approach

2. Bottom up approach

3. Combined (Sandwich approach)

System Testing

This is where the complete and integrated system is tested to evaluate the system’s compliance with the
requirement specified. Non- functional requirements such as security and performance are tested.

Acceptance Testing

This is also called the pilot testing. It involves formal testing where users say if a system would be
accepted or not.

Software Test Techniques/ Methods.


Different test techniques can be used to detect failures, some of which are:
1. Specification based testing/ Functional Testing/ Conformance /Black box/ Closed- box
Testing:
This involves that act of examining software against specifications without examining code details. Some
techniques used here are:

a. Equivalence Partitioning: This technique divides input data into set of equivalence classes, this
could be based on the criteria of data that must be accepted/ rejected and then a set of test
cases for each class is designed. Since each set of test cases is designed for the same class of
data that means any defect found in one test case will likely be found in other cases of the same
set. This would therefore maximize the testing coverage with minimum number of test cases.
b. Boundary Value Analysis: This can be seen as another form of equivalence partitioning but only
test the system on and near the input domain boundaries.
c. Robustness Testing: This is an extension of boundary value analysis where test cases are chosen
outside the input domain to test the program against unexpected inputs.
2. Code based Testing/ Structural Testing/ White-box/ Open-box Testing:
This involves examining the internal code and some techniques used here are:
a. Control Flow: This technique checks all the statement and/or statement block by
representing the control flow of a program by a notation/ flow graph which illustrates
sequence, conditions and loop statements. This would then test all paths or selected paths
and statements
b. Data flow: This annotates the flow graph with information about variables definition, usages
and disposition by looking for risky patterns and design tests accordingly.
Testing Objectives
Any testing activity can be associated with any of the objectives mentioned below:
1. Performance testing: This is to verify that the software meets performance requirements
under expected load. Examples are throughput and latency.
2. Stress Testing: This tests a system beyond expected load by attempting to break the system to
identify its limit under certain resources.
3. Recovery Testing: This verifies if the system can recover from disaster either automatically or
manually.
4. Configuration Testing: This verifies all supported hardware and software configurations.
5. Usability Testing: This evaluates how users can use/operate the system.
6. Alpha testing: For trials, but internally.
7. Beta Testing: For trials, but externally

You might also like