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


1.3
date	92.11.11.11.12.59;	author malingka;	state Exp;
branches;
next	1.2;

1.2
date	92.11.11.10.16.17;	author lacey;	state Exp;
branches;
next	1.1;

1.1
date	92.11.11.08.23.32;	author malingka;	state Exp;
branches;
next	;


desc
@Calculation subsystem test procedure
@


1.3
log
@spell
proofread
@
text
@\section{Test Procedure for Calculations module}
The testing procedure will check whether the Calculation Subsystem perform
the following functionalities:
\begin{itemize}
\item Detect a dependency loop if it exists in the task network.
\item Correctly identify the critical path through the task network.
\item Generate the correct position of each PERT box.
\item Generate the correct position of each Gantt bar.
\item Calculate the earliest/latest start/end dates of a task.
\end{itemize}

\subsection{Order of integration}
Since the Calculation subsystem contains various functions that are critical
to the whole program, a separate test phases and schedule will be included. 
The following are the test phases for the Calculation subsystem: 
\begin{enumerate}
\item Dependency loop detection
\item Critical path detection
\item PERT box location
\item Gantt bar location 
\item Date arithmetic verification 
\end{enumerate}


Among the phases for Calculation subsystem, only phase 5 (Date arithmetic 
verification) depends on another phase. The remaining phases are more or less
independent of each other. Therefore, the schedule for phase 1 to 4 can be
overlapped. Moreover, the integration test for Calculation subsystem should be 
done before Nov. 21 '92, when it will then be hooked up to GUI. With that in 
mind, the following schedule is developed:
\begin{enumerate}
\item Dependency loop detection, tested by Nov. 12, '92
\item Critical path detection, tested by Nov. 13, '92
\item PERT box location, tested by Nov. 15, '92
\item Gantt bar location, tested by Nov. 17, '92
\item Date arithmetic verification, tested by Nov. 20, '92
\end{enumerate}

\paragraph{Modules to be tested}
The three modules within the Calculation subsystem that need to be tested are:
\begin{itemize}
\item General Calculation module \\
	This module will perform tasks such as checking for a dependency loop,
	finding the critical path in the task network, and generating the 
	position of each PERT box. 
\item Gantt Calculation module \\
	This module will generate the position of each Gantt bar along with
	the length of the bar.
\item Date Arithmetic module \\
	This module will calculate the earliest/latest start/end dates. 
	Previously, this module was part of General Calculation module.
	The separation was done to simplify the testing procedure. Since
	this module depends on a correct critical path, we must ensure first
	that the critical path calculation will produce a correct result. This
	way, the Date Arithmetic module can be tested after the output from 
	General Calculation module has been verified.
\end{itemize}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% The following subsubsection should be repeated for each module that
% is invoked by the top-level module.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsubsection{Unit tests for General Calculation module} 
This module will perform tasks such as checking for a dependency loop,
finding the critical path in the task network, and generating the position 
of each PERT box.
The first three test phases are used for analyzing the behavior and 
functionality of this module. 

\begin{description}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Describe the test for the module.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\item[{\bf Description of test for General Calculation module:}]  
There are three tests associated with this module. Those three tests correspond
to the three functions that this module will perform. 
\begin{itemize} 
	\item The first test is used for checking whether the module can 
correctly detect different kinds of dependency loops that might exist in the 
task network. There are two kind of dependency loops that we anticipate:
	\begin{itemize}
		\item {\em self loop} \\
	This can happen when a task depends on itself, in which the 
	dependency pointer points to itself. See Figure~\ref{self:loop}
	for an example. Since the loop can practically exists in every task
	node, several test cases will be supplied for verifying that the module
	did detect the loop.

		\begin{figure}
		\centering
		\centerline{\psfig{figure=self-loop.ps,height=2in}}
		\caption[Self Loop]{An example of a self loop in the task 
			network.}
		\label{self:loop}
		\end{figure}

		\item {\em predecessor loop} \\
	This refers to a task which depends on its predecessor(s). Given the 
	graph in Figure~\ref{self:loop}, there are many possible combination 
	of this type of loop. One such possible combination is given in
	Figure~\ref{pred:loop} 

		\begin{figure}
		\centering
		\centerline{\psfig{figure=pred-loop.ps,height=2in}}
		\caption[Predecessor Loop]{An example of a predecessor loop.}
		\label{pred:loop}
		\end{figure}

	\end{itemize}

	\item The second test is used to verify whether the module can 
identify correctly the longest path through the task network (critical path). 
The algorithm for critical path calculation will pick the first longest 
path encountered (in the case where there are more than one longest paths). 
Therefore, the tests must insure that the status of the longest path at 
any given time is not modified, unless a longer path is encountered. 

	\item The third test is used to verify that the PERT boxes are 
correctly placed into their grids. This is probably the hardest part to test
since the only procedure that we can think of is to check the result on
paper (since this test should be independent of \LaTeX\ PERT Chart 
Generation module). Output comparison with MS-Project was also considered,
but will not determine the correctness of the PERT box's location since
MS-Project output is not {\em the only} correct solution. 

\end{itemize}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Use of stubs or other software to facilitate the test
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\item[{\bf Overhead software description:}] \hfill \\
A ``dummy'' database will be created to hold the different sets of test
data. The size and content of the database will be determined by the test
that will be performed on the module. When the database subsystem has been
tested completely, the new test data will be generated by the database
subsystem. \\
As mentioned in the description above, MS-Project output may be used as a 
comparison, but will not determine the correctness of the module's
output. Instead, it will be used to verify the validity of test data.
This is useful in a sense that we could check for bad test data. This will
ensure that if an error does come up, it is caused by the module, and not
by the test data. \\



%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% What data did you use to conduct the tests?
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\item[{\bf Test case data:}] \hfill \\
For most of the tasks in this module, a ``dummy'' database will be used.
Test case data that will be used for General Calculation module are as
follow:
\begin{enumerate}
	\item Multiple longest paths \\
	This test case is primarily used for critical path detection. The 
purpose is to create more than one {\em correct} answer for finding the
critical path.
	\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 breath-graph. % I don't even understand this; must rephrase.
	\item Multiple sub-paths \\
	This is 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). See Figure~\ref{sub:path}.

		\begin{figure}
		\centering
		\centerline{\psfig{figure=sub-path.ps,height=3in}}
		\caption[Multiple Sub-paths]{An example of multiple sub-paths.}
		\label{sub:path}
		\end{figure}

The module should be able to handle any number of sub-paths. 

	\item Stand-alone paths \\
	This test case is especially useful for testing the position of PERT
boxes generated. See Figure~\ref{alone:path}. The lose definition for 
stand-alone path is a path which covers more than 1 sub-paths.

		\begin{figure}
		\centering
		\centerline{\psfig{figure=alone-path.ps,height=3in}}
		\caption[Stand-alone Path]{An example of stand-alone path.}
		\label{alone:path}
		\end{figure}

\end{enumerate}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Briefly, what type of results do you expect?
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\item[{Expected Results:}] \hfill \\
\begin{enumerate}
\item If a task network contains 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 node (or task) that belongs to the critical path must be clearly
marked in the database. The critical path can be found by traversing the
task list backward. 
\item Each of the PERT boxes must be correctly placed in chronological order,
and no two boxes can occupy the same grid.
\end{enumerate}
\end{description}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% DO NOT FILL OUT THE FOLLOWING SECTION FOR THE TESTING SPEC DELIVERABLE!!
% The testing results will be turned when the practice demo is given.
%
% For each top level module, describe the testing results.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 
%\subsubsection{Actual Test Results}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% The following subsubsection should be repeated for each module that
% is invoked by the top-level module.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsubsection{Unit tests for Gantt Calculation module} 

This module will generate the position of each Gantt bar along with the 
length of the bar.

\begin{description}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Describe the test for the module.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\item[{\bf Description of test for Gantt Calculation module:}] \hfill \\
The test must ensure that each bar is positioned on a separate line and the 
length of the bar must correspond to the task duration. The Gantt bars must 
also be displayed in semi-chronological order, meaning that the subtasks 
within a task will be displayed in chronological order. 
See Figure~\ref{order:gantt}.
Notice that sub-task 1.4 and sub-task 2.1 are not in chronological order.

		\begin{figure}
		\centering
		\centerline{\psfig{figure=order-gantt.ps,height=3in}}
		\caption[Gantt Chart]{An example of a Gantt chart.}
		\label{order:gantt}
		\end{figure}


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Use of stubs or other software to facilitate the test
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\item[{\bf Overhead software description:}] \hfill \\
This module will use both the ``dummy'' database described earlier in
General Calculation section, and the output generated by MS-project.
Again, since this module is tested independent of \LaTeX\ Gantt Generation
module, the output generated must be compared with the ``paper and pencil''
result.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% What data did you use to conduct the tests?
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\item[{\bf Test case data:}] \hfill \\
In addition to the test cases generated for the General Calculation module,
the Gantt Calculation module will also use the following test cases:
\begin{enumerate}
	\item Task with duration = 0 day (milestones or deliverables)
	\item Overlapping sub-tasks \\
	These are sub-tasks that can start while other sub-tasks (within a
task) have not been completed. 
	\item Insertion of the tasks in reverse chronological order \\
	This will insure that the output generated by the Gantt Calculation
module are independent of the order of task insertion into the database.
\end{enumerate}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Briefly, what type of results do you expect?
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\item[{Expected Results:}] \hfill \\
The expected result is that each bar in the Gantt chart will match the output
produced by the ``paper and pencil'' technique. Note that Gantt Calculation
module only calculates the {\em position and length} of each bar and does not
produce any screen or hard copy output. Therefore, if the result produced by
this module matches the ``paper and pencil'' output, the graph produced by
the ``paper and pencil'' technique will be compared later with the actual
output from MS-Project.

\end{description}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% DO NOT FILL OUT THE FOLLOWING SECTION FOR THE TESTING SPEC DELIVERABLE!!
% The testing results will be turned when the practice demo is given.
%
% For each top level module, describe the testing results.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 
%\subsubsection{Actual Test Results}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% The following subsubsection should be repeated for each module that
% is invoked by the top-level module.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsubsection{Unit tests for Date Arithmetic module} 

This module will calculate the earliest/latest start/end dates. 
Previously, this module was part of General Calculation module. The separation 
was done to simplify the testing procedure. Since this module depend on 
a correct critical path, we must ensure first that the critical path 
calculation will produce a correct result. This way, the Date Arithmetic 
module can be tested after the output from General Calculation module has been 
verified.

\begin{description}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Describe the test for the module.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\item[{\bf Description of test for Date Arithmetic module:}] \hfill \\
The test case must insure that the routines will detect illegal dates
(such as February 30), and that the routines will correctly calculate
the earliest/latest start/end dates, given that the longest path (critical
path) is known. Therefore, the output from this module will depend on the
output generated by the General Calculation module. 


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Use of stubs or other software to facilitate the test
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\item[{\bf Overhead software description:}] \hfill \\
A ``dummy'' database will be used to hold the different sets of test data. 


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% What data did you use to conduct the tests?
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\item[{\bf Test case data:}] \hfill \\
Test case data that will be used for Date Arithmetic module are as
follows:
\begin{enumerate}
	\item Milestone or deliverable dates \\
	These dates belong to tasks that have a duration of 0 day. This will
check whether the module correctly take into account those tasks with no
duration.
	\item Multiple critical paths \\
	Since the algorithm used for calculating the dates rely heavily on
the critical path, this test will check whether the routine still produce a
correct output independent of the critical path chosen by General Calculation
module.
	\item Task duration greater than 1 month \\
	This will check whether the module perform the date conversion 
correctly.
Test case should be done especially with the month of February to ensure that
the module will work with any given month.
	\item Task duration greater than 1 year \\
	Although this is highly unrecommended (to have task duration more than
one year), the test case is useful for checking whether the module calculate
the leap year conversion correctly. This will also have an effect on the month
of February.
\end{enumerate}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Briefly, what type of results do you expect?
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\item[{Expected Results:}] \hfill \\
The module is expected to produce the correct output given the test cases 
above. The output must then be stored to the database at the correct
location.

\end{description}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% DO NOT FILL OUT THE FOLLOWING SECTION FOR THE TESTING SPEC DELIVERABLE!!
% The testing results will be turned when the practice demo is given.
%
% For each top level module, describe the testing results.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 
%\subsubsection{Actual Test Results}
@


1.2
log
@*** empty log message ***
@
text
@d4 1
a4 1
\begin{enumerate}
d10 12
d24 1
a24 1
\subsection{Order of integration}
d27 1
a27 1
independent of each other. Therefore, the schedule for phase 1 - 4 can be
d29 2
a30 2
done before Nov. 21 '92, when it will be hooked up to GUI. With that in mind, 
the following schedule is developed:
d40 1
a40 1
There are three modules within Calculation subsystem that need to be tested.
d43 3
a45 3
	This module will perform tasks such as checking for dependency loop,
	finding the critical path, and generating the position of each PERT
	box. 
d53 1
a53 1
	this module depend on a correct critical path, we must ensure first
d55 2
a56 2
	way, Date Arithmetic module can be tested after the output from General
	Calculation module has been verified.
d64 3
a66 2
This module will perform tasks such as checking for dependency loop,
finding the critical path, and generating the position of each PERT box.
d76 2
a77 2
to the three functionalities that this module will perform. 
begin{itemize} 
d79 1
a79 1
correctly detect different kind of dependency loops that might exist on the 
d92 1
a92 1
		\caption[Self Loop]{An example of a self looping the task 
d115 2
a116 2
path encountered (in the case where there are more than one longest path). 
Therefore, the tests must ensure that the status of the longest path at 
d127 1
a127 1
end{itemize}
a131 1

d134 2
a135 2
that will be performed on the module. When the Database subsystem has been
tested completely, the new test data will be generated by the Database
a197 1

d199 1
a199 1
\item If a task network contain a dependency loop, the routine 
d232 5
a236 4
The test must ensure that each bar is positioned on separate line and length of
the bar must correspond to the task duration. The Gantt bars also must be
displayed in semi-chronological order, meaning that the subtasks within a
task will be displayed in chronological order. See Figure~\ref{order:gantt}.
a250 1

a260 1

d262 1
a262 1
Gantt Calculation module will also use the following test cases:
d268 3
a270 3
	\item Insert the tasks in reverse chronological order
	This will ensure that the outputs generated by the Gantt Calculation
module are independent of the order of tasks insertion into the database.
a275 1

d277 1
a277 1
produce by the ``paper and pencil'' technique. Note that Gantt Calculation
d304 2
a305 2
calculation will produce a correct result. This way, Date Arithmetic module 
can be tested after the output from General Calculation module has been 
d313 1
a313 2

The test case must ensure that the routines will detect illegal dates
d317 1
a317 1
output generated by General Calculation module. 
a323 1

d332 1
a332 1
follow:
d334 1
a334 1
	\item Milestone or deliverable dates
d338 1
a338 1
	\item Multiple critical paths
d343 3
a345 2
	\item Task duration greater than 1 month
	This will check whether the module perform the date conversion correctly.
d348 1
a348 1
	\item Task duration greater than 1 year
a357 1

@


1.1
log
@Initial revision
@
text
@d47 9
a55 3
\input{module-gen-calc}
\input{module-gantt-calc}
\input{module-date-calc}
d57 307
@
