Software Quality Assurance

and Testing

Gabriel Kapumpe
School of Computing, Technology and Applied Sciences
ZCAS University
2025

Examining the Specification

i.Examining the Specification

Today, we are looking at:
1. Black-Box Testing and White-Box Testing
2. Static and Dynamic Testing
3. Static Black-Box Testing: Testing the Specification
a) High Level Review of the Specifications
b) Low Level Specification Techniques

1
 BLACK BOX TESTING
1. This approach tests all possible combinations of
end-user actions.
2. Black box testing assumes no knowledge of code and
is intended to simulate the end-user experience.
3. The tester can use sample applications to integrate
and test the application block for black box testing.
4. Planning for black box testing immediately after the
requirements and the functional specifications are
available.
5. Black box testing should be conducted in a test
environment close to the target environment.

WHITE BOX TESTING

1. This is also known as glass box, clear box, and open
box testing.
2. In white box testing, test cases are created by
looking at the code to detect any potential failure
scenarios.
3. The suitable input data for testing various APIs and
the special code paths that need to be tested by
analyzing the source code for the application block.
4. Therefore, the test plans need to be updated before
starting white box testing and only after a stable
build of the code is available.

WHITE BOX TESTING…cntd’

5. White box testing assumes that the tester can take a look at the
code for the application block and create test cases that look for
any potential failure scenarios.
6. During white box testing, analyze the code of the application
block and prepare test cases for testing the functionality to
ensure that the class is behaving in accordance with the
specifications and testing for robustness.

2
 Static and Dynamic testing
1. Dynamic testing is testing that is performed when the system is running.
2. The basic requirement is to review test plans.
3. Recommend tests based on the hazard analyses, safety standards and
checklists, previous accident and incidents, operator task analyses etc.
4. Specify the conditions under which the test will be conducted.
5. Review the test results for any safety-related problems that were missed in
the analysis or in any other testing.
6. Ensure that the testing feedback is integrated into the safety reviews and
analyses that will be used in design modifications
7. Static testing is performed when the system is not running.
8. Static testing works with peer review, and mostly referred to as pen and
pencil run.

Static black box testing: - Testing the specification

1. Testing the specification is static black-box testing.

2. The specification is a document, not an executing program, so it’s
considered static.
3. It’s also something that was created using data from many
sources—usability studies, focus groups, marketing input, e.t.c
4. It is not necessarily to know how or why that information was
obtained or the details of the process used to obtain it, just that
it’s been boiled down into a product specification.
5. Tester can then take that document, perform static black-box
testing, and carefully examine it for bugs.

a) Performing a High-Level Review of the Specification

1. The first step is to stand back and view it from a high level.
Examine the specifications for large fundamental problems,
oversights, and omissions.
2. It is important to do research before testing, but ultimately the
research is a means to better understand what the software should
do and leads to the better understanding of the product on which
testing is to be performed.
3. For performing the high level review the guidelines are for
pretending to be a customer, research existing guidelines and
review the similar test cases.

3
 b) Low-Level Specification Test Techniques

After you complete the high-level review of the product specification the
testing of the low level specification is done.
• Specification Attributes Checklist
A good, well-thought-out product specification has eight important attributes:
• Complete: -Is anything missing or forgotten? Is it thorough? Does it include everything
necessary to make it stand alone?
• Accurate: -Is the proposed solution correct? Does it properly define the goal? Are there
any errors?
• Precise, Unambiguous, and Clear: -Is the description exact and not vague? Is there a
single interpretation? Is it easy to read and understandable?
• Consistent: -Is the description of the feature written so that it doesn’t conflict with itself
or other items in the specification?
• Relevant: -Is the statement necessary to specify the feature? Is it extra information that
should be left out? Is the feature traceable to an original customer need?

Low-Level Specification Test Techniques..cntd’

• Feasible: -Can the feature be implemented with the available

personnel, tools, and resources within the specified budget and
schedule?
• Code-free: -.Does the specification stick with defining the
product and not the underlying software design, architecture,
and code?
• Testable: -Can the feature be tested? Is enough information
provided that a tester could create tests to verify its operation?

Testing the Software with Blinders On

4
 Testing the Software with Blinders On

• 1. Dynamic Black-Box Testing

• 2. Data Testing
• 3. State Testing

Dynamic Black-Box Testing

a) Testing the Software while Blindfolded
1. Testing software without having an insight into the details of underlying
code is dynamic black-box testing.
2. It’s dynamic because the program is running and testing is done
simultaneously using it as a customer would. And, it’s black-box because
you’re testing it without knowing exactly how it works—with blinders on.
3. The inputs are entered, and receiving outputs and checking the results
are tabulated.
4. Another name commonly used for dynamic black-box testing is behavioral
testing because you’re testing how the software actually behaves when
it’s used.

Dynamic Black-Box Testing

b) Test-to-Pass and Test-to-Fail
There are two fundamental approaches to testing software test-to-pass and
test-to-fail.
1. When you test-to-pass, you really assure only that the software
minimally works and as a software tester it is the first positive approach.
2. Don’t push its capabilities; don’t see what you can do to break it. Test
the software by applying the simplest and most straightforward test
cases.
3. The software should be tested for it to work under the best ideal
condition.
4. During test to fail, the software should be tested for the boundary
conditions on its various limits.

5
 c) Equivalence Partitioning
1. Type of black box testing that divides the input domain of the program
into classes of data from which the test cases can be divided.
2. This method is typically used to reduce the total number of test cases to
a finite set of testable test cases, still covering maximum requirements.
3. It is the process of taking all possible test cases and placing them into
classes. One test value is picked from each class while testing.

For example:
If you are testing for an input box accepting numbers from 1 to 1000 then
there is no use in writing thousand test cases for all 1000 valid input numbers
plus other test cases for invalid data.

2. Data Testing
The simplest view of software is to divide its world into two parts:
The data and The program.
• The data is the keyboard input, mouse clicks, disk files, printouts, and
so on.
• The program is the executable flow, transitions, logic, and computations.

When software testing is performed on the data, the user information is

checked and the data is tabulated with the expected results.

For Example:
•The words you type into a word processor
•The numbers entered into a spreadsheet

6
 BREAKFAST
28th February, 2025

BREAKFAST
Question 1: Explain black box testing and white box testing
Question 2: Explain static testing and dynamic testing
Question 3: Explain testing specification in static testing
Question 4: Explain performance a high level review of
specification static testing
Question 5: Explain the concept of testing the software
blindfolded in dynamic black box testing