10/26/2018 & 1.0 & Andy added section 1.0 and 7.0\\
Date 2 & 1.1 & Notes\\
\bottomrule
\end{tabularx}
...
...
@@ -51,8 +52,14 @@ Date 2 & 1.1 & Notes\\
\section{General Information}
\subsection{Purpose}
Testing will be conducted to ensure that the software meets the requirements set in the original development as well as the new requirements that are set as enhancements to the original game. The generated test cases will also serve as guiding rules to for developing code using TDD.
The reinvention of the Snake game as Snake 2.o will involve new features such as custom speed, high score menu, customizable themes and a multiplayer mode if time permits. These new features, along with the requirements set for the original implementation of the game will be tested to detect any bugs or errors. The use of the Pygame library allows for a GUI that will enable integrated and system testing. Peers will be able to demo the game as if it was completed and catch any errors or bugs by doing so. White box testing will be used as well on the existing code that was used for the Proof of Concept demonstration. Automated testing will be implemented using the unittest framework built into Python. Aspects that have not yet been implemented or would be hard to detect visually, like for example the speed of the moving snake, will be tested using static analysis along with automated testing.
\subsection{Scope}
Testing will cover all of the behaviours mentioned below. Note that this is a general overview and more details are provided further on in the document.
The expected behaviour is to have a menu that leads to the game screen. Once the game is initiated, the objective is for the snake to eat the food block and continue doing so the snake dies. Each time the snake eats, the score should increase by one and the length of the snake body should increase by some predetermined number of blocks. The snake dies if it runs into itself by looping around its body or by hitting the edges of the game window.
Looking at the Git respository for the original game, there are no test modules that can be seen so the test cases will be based on any test cases generated by the three team members.
\subsection{Acronyms, Abbreviations, and Symbols}
...
...
@@ -63,8 +70,11 @@ Date 2 & 1.1 & Notes\\
\toprule
\textbf{Abbreviation}&\textbf{Definition}\\
\midrule
Abbreviation1 & Definition1\\
Abbreviation2 & Definition2\\
T1D1 & Test 1 ID 1\\
TDD & Test-Driven Development\\
POC & Proof of Concept\\
GUI & Graphical User Interface\\
N/A & Not Applicable\\
\bottomrule
\end{tabularx}
...
...
@@ -77,8 +87,11 @@ Abbreviation2 & Definition2\\
\toprule
\textbf{Term}&\textbf{Definition}\\
\midrule
Term1 & Definition1\\
Term2 & Definition2\\
Pygame & open source Python library used to create game graphics\\
White Box testing & a method of testing where the code is examined in order to create the test cases. This mostly corresponds to testing functional requirements based on the description of functions and methods in each component module\\
Black Box testing & a method of testing where the code is not examined in order to create the test cases. This mostly corresponds to non-functional requirements\\
Test Driven Development& a method of developing software using a set of test cases that are written prior to the code itself. The test cases can identify how functions and methods should behave\\
PyUnit& Testing framework for python software development\\
\bottomrule
\end{tabularx}
...
...
@@ -86,6 +99,8 @@ Term2 & Definition2\\
\subsection{Overview of Document}
The document will summarize the test cases that will be conducted on Snake 2.o, a remake of the orignal snake game using Python and the Pygame library. Several testing techniques are used including automated testing, white box testing, black box testing, manual testing, integration and system testing and static analysis. The document will outline the plan for testing, a description of the test system with non-functional and functional test cases, unit testing and POC testing, and other details pertaining to the testing of Snake 2.o.
\section{Plan}
\subsection{Software Description}
...
...
@@ -544,15 +559,21 @@ The testing of the output files through unit testing will tell the developers if
\section{Appendix}
This is where you can place additional information.
\subsection{Symbolic Parameters}
The definition of the test cases will call for SYMBOLIC\_CONSTANTS.
Their values are defined in this section for easy maintenance.
N/A
\subsection{Usability Survey Questions?}
This is a section that would be appropriate for some teams.
The following questions will be asked to peers when conducting integrated and system testing:
\begin{itemize}
\item Does the game lag at any point?
\item Does the game maintain consistent speed performance as you advance through the game?
\item Is the main menu clear and understandable?
\item Is the game exciting to play?
\item Is the game visually appealing? Does it look visually complete?
Other questions will be asked to validate the game, mostly focusing on non-functional requirements whose completeness is subjective to the user.
