SE Quality Management1 PDF
SE Quality Management1 PDF
SE Quality Management1 PDF
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.
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.
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.
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.
Validation on the other hand ensures that the right product is built i.e. that the product fulfills its
intended purpose.
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:
Integration Testing
This is sometimes called string testing. Here, components are brought together to interact and this
interaction of components is tested against specification.
2. Bottom up 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.
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