Individual Reports, 2B03
2003 February 18
When designing, reviewing and testing individual routines for your player
modules for the card game Sevens and writing the corresponding reports,
please note the following guidelines and the expected contents of your
reports. See also the slides for the corresponding lectures.
Design Report: Your task of designing a particular routine starts
with the specification of your routine (the relevant parts of the MIS and
MID, especially the routine semantics in terms of the concrete state variables)
and ends with
-
the source code in Oberon-2 for the routine and
-
your design report.
It is the designer's responsibility to ensure that the Oberon-2 source
code satisfies the specification (see section 7 of the Semiformal Specification
of the Interface between the Main Control Program and the Student Teams'
Player Modules at MCPInterface2B03.html.)
Your Design Report should include
-
a copy of the relevant parts of the MIS and MID,
-
the Oberon-2 source code you have designed and
-
your explanation how you determined your program (source code) based on
the specification.
In your report explain why you wrote the source code you wrote and not
some other code. Indicate what techniques, criteria, etc. you used for
transforming the specification into your source code. Address the issues
raised by the following questions:
-
How confident are you that your program satisfies the specification? Why
are you so confident (or not so confident)?
-
What information (if any) other than the specification did you consider
when designing and writing your program code? Why did you need it? What
are the results of your considering such other information?
-
If you were to design this routine again, what would you do differently?
Why? What additional information would you like to have before beginning
again?
Review Report: Your task of inspecting and reviewing a particular
routine starts with the Design Report (and relevant parts of other documents
such as the MIS and MID) and ends with your conclusions regarding the presence
or absence of errors in the routine's source code or in its specification.
Your Review Report should
-
describe the methods and the criteria (be specific) you used to inspect
and review the routine and its specification,
-
list the errors you found in the routine or its specification (if none,
state so and justify),
-
justify your confidence that no other errors are present in the routine
or its specification,
-
list other shortcomings, desirable improvements, etc. (if any),
-
suggest corrections or improvements to the routine (if any) and
-
give recommendations for designing and inspecting routines in the future.
In your report explain why you inspected and reviewed the routine the way
you did and not some other way. Indicate what techniques, criteria, etc.
you used in your inspection. Address the issues raised by the following
questions:
-
How confident are you that you found all errors in the routine and its
specification? Why are you so confident (or not so confident)?
-
What information (if any) other than the Design Report did you consider
when inspecting and reviewing the routine's design? Why did you need it?
What are the results of your considering such other information?
-
How easy or difficult was it to inspect and review the routine? Why? What,
if anything, should the designer do differently in the future in your opinion?
-
If you were to inspect this routine again, what would you do differently?
Why? What additional information would you like to have before beginning
again?
Testing Report: Your task of testing a particular routine
starts with the Design Report and possibly the Review Report and relevant
parts of other documents such as the MIS and MID and ends with your list
and analysis of errors in the routine and in its specification and, in
particular and most importantly, test cases not handled correctly by the
routine being tested.
Throughout your testing you should take the attitude that there are
errors in the routine and that you will find all of them. Be very
critical and suspicious.
Your Testing Report should
-
describe the types of tests you used (black box, etc.)
-
describe the criteria (be specific) you used to generate your test cases,
-
state your reasons for deciding upon your methods and criteria to generate
test cases (and no others),
-
give an overview of your testing activities (number and types of test cases,
results, etc.),
-
list the errors you found in the routine or its specification and the test
cases not handled correctly by the routine,
-
analyze the errors you found,
-
justify your confidence that no other errors are present in the routine
or its specification,
-
list other shortcomings (if any) you noticed while testing the routine,
-
give recommendations for testing routines in the future and
-
give recommendations to the designer or other persons who made and must
correct the errors you found and to the reviewer who did not notice the
errors you found.
Your Testing Report must give at least the following information for every
test case:
-
the values of the input variables (input parameters and initial values
of relevant state variables)
-
the values of the output variables (output parameters and final values
of relevant state variables)
-
the correct values of the output variables (output parameters and final
values of relevant state variables)
-
whether the test case was constructed on the basis of white, gray or black
box considerations
-
the path segments covered by the test case
Your Testing Report must include a table showing which or how many test
cases exercised which path segments. Use this table to ensure that your
test cases covered all path segments.
Voluminous detail (e.g. a list of many test cases) should be included
in an appendix and summarized in the body of your report.
In your report explain why you tested the routine the way you did and
not some other way. Indicate what techniques, criteria, etc. you used in
your testing. Address the issues raised by the following questions:
-
How confident are you that you found all errors in the routine and its
specification? Why are you so confident (or not so confident)?
-
What information (if any) other than the Design Report did you consider
when testing the routine? Why did you need it? What are the results of
your considering such other information?
-
How easy or difficult was it to test the routine? Why? What, if anything,
should the designer do differently in the future in your opinion in order
to facilitate testing?
-
If you were to test this routine again, what would you do differently?
Why? What additional information would you like to have before beginning
again?