Scribd
Upload
3 views

Software Testing & Quality - Wk10

Uploaded by

moayyadsmra
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
3 views

Software Testing & Quality - Wk10

Uploaded by

moayyadsmra
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 19

Click to edit Master title style

Software Testing & Quality


U s a b i l i t y ( U s e r ) Te s t

1
Click to edit Master title style

Usability (User) Test

2 2
Data Gathering
Click to Methods
edit Master title style

• Think-aloud protocol: users speaking aloud their


thoughts and observations while they are performing
the assigned software testing tasks.
• Remote user testing: the application is installed at the
testing user’s business where the software may
ultimately be applied.
• Both methods can be combined with posttest
questionnaires or interviews.
• Eye tracking: to show which visual elements attract
the observer’s attention by tracking how long an
observer pauses on certain visual elements.

3 3
Questionnaire
Click to edit Master title style

• Although you may want to include some questions


that elicit free-form comments from the user, in
general you want to develop questionnaires that
generate responses that can be counted and analyzed
across the spectrum of testers.
• It may be good practice to ask the same question
more than once but present it from the opposite
perspective so that one elicits a negative response and
the other a positive one. (so-called test reliability in
psychology)
• For large software systems that undergo extensive
testing with a large user base, statistical software
may help uncover trends that aren’t obvious with
manual interpretation methods.

4 4
How many
Click to tests? title style
edit Master

• If budget and time allow, it is advisable to test


software in stages, as each segment is completed.
• Component tests: to test the usability of an
interactive component, something that requires user
input and that responds to this input in a user-
perceivable way.
• If none of the initial testers have a problem
navigating through their assigned tasks, and none
uncover any mistakes or malfunctions, then perhaps
the testing pool is too small

5 5
Click to edit Master title style

Debugging

6 6
Debugging
Click to edit Master title style

• Debugging is a two-step process that begins when you


find an error as a result of a successful test case and
consists of:
1. Determining the exact nature and location of the
suspected error within the program (≈ 95% of the
problem);
2. Fixing the error.
• Debugging seems to be the one aspect of the software
production process that programmers enjoy the least:
1. Your ego may get in the way.
2. You may run out of steam.
3. You may lose your way.
4. You may be on your own.

7 7
Click toForce
Brute edit Master title style

• Three categories of brute-force methods:


1. Debugging with a storage dump.
2. Debugging according to the common suggestion to
‘‘scatter print statements throughout your program.’’
3. Debugging with automated debugging tools.
• Dumping storage is the least efficient approach:
1. It is difficult to establish a correspondence between
memory locations and the variables in a source
program.
2. A memory dump will produce a massive amount of
irrelevant data.
3. A memory dump is a static picture of the program.
4. It doesn’t show the program’s state at the point of the
error.
5. Adequate methodologies don’t exist for finding errors 8 8
by analyzing a memory dump.
Click toForce
Brute edit Master title style

• Disadvantages of scattering statements throughout a


failing program to display variable values:
1. it is largely a hit-or-miss method.
2. It produces a massive amount of data to be analyzed.
3. It requires you to change the program; such changes
can mask the error, alter critical timing relationships,
or introduce new errors.
4. The cost of using it in large programs is quite high.
Furthermore, it often is not even feasible on certain
types of programs such as operating systems or process
control programs.
• Automated debugging tools work similarly to
inserting print statements within the program. This
method, too, is largely hit or miss, however, and
often results in an excessive amount of irrelevant
data. 9 9
Click toForce
Brute edit Master title style

• The general problem with these brute-force methods


is that they ignore the process of thinking.
• Brute-force methods are only recommended:
1. when all other methods fail;
2. as a supplement to, not a substitute for, the thought
processes we’ll describe next.

1010
Induction
Click to edit Master title style

1. Locate the pertinent data.


2. Organize the data. (You can build a table.)
3. Devise a hypothesis. (Start with the most probable
one.)
4. Prove the hypothesis. (Skipping this step might
result incomplete solution.)
5. Fix the problem. (Do regression testing!)

1111
Induction
Click to edit Master title style

As a simple example, assume that an apparent error


has been reported in the examination grading program
described in Chapter 4. The apparent error is that the
median grade seems incorrect in some, but not all,
instances. In a particular test case, 51 students were
graded. The mean score was correctly printed as 73.2,
but the median printed was 26 instead of the expected
value of 82.

1212
Deduction
Click to edit Master title style

1. Enumerate the possible causes or hypotheses.


2. Use the data to eliminate possible causes. (You can
build a table.)
3. Refine the remaining hypothesis. (For example, you
might start with the idea that ‘‘there is an error in
handling the last transaction in the file’’ and refine
it to ‘‘the last transaction in the buffer is overlaid
with the end-of-file indicator.’’)
4. Prove the remaining hypothesis.
5. Fix the error. (Do regression testing!)

1313
Deduction
Click to edit Master title style

As an example, assume that we are commencing the


function testing of the DISPLAY command discussed in
Chapter 4. As part of the process of establishing input
conditions, we will initialize memory that the first, fifth,
ninth, . . . , words have the value 000; the second,
sixth, . . . , words have the value 4444; the third,
seventh, . . . , words have the value 8888; and the
fourth, eighth, . . . , words have the value CCCC. That is,
each memory word is initialized to the low-order
hexadecimal digit in the address of the first byte of the
word (the values of locations 23FC, 23FD, 23FE, and
23FF are C).

1414
Backtracking and title
Click to edit Master Testing
style

• Backtracking: an effective method for locating errors


in small programs is to backtrack the incorrect
results through the logic of the program until you
find the point where the logic went astray.
• Testing: Consider two types of test cases: test cases
for testing, whose purpose is to expose a previously
undetected error, and test cases for debugging, whose
purpose is to provide information useful in locating a
suspected error.
• The difference between the two is that test cases for
testing tend to be ‘‘fat,’’ in that you are trying to
cover many conditions in a small number of test cases.
Test cases for debugging, on the other hand, are
‘‘slim,’’ because you want to cover only a single
condition or a few conditions in each test case.

1515
Error-Locating Principles
Click to edit Master title style

• Think!
1. Position yourself in a quiet place, where outside
stimuli—voices of coworkers, telephones, radio or other
potential interruptions—won’t interfere with your
concentration.
2. Without looking at the program code, review in your
mind how the program is designed, how the software
should be performing within the area that is
performing incorrectly.
3. Concentrate on the process for correct performance,
and then imagine ways in which the code may be
incorrectly designed.
• If You Reach an Impasse, Sleep on It.
• If You Reach an Impasse, Describe the Problem to
Someone Else.
• Use Debugging Tools Only as a Second Resort. 1616

• Avoid Experimentation—Use It Only as a Last Resort.


Click to edit MasterTechniques
Error-Repairing title style

• Where There Is One Bug, There Is Likely to Be


Another.
• Fix the Error, Not Just a Symptom of It.
• The Probability of the Fix Being Correct Is Not 100
Percent.
• The Probability of the Fix Being Correct Drops as the
Size of the Program Increases.
• Beware of the Possibility That an Error Correction
Creates a New Error.
• The Process of Error Repair Should Put You
Temporarily Back into the Design Phase.
• Change the Source Code, Not the Object Code.

1717
Click toAnalysis
Error edit Master title style

• Information about the nature of software errors can


provide valuable feedback in terms of improving
future design, coding, and testing processes.
• Where was the error made? This question is the most
difficult one to answer, because it requires a
backward search through the documentation and
history of the project; at the same time, it also is the
most valuable question.
• Who made the error?
• What was done incorrectly?
• How could the error have been prevented?
• Why wasn’t the error detected earlier?
• How could the error have been detected earlier?

1818
Click to edit Master title style

Thank You!

19

You might also like