head	1.2;
access;
symbols;
locks; strict;
comment	@% @;


1.2
date	92.12.14.07.48.30;	author malingka;	state Exp;
branches;
next	1.1;

1.1
date	92.12.14.00.03.09;	author lacey;	state Exp;
branches;
next	;


desc
@@


1.2
log
@calc testing results
@
text
@%---------------------- General Calculation Module ----------------------
\subsection{General Calculation Module}
%
% If your testing specifications were correct, then you can
% include the text for the test data description and expected 	
% results. Otherwise, incorporate the corrected descriptions.
%
\begin{description}
\item[{Test Data: }]
Test case data that were used for General Calculation module are as
follow:
\begin{enumerate}
	\item Multiple longest paths \\
	This test case was primarily used for critical path detection. The 
purpose was to make sure that this module can detect multiple longest paths.
	\item Multiple parallel paths \\
	This test case was useful for both critical path detection and PERT
box location. Since the calculations were based on depth-first-search
algorithm, the graph (or task network) was created in such a way to reflect
a breadth-graph. % I don't even understand this; must rephrase.
	\item Multiple sub-paths \\
	This was probably the most important test case that will be used.
Recall that depth-first-search algorithm is based on graphs and/or trees.
In contrast, rarely the task networks will represent regular graphs and/or
trees. For example, a tree usually will have one root node and many leaf
nodes. With task network, we only have one root node (the first task) and
a few leaf nodes (the last tasks). Refer to Figure~8 on page 23 in the original
Testing Specifications. 
	\item Stand-alone paths \\
	This test case was especially useful for testing the position of PERT
boxes generated. refer to Figure~9 on page~24  in the original
Testing Specifications. The loose definition for 
stand-alone path is a path that covers more than 1 sub-path.
\end{enumerate}

\item[{Expected Results: }]
\begin{enumerate}
	\item If a task network contained a dependency loop, the routine 
traverse-task-list() should return an error message that was originally 
produced by the recursive function visit-task(). 
	\item Each of the PERT boxes must be correctly placed in chronological
order, and no two boxes could occupy the same grid.
\end{enumerate}

\item[{Actual Results: }] 
\begin{enumerate}
	\item The routine visit-task() did detect the dependency loop
and set the loop-found variable to {\em true}.
	\item The PERT boxes locations did satisfy the expected results
given above. All boxes were arranged in chronological order, and no two boxes
occupied the same grid.
\end{enumerate}
\end{description}

%-------------------- Date Arithmetic ---------------------------------

\subsection{Date Arithmetic Module}
\begin{description}
\item[{Test Data: }]
Test case data that were used for Date Arithmetic module are as
follow:
\begin{enumerate}
	\item Milestone or deliverable dates \\
	These dates belong to tasks that have a duration of 0 day. This 
checked whether the module correctly took into account those tasks with no
duration.
	\item Multiple critical paths \\
	Since the algorithm used for calculating the dates relied heavily on
the critical path, this test checked whether the routine still produced a
correct output when multiple critical path existed.
	\item Negative float \\
	Negative float refer to a task in which the time needed to
finish that task is more than the duration given. This means that the
task would not be completed on time given the current resources. 
\end{enumerate}

\item[{Expected Results: }]
The module was expected to produce the correct output given the test
cases above. The output were stored to the database
at the correct location. 

\item[{Actual Results: }] 
The module produced the output as expected for the first two test
cases. The final product did not make any attempt to handle negative
float. This can be implemented as future extension.
\end{description}

%-------------------- Critical Path ---------------------------------
\subsection{Critical Path Module}
\begin{description}
\item[{Test Data: }]
\begin{itemize}
	\item Multiple critical paths \\
Multiple critical path were provided to test whether the module could
detect all the paths.
	\item Multiple parallel paths \\
This test case is useful for both critical path detection and PERT
box location. Since the calculations are based on depth-first-search
algorithm, the graph (or task network) is created in such a way to reflect
a breadth-graph. % I don't even understand this; must rephrase.
\end{itemize}
	
\item[{Expected Results: }]

The module was expected to detect all the critical paths in the task
network. To be precise, the module must mark all the task that belong
to the critical path.

\item[{Actual Results: }] 
The module performed as expected. All the tasks in the critical paths
were correctly identified and were marked in the database.
\end{description}
@


1.1
log
@Initial revision
@
text
@d1 2
a2 1
\subsection{Database Module}
d10 26
d37 8
d46 66
@
