This document describes the test plan for the Gifitti application developed for 3XA3 at McMaster University.
\section{General Information}
\subsection{Purpose}
The purpose of the testing plan is to establish a set of tests that will test the product in its entiretiy to ensure that it fufills the intendend purpose. This would be accomplished through verifying if Gifitti satisfies the different functional and non-functional requirements that were assigned to it. Having test plans for any product is essential to be able to understand how well the product is satisfying the clients needs and if there are rooms for improvement.
\subsection{Scope}
This testing plan is utilizing different testing methods, automated and user created, and various techniques, black box and white box testing, to establish if the project has any need of improvement. Two different products will be analyized through these tests, the Proof of Concept and the first iteration of the final product. Proof of Concept will be tested to ensure that a basic representation of the product was demonstrated while the requirements should be tested when the first iteration of the final product is completed.
\subsection{Acronyms, Abbreviations, and Symbols}
...
...
@@ -87,17 +87,21 @@ Term2 & Definition2\\
\end{table}
\subsection{Overview of Document}
The testing plan is broken up into distinct parts. Under the heading Plan, the basic information will be given on the product and the tests. System Test Description will contain the specific tests for the functional requirements stated for the product. These tests will broken down into what type of tests they are and the results they achieve depending on their specific input. Test for nonfunctional requirments will follow the same format where input will be given and the output will be measured for all of the provided nonfunctional requirements. Under tests for proof of concept, the same format will be utilized as the functional testing but it will not be testing
the requirements for the project but for the goals of the proof of concept. Furthermore there will be tests to compare Gifitti to the
original product it was based on and unit testing plans to ensure correct output is achieved through proper internal functions.
\section{Plan}
\subsection{Software Description}
Gifitti is a software prodcut
\subsection{Test Team}
The team to implement the test plan for the project will be Pavle Arezina, Riley McGee, Nicolai Kozel
\subsection{Automated Testing Approach}
This test plan will not utilize an automated testing approach towared Gifitti since the project centers around a graphical manipulation
of the GIF.
\subsection{Testing Tools}
Tools to be utilized will be
\subsection{Testing Schedule}
See Gantt Chart at the following url ...
...
...
@@ -381,308 +385,3 @@ positive and negative aspects of the program. The questionaire can be found at \
Oct. 24 & 1.1 & Updated section 1 and 2 with pertinant information.\\
\bottomrule
\end{tabularx}
\end{table}
\newpage
\pagenumbering{arabic}
This document describes the test plan for the Gifitti application developed for 3XA3 at McMaster University.
\section{General Information}
\subsection{Purpose}
The purpose of the testing plan is to establish a set of tests that will test the product in its entiretiy to ensure that it fufills the intendend purpose. This would be accomplished through verifying if Gifitti satisfies the different functional and non-functional requirements that were assigned to it. Having test plans for any product is essential to be able to understand how well the product is satisfying the clients needs and if there are rooms for improvement.
\subsection{Scope}
This testing plan is utilizing different testing methods, automated and user created, and various techniques, black box and white box testing, to establish if the project has any need of improvement. Two different products will be analyized through these tests, the Proof of Concept and the first iteration of the final product. Proof of Concept will be tested to ensure that a basic representation of the product was demonstrated while the requirements should be tested when the first iteration of the final product is completed.
\subsection{Acronyms, Abbreviations, and Symbols}
\begin{table}[hbp]
\caption{\textbf{Table of Abbreviations}}\label{Table}
\begin{tabularx}{\textwidth}{p{3cm}X}
\toprule
\textbf{Abbreviation}&\textbf{Definition}\\
\midrule
Abbreviation1 & Definition1\\
Abbreviation2 & Definition2\\
\bottomrule
\end{tabularx}
\end{table}
\begin{table}[!htbp]
\caption{\textbf{Table of Definitions}}\label{Table}
\begin{tabularx}{\textwidth}{p{3cm}X}
\toprule
\textbf{Term}&\textbf{Definition}\\
\midrule
Term1 & Definition1\\
Term2 & Definition2\\
\bottomrule
\end{tabularx}
\end{table}
\subsection{Overview of Document}
The testing plan is broken up into distinct parts. Under the heading Plan, the basic information will be given on the product and the tests. System Test Description will contain the specific tests for the functional requirements stated for the product. These tests will broken down into what type of tests they are and the results they achieve depending on their specific input. Test for nonfunctional requirments will follow the same format where input will be given and the output will be measured for all of the provided nonfunctional requirements. Under tests for proof of concept, the same format will be utilized as the functional testing but it will not be testing
the requirements for the project but for the goals of the proof of concept. Furthermore there will be tests to compare Gifitti to the
original product it was based on and unit testing plans to ensure correct output is achieved through proper internal functions.
\section{Plan}
\subsection{Software Description}
Gifitti is a software prodcut
\subsection{Test Team}
The team to implement the test plan for the project will be Pavle Arezina, Riley McGee, Nicolai Kozel
\subsection{Automated Testing Approach}
This test plan will not utilize an automated testing approach towared Gifitti since the project centers around a graphical manipulation
of the GIF.
\subsection{Testing Tools}
Tools to be utilized will be
\subsection{Testing Schedule}
See Gantt Chart at the following url ...
\section{System Test Description}
\subsection{Tests for Functional Requirements}
\subsubsection{Open GIF}
\paragraph{The User is Able to Open a GIF from a specified location}
\begin{enumerate}
\item{Select proper formatted gif- id1\\}
Type: Manual Functional.
Initial State: Program loaded; no GIF Loaded.
Input: File name.
Output: System loads gif into memory, displays it to the user in the gif view.
How test will be performed:
\begin{enumerate}
\item{Launch the program}
\item{Select Open}
\item{From the Open dialog specify a path to a known gif image}
\item{After the image is loaded verify that it is being displayed, and resides in system memory}
\\
\end{enumerate}
\item{No File Selected in File Dialog-id2\\}
Type: Manual Functional.
Initial State: Program loaded; no GIF Loaded.
Input: No file path.
Output: No image loaded.
How test will be performed:
\begin{enumerate}
\item{Launch the program}
\item{Select Open}
\item{Select open option with no file path specified}
\item{Verify program remains open, and no image is loaded}
\\
\end{enumerate}
\item{Close File Dialog-id3\\}
Type: Manual Functional.
Initial State: Program loaded; no GIF Loaded.
Input: None.
Output: No image loaded.
How test will be performed:
\begin{enumerate}
\item{Launch the program}
\item{Select Open}
\item{Close the file dialog}
\item{Verify program remains open, and no image is loaded}
\\
\end{enumerate}
\item{Open random non gif file-id4\\}
Type: Manual Functional.
Initial State: Program loaded; no GIF Loaded.
Input: File that is not a GIF.
Output: No image loaded.
How test will be performed:
\begin{enumerate}
\item{Launch the program}
\item{Select Open}
\item{Try and select a file that is not a GIF or specify a file path to a known file}
\item{Verify program remains open, and no image is loaded}
\\
\end{enumerate}
\end{enumerate}%End of Functional requirements
\subsubsection{Area of Testing2}
...
\subsection{Tests for Nonfunctional Requirements}
\subsubsection{Area of Testing1}
\paragraph{Title for Test}
\begin{enumerate}
\item{test-id1\\}
Type:
Initial State:
Input/Condition:
Output/Result:
How test will be performed:
\item{test-id2\\}
Type: Functional, Dynamic, Manual, Static etc.
Initial State:
Input:
Output:
How test will be performed:
\end{enumerate}
\subsubsection{Area of Testing2}
...
\section{Tests for Proof of Concept}
\subsection{Opening a GIF file for playback}
\paragraph{Open GIF}
\begin{enumerate}
\item{OpenGif-01\\}
Type: Manual Functional
Initial State: Program must be in normal state (form window is open and playback window is blank).
Input: File
Output: GIF is shown in playback window of the form.
How test will be performed: Click open button, select a file of type .gif, and verify that the GIF loads and begins to playback within the form window.
\end{enumerate}
\subsection{Saving a GIF file's frames}
\paragraph{Save GIF}
\begin{enumerate}
\item{SaveGif-01\\}
Type: Manual Functional
Initial State: Program must be in playback state (form window is open and playback window is playing GIF).
Input: GIF File
Output: GIF's frames are saved as .bmp in folder specified.
How test will be performed: Click save frames button, select a folder, and verify that the GIF's frames are saved to the specified folder as .bmp.
\end{enumerate}
\section{Comparison to Existing Implementation}
\subsection{Graphics/UI}
\begin{enumerate}
\item GIF playback resolution is the same or better than Gif Viewer.
\item Program has the same button scheme as Gif Viewer (Open button to open file, Extract Frames button to save frames).
\item Program has a help menu available that is similiar to Gif Viewer, but is available at all times.
\item Program's color scheme and design resembles Gif Viewer.
\end{enumerate}
\subsection{Performance}
\begin{enumerate}
\item GIF playback is at the same smoothness/framerate or better than Gif Viewer.
\item Opening and saving a file takes the same amount of time or less than Gif Viewer.
\end{enumerate}
\section{Unit Testing Plan}
\subsection{Unit testing of internal functions}
\subsection{Unit testing of output files}
\bibliographystyle{plainnat}
\bibliography{SRS}
\newpage
\section{Appendix}
This section contains symbolic parameters for this document and the usability survey that will be delivered
to a focus group upon initial completion of the application.
\subsection{Symbolic Parameters}
The definition of the test cases will call for SYMBOLIC\_CONSTANTS.
Their values are defined in this section for easy maintenance.
\subsection{Usability Survey Questions}
The survey will be deliverered in the same format as the Questionaire for User Interface Satisfaction. This
questionaire is composed of various questions pertaining to several sub categories on a 0-9 scale. This includes the screen,
terminology and system information, learning, and system capabilites. It also allows the user to list the most
positive and negative aspects of the program. The questionaire can be found at \href{http://garyperlman.com/quest/quest.cgi?form=QUIS}{garyperlman.com}
