\documentclass[signature]{deltares_manual}
\usepackage[titletoc]{appendix}

\renewcommand\BackgroundPicChapter{
    \put(0,0){
    \parbox[b][\paperheight]{\paperwidth}{%
        \vspace{4\baselineskip}
        \hspace{220mm}
        \includegraphics[width=15mm]{pictures/Ribbon.pdf}%
        \vfill
        }
    }
}

\renewcommand{\contactsalesandsupport}{
	\textbf{Contact:}\\
	\begin{tabular}[t]{@{}p{0.50\textwidth}p{0.50\textwidth}}
	\vspace*{-1.5\baselineskip}
	\begin{tabbing}
	Helpdesk Water  \\
	Rijkswaterstaat WVL \\
	P.O. 2232 \\
	3500 GE Utrecht \\
	The Netherlands \\
	\end{tabbing}
	&
	\vspace*{-1.5\baselineskip}
	\begin{tabbing}
	telephone: \= +31\,88\,797\,7102 \\
	www:       \> http://www.helpdeskwater.nl \\
	\end{tabbing}
	\end{tabular}
}

%
%------------------------------------------------------------------------------
%
\begin{document}
\pagestyle{empty}
\includepdf[pages=1, offset=72 -70]{pictures/DSoilModel_TestPlan_Cover.pdf} % links-rechts past precies
\cleardoublepage

\newcommand{\DSOILMODEL}{D-Soil~Model\xspace}

\title{\DSOILMODEL}
\subtitle{}
\manualtype{Test Plan}
\version{2.0}
\revision{}

\client{RWS}
\projectnumber{1230088-026}
\reference{1230088-026-DSC-0002}
\classification{-}

\keywords{WTI2017, hydraulic structures, structural failure, calculation kernel, wave pressure, linear load calculation, quadratic load calculation}

\references{\begin{thebibliography}{100}
\bibitem[Lit 1]{TechnicalDesign} WTI 2017 DSoilModel - Technical Design, J. Bokma, J. Beckers, B. Adriaanse, Deltares report 1209430-003-DSC-0021, Dec. 2015.
\bibitem[Lit 2]{ReqAndFunctDesign} WTI 2017 D-Soil Model - Requirements and Functional Design, I. van der Zwan
R. van der Meij, Deltares report 1209430-003-DSC-0009 version 1 (final), March 2015.
\bibitem[Lit 3] {OverallTestPlanWTI} Overall Testplan Software WTI2017 - RingToets, HydraRing, D-Soil Model en Faalmechanisme bibliotheken. H. van Putten \& P. Witlox, Deltares report 1220079-005-DSC-0006, 2015.
\bibitem[Lit 4] {AcceptatieTestPlan} Acceptatietestplan -- Plan voor acceptatie van de WTI2017 software, H. van Putten \& P. Witlox, Deltares report 1230088-036-DSC-0001, 2016.
\bibitem[Lit 5] {Eisen} Eisen aan toelevering van softwarecomponenten aan het Cluster Softwareontwikkeling, J. Icke, Deltares rapport 1209430-005-DSC-002, 2014.
\bibitem[Lit 6] {Basisuitgangspunten} Basisuitgangspunten WT12017. Watersystemen, Faalmechanismen en Softwareontwikkeling. J.G. Knoeff et al., Deltares report 1206004-002-GEO-0002, 2012. 
\end{thebibliography}}

\summary{This document contains the 2$^{\text{nd}}$ version of the test plan for \DSOILMODEL, including the comments of H. Walls (Rijkswaterstaat).}

\authori{dr. V. Trompille}
\revieweri{P. Witlox \newline ir. K.S. Lam}
\approvali{ir. J. Icke}
\versioni{1.0}
\datei{July 2015}

\authorii{dr. V. Trompille}
\reviewerii{dr.ir. J.G. van \newline Putten}
\approvalii{ir. J. Icke}
\versionii{2.0}
\dateii{April 2016}


\status{final}

\deltarestitle
%------------------------------------------------------------------------------

\chapter{Introduction}

\section{Purpose and scope of this document}

This document contains the test plan design for \DSOILMODEL. 

The document will not give any background on the context of the WTI project. For this purpose the reader is referred to the WTI2017 and to its supporting technical reports and their background reports underneath (paragraph 1.3). 

This document will not describe how the requirements and functional design are implemented in the program. 

This document describes the different regression and acceptation tests, including target values.

\section{Other system documents}

The full documentation on \DSOILMODEL comprises the following documents.

\begin{table}[H]
%\caption{xxx}
%\label{xxx}
\begin{tabular}{|p{40mm}|p{50mm}|p{\textwidth-90mm-36pt}|} \hline 
\textbf{Title} & \textbf{Content} & {Authors} \\ \hline
Requirements and Functional Design \citep{ReqAndFunctDesign} & Description of the requirements and functional design. & Raymond van der Meij, \newline Kin Sun Lam \\ \hline
Technical Design \citep{TechnicalDesign} & Description of the implementation of the functional design & John Bokma \\ \hline
Technical Specification & Description of the arguments and usage of different software components, generated from in-line comment with Doxygen & John Bokma \\ \hline
Test Plan & This document & Virginie Trompille \\ \hline
Test Report & Actuated results of the test plan. & Virginie Trompille \\ \hline
\end{tabular}
\end{table}


\section{Assumptions and constraints}

\textbf{CNS 1} As a general constraint, the development process needs to comply with the general process description for WTI software, contained in a separate document \citep{Eisen}.

\textbf{CNS 2} As a general constraint, the program needs to comply with the relevant general requirements and further design rules for the programming, documentation and testing of WTI software. This set of requirements and rules is contained in a separate document \citep{Basisuitgangspunten}.



\section{Test levels} \label{sec:1.4}
According to \cite{OverallTestPlanWTI}, the program \DSOILMODEL should be tested on four different levels (V-Model):
\begin{enumerate}
	\item Component Testing
	\item Integration Testing
	\item System Testing
	\item Acceptance Testing
\end{enumerate}

\subsection*{Component Testing (Unit tests)}
Component Testing is testing on code level using the unit tests. For each relevant function, a unit test is defined within the C\# solution. A relevant function is a function that actually performs part of the calculation, validation or I/O of the core. Properties and purely administrative functions do not have unit tests. \\
Refer to \Cref{chapter2} for more information.

\subsection*{Integration Testing (Integration tests)}
Integration Testing is testing on functional level using integration tests. These types of tests combine multiple functions to prove that high level functionality works. For this, a unit test is defined within the C\# solution for each method with high level functionality.\\
Refer to \Cref{chapter3} for more information.

\subsection*{System Testing (Benchmarks and test scripts)}
System Testing is testing the functioning of the complete system: 
\begin{itemize}%[no separator]
	\item The main calculator must provide the correct answers to confirm its performance according to the functional design;
	\item All possible errors must be handled and reported properly;
	\item The \textit{User Interface} must function properly.
\end{itemize}	
Refer to \Cref{chapter4} for more information.

\subsection*{Acceptation level (Acceptance tests)}
The Acceptance Test of \DSOILMODEL will be covered in the acceptance test for the overall WTI system (which includes acceptance tests for the stand-alone tools) and will be reported in a so-called Acceptance Report \citep{AcceptatieTestPlan}.

\section{Code coverage}\label{sec:1.5}

Testing is considered to be ok when all the unit tests pass and when the code coverage of those tests is more than 60\% so as prescribed in \cite{OverallTestPlanWTI}. 

To determine the code coverage of the \textit{Calculation} components, the feature `Code coverage' of Visual Studio can be used. This tool shows the percentage of the code that was tested in each assembly, class, and method, and is visible on the build server.




%------------------------------------------------------------------------------
\chapter{Component Testing (Unit tests)} \label{chapter2}

The tests on code level are the unit tests. For each relevant function, a unit test is defined within the C\# solution. A relevant function is a function that actually performs part of the calculation, validation or I/O of the core. Properties and purely administrational functions do not have unit tests.

These tests are considered to be ok when the unit tests pass and when the code coverage of those tests is more than 60\%, as prescribed in \cite{OverallTestPlanWTI} for UI solutions. For these tests, see the C\# solution.

The following information must be provided in the Test Report:
\begin{itemize}
	\item Number of unit tests
	\item Code coverage of the unit tests
	\item Specify if all unit tests succeed or not
\end{itemize}


%------------------------------------------------------------------------------
\chapter{Integration Testing (Integration tests)} \label{chapter3}

The tests on functional level are the integration tests. These types of tests combine multiple functions in the kernel to prove that high level functionality works. For this, an integration test is defined within the C\# solution for each method with high level functionality.

These tests are considered to be ok when the integration tests pass. For these tests, see the C\# solution.

The following information must be provided in the Test Report:
\begin{itemize}
	\item Number of integration tests
	\item Code coverage of the integration tests
	\item Specify if all integration tests succeed or not
\end{itemize}



%------------------------------------------------------------------------------
\chapter{System testing (Test Scripts)} \label{chapter4}

As \DSOILMODEL is a database and support software for schematize the subsoil, the system testing will only consist of executing test scripts and common tests for general User Interface functionalities. 

A Test Script will be provided to the tester, describing a sequence of actions and the expected outcome. An overview of the Test Scripts is listed below:
\begin{itemize}
	\item \textbf{Language:} \\
	The test must be done only for Dutch language.
	\\
	\item \textbf{Layout:} \\
	The layout must be identical to the layout described in the Technical Design \citep{TechnicalDesign}:
	\begin{itemize}
		\item Menu items
		\item Options in each menu items
		\item Tool bar
		\item Components
		\item Tabs
		\item Icon bar of tabs
	\end{itemize}
	\\
	\item \textbf{Menu:} \\
	All available options under the different items of the menu must be tested.
	\\
	\item \textbf{Menu bar:} \\
	All icons of the menu bar must be tested.
	\\
	\item \textbf{Import files:} \newline
	The import option must be tested by importing the following files and checking that the data's are correctly and completely imported:	
	\begin{itemize}
		\item Soils from database (*.mdb file)
		\item 1D profiles from file (*.csv file)
		\item 2D profiles from file (*.sti and *.geo files)
		\item Surface lines from file (*.csv file)
		\item Characteristic Points from file
		\item Soil segments from file (csv) (*.csv file)
		\item Soil segments from file (shape)
		\item CPT from file (*.gef file)
		\item Boring from file (*.gef file)
		\item DAM import dataset (*.defx file and the underlying files refers in the defx)
		\item Old Project database of previous versions or forerunners of \DSOILMODEL (*.mdb and *.gdb files)
	\end{itemize}
	Each importation of a file will have at least one test script.
	\\
		\item \textbf{Tables toolbar:} \\
	All icons of the Tables toolbar (when available) must be tested:
	\begin{itemize}
		\item Add
		\item Delete
		\item Cut
		\item Copy
		\item Paste
		\item Fits columns
		\item Edit
		\item Edit Unit
		\item Export (all available formats must be tested)
	\end{itemize}
	\\
	\item \textbf{Map / Length Profile toolbar:} \\
	All icons of the Map and Length Profile toolbar (when available) must be tested:
	\begin{itemize}
		\item Selection
		\item Pan
		\item Zoom to extents
		\item Zoom to extents and	reset aspect ratio
		\item Zoom to data
		\item Zoom by rectangle
		\item Options
		\item Show legend
		\item Open layer from file
		\item Export layers	
		\item Save map
		\item Select web layer
		\item Selection	
		\item Add location for split
	\end{itemize}
	\\
	\item \textbf{Property Editors:} \\
	The content of the property editor must be check for all selected objects. \\
	The coupling between the content of the Property Editors and the Tables component must also be tested: changing a property in the Property Editors should affect the Tables component.
	\\
	\item \textbf{Default/Min/Max:} \newline
	The default, minimum and maximum values  of all properties (as given in the Functional Design) must be tested.
	\\
	\item \textbf{Filters:}
	All possible filters must be tested, by checking that the resulting list of is as expected (no more, no less). All possible combination of filters must also be tested.
\end{itemize}



All the \textit{Test Scripts} are part of a so-called \textit{Test Document} that will be joined as Annex in the Test Report.


\section{Test Script template}

A test script will consist of:
\begin{itemize}
	\item The header of a test has a title.
  \item The description of a test.
  \item If applicable, the preconditions of a test. A precondition descripts the system state and data required to start the test;
  \item The sequence of steps (acts) that must be performed. For each step the expected output and the actual (test) result. 
  \item Remarks and details on the test results can be put at the end of the test.
\end{itemize}

If a test step fails, just add ``failed'' in the column ``Result''. 

\begin{table}[H]
%\caption{xxx}
%\label{xxx}
\begin{tabular}{|p{40mm}|p{50mm}|p{\textwidth-90mm-36pt}|} \hline 
\multicolumn{3}{|p{\textwidth-36pt}|}{\textbf{Test Title}} \\ \hline
\multicolumn{3}{|p{\textwidth-36pt}|}{Test description: <description of the tests>} \\ \hline
\multicolumn{3}{|p{\textwidth-36pt}|}{Preconditions: <system state and data>} \\ \hline
\textit{\textbf{Steps (test script)}} & \textit{\textbf{Output}} & \textit{\textbf{Result}} \\ \hline
Act 1 & Expected Output & Passed \\ \hline
Act 2 & Expected Output & Failed, Comment 1 \\ \hline
& Expected Output & Passed \\ \hline
Act 3 & - & - \\ \hline
Act 4 & Expected Output & Failed, see Remark \\ \hline
\multicolumn{3}{|p{\textwidth-36pt}|}{Remarks (details, data sets, screenshots)} \\ \hline
\end{tabular}
\end{table}



%------------------------------------------------------------------------------
\cleardoublepage

\pagestyle{empty}
\cleardoublepage
\mbox{}
\includepdf[pages=2, offset=-72 -70]{pictures/DSoilModel_TestPlan_Cover.pdf} % links-rechts past precies


\end{document}
