\documentclass[12pt, titlepage]{article}

\usepackage{booktabs}
\usepackage{tabularx}
\usepackage{hyperref}
\hypersetup{
    colorlinks,
    citecolor=black,
    filecolor=black,
    linkcolor=red,
    urlcolor=blue
}
\usepackage[round]{natbib}

\title{SE 3XA3: Test Report\\Title of Project}

\author{Team \#, Team Name
		\\ Student 1 name and macid
		\\ Student 2 name and macid
		\\ Student 3 name and macid
}

\date{\today}

\input{../Comments}

\begin{document}

\maketitle

\pagenumbering{roman}
\tableofcontents
\listoftables
\listoffigures
\clearpage

\begin{table}[bp]
\caption{\bf Revision History}
\begin{tabularx}{\textwidth}{p{3cm}p{2cm}X}
\toprule {\bf Date} & {\bf Version} & {\bf Notes}\\
\midrule
Date 1 & 1.0 & Notes\\
Date 2 & 1.1 & Notes\\
\bottomrule
\end{tabularx}
\end{table}

\clearpage

\pagenumbering{arabic}

This document ...

\section{Functional Requirements Evaluation}
\subsection{Opening a GIF}
There were four tests conducted to ensure that opening the GIF could be performed by Gifitti without any problems. 
 The first test was the ability of the program to load a GIF. The program is loaded intially and a GIF is selected 
that will be loaded into memory, being displayed to the user. The results of this test matched the expected output. 
The next few tests pertain to scenarios where it would cause errors in the program. They all start with the program running but with different errornous inputs such as no file path, null filepath, and inncorrect file type. All these inputs do not cause any change in the 
running program which is the expected output. All the tests in opening a GIF file has been successful in determining a proper functioning.
\subsection{Save a GIF}
There are three tests conducted that verify that the GIF modify in the program is saved properly on the file system of the user's 
computer. They all start with an intial state of a GIF already loaded into the program and are saved either in known, chosen or non-existing locations. When the user selects a valid location, the program will save the GIF as it appears in the program but gives an error if you try to save it in a non-existant location. This is the expected output of the test performed.
\subsection{Start, Stop, Modify Length}
The test pertaining to the stop and start of the animation has the initial conditions of a GIF already loaded in and will take input of a GIF either in an animation or stopped on a frame, with the start and stop button being pressed to pause or resume the animation. The program performs these functions as expected. The testing for the modification of the GIF was successful as the program takes a GIF and cuts it down to the specified frame length. For example, a GIF of 20 frames was successfully shortned to frames five to ten.
\subsection{Save In Different File Format}
Four tests were conducted in the exact same fashion where a GIF, already loaded into the program,  had its frames exported into an image format. These four tests were extremely successful in exporting the images in their specific file format (JPEG, PNG, TIFF, BMP) that did not overwrite each other. The output matched the expected output.
\subsection{Help Context}
One test was performed to determine if the help section could be easily acccesible and understandable. With the program loaded, the help tab was tested if it opened and the definitions given were viewable. This test proved to be successful in matching what the expected output was supposed to be.
\subsection{Resize}
A GIF was loaded into the program and a specific size was specified by the user. The GIF would be resized to that specified size which matched the expected output of that function. There was also a test that went through the exact same process where it utilized edge case to determine if it crashed the program. As expected, it did not crash it.
\section{Nonfunctional Requirements Evaluation}	
\subsection{Performance}

\section{Unit Testing}
Unit testing has been done on system methods that return a value, or modify
known objects in an expected way. A metric for passing is to be used on
all methods with an error tolerance, such as manipulation of a GIF (where
slight variations can exist in the output). A method with no
expected error tolerance has been implemented as discreetly pass XOR fail.
All unit test inputs fall in a known domain where the expected output
can be assumed. The unit tests were utilized to ensure that certain edge cases
were considered and that they did not crash the program.\\

To test the validity of outputted GIF images, the testing system holds
image resources of input frames, input GIFs, as well as the expected GIF
outputted. A known GIF was manipulated and then compared to
the expected GIF in a frame-by-frame matter. To exclude meta-data issues
associated with GIF images, each frame was cast to a known image
format such as a bitmap, then compared pixel-by-pixel. Frames  have had 
a 100 percent pixel match for the expected GIF to pass. \\



 Any written unit test utilizes the C Sharp attributes for
Unit Testing provided by the framework. This ensures the system does not
build the testing package into the consumer version of the software.

\section{Changes Due to Testing}
Through various test plans being enacted onto this program and other brute force testing by persons who had no understanding of code we were able to identify certain areas that were lacking. The general trend is that if a command is successfully inputed, that the expected output, that is the GIF, has been produced accurately for the majority of the time. The main issue the project had to be adjusted to is the different methods and input could be incorrectly given. For example, putting negative values for the frames wanted out of GIF. Through these testing methadologies, no big corrections were required but extensive testing revealed edge cases that were not previously considered that needed to be corrected. For example, one of the testers caught a work around the file selection to be able to select JPEG images as our input. Of course, futher testing can always be done to catch a possible edge case that has not been considered before.
\section{Automated Testing}

This test plan has utilized automated testing for the verification of the manipulation functionality that changes the GIF. That is to say that the
exported GIF image will match what is created by the user of our product.
The only tool to be utilized to test this product will be the Microsoft Unit
Test Framework that is native with Visual Studio. Through this unit testing framework, we will have it set up that it automatically does comparisons of the GIF output to the expected output where it can in a quick manner compare the pixel values to ensure complete accuracy. Throughout utilizing this framework, we have always gotten successful results which allowed us to identify other areas wher the majority of the problems occured.		
\section{Trace to Requirements}

		
\section{Trace to Modules}
Refer to Test Plan to see corresponding Tests and Module Guide to see corresponding Modules.
\begin{table}
\centering
\begin{tabular}{p{0.2\textwidth} p{0.6\textwidth}}
\toprule
\textbf{Test} & \textbf{Modules}\\
\midrule
ID1 & M5, M9\\
ID2 &  M5, M9\\
ID3 & M5,, M9\\
ID4 &  M5,  M9\\
ID5 &  M8\\
ID6 & M8\\
ID7 &  M8\\
ID8 &  M8\\
ID9 & MIL\\
ID10 &  MIL\\
ID11 & MIL\\
ID12 & M6\\
ID13 &  M6\\
ID14 & M6\\
ID15 &  M6\\
ID16 &  MIL\\
ID17 &  MIL\\
ID18 &  MIL\\
ID19 &  MIL\\
ID20 &  MIL\\
ID21 &  MIL\\
ID22 &  MIL\\
ID23 &  MIL\\
ID24 &  MIL\\

\bottomrule
\end{tabular}
\caption{Trace Between Requirements and Modules}
\label{TblRT}
\end{table}		

\section{Code Coverage Metrics}
Through an analysis of Trace to Requirements and Trace to Modules sections, the system defined and the system tested almost fully match. Excluding hard to test components of the system, edge coverage of system inputs was tested. \\

GIF manipulation was tested through auto manipulation of a GIF and comparisons to the expected output. This solution provided a guaranteed way to validate output with what a user should expect. However, due to the system depending on user interaction, most testing had to go through a manual test plan for system validation and verification. All possible input types are tested within the test plan, which verifies full edge coverage of user inputs to the system. However not all sequences could be tested manually due to the immense time it would take to complete this task. Thus the system is tested on an edge coverage basis, not a path coverage basis. \\

Finally, hard to test requirements such as non-functional requirement 3.2.1 is relative to specific test groups not available during this development time. Having a person of age MIN\_USE\_AGE (10) test the system was not present during the development phase, thus remains unverified. Furthermore, non-functional requirement 3.3.1 would require a testing of an extreme amount of GIF images to validate the speed requirement is met. Few other examples of hard to test requirements exist, thus passing the system as valid is a safe assumption.

\bibliographystyle{plainnat}

\bibliography{SRS}

\end{document}