Software Engineering Spring 2006
This assignment is essentially the same as assignment 2, but now for the
full ray tracer.
Part A - test specification
Based on your own requirements document, you must prepare test cases.
For each test case, you must give
Make sure that all requirements are tested, including those
that have been tested on the simple ray tracer (so-called regression
- test data
- expected result - and how you plan to check if the actual
result is the same
- which requirement(s) are tested by this test case (traceability!)
Plan ahead for running a serious number of tests in an efficient
The Methods of Programming course students are now working on their assignment
3 - the full ray tracer. You have to agree with them on internal deadlines
(8th of may) that allow you and them to make the external (i.e. the teachers') deadlines.
Specifically, you have to agree on dates
- when you will do the code review (8th of May to 12 of May)
- when the program is available for system testing
Part B - test report
Run the test cases that you planned to run according to part A (after
comments of Anders Hessel) and document the results in an appropriate way
(e.g. an overview table with test run identifier, pass/fail, comment and
then the individual test runs).
Part C - code review
The code review, together with the code that it refers to, is
handed in to the assistants of the Methods of Programming course.
- Preparation: before the inspection you need:
- a set date, time and place,
- an up-to-date and concise requirements specification,
- a checklist for common errors (e.g. Sommerville Figure 22.7 (6th
ed.: 19.7) is a start) and deviations from the coding
and documentation rules.
- a protocol form that allows you to take notes for each error/deviation:
where in the code, what is the deviation, severity, programmer's comments,
- to be delivered by the Methods of Programming students: code
that compiles without errors and warnings, and passes Lint without warning
(or with only a few that you can defend). The code must also be unit-tested,
and documentation of these test must be available.
- Overview meeting: the programmers present their code.
- Individual preparation: the SE students go through the code, identify
potential errors and problems, and write them down on the protocol form.
- Inspection meeting: (for roles see Sommerville Figure 22.5 (6th ed.:
19.5) - the MP students can alternate between the roles of author and reader,
the SE students between inspector and moderator/scribe). At this meeting,
the protocol is updated: is there an error? severity?
- The assignment is made in pairs. You are welcome
to discuss the assignment with others if it helps you clarify your
thinking, but submit your own work!
- You may write in Swedish or English.