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.
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 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.
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 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 POC 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.
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 until 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}
...
...
@@ -106,17 +106,17 @@ The document will summarize the test cases that will be conducted on Snake 2.o,
\subsection{Software Description}
The software will act as a medium of entertainment to the users. It is a Snake Game with added functionality such as different speed and themes option. The implementation of this software is done using Python.
The software will act as a medium of entertainment to the users. It is a snake game with added functionality such as different speed and theme options. The implementation of this software is done using Python.
\subsection{Test Team}
The individuals responsible for testing are Vaibhav Chadha, Usman Irfan and Andy Hameed. Each person will be responsible for testing one's own work. For example, Vaibhav is working on the Graphical User interface of the main screen, hence is responsible for testing it. Usman and Andy will be collaboratively working on the snake game ( which includes recording highest score, current score, snake movement etc.) and will be responsible for testing them sidewise.
The individuals responsible for testing are Vaibhav Chadha, Usman Irfan and Andy Hameed. Each person will be responsible for testing one's own work. For example, Vaibhav is working on the Graphical User interface of the main screen, hence is responsible for testing it. Usman and Andy will be collaboratively working on the snake game ( which includes recording highest score, current score, snake movement etc.) and will be responsible for testing them likewise.
\subsection{Automated Testing Approach}
The most part of this software will include Manual testing. The reason behind this is that a game can be tested better when played as the user can see errors and delays better.
One of the more difficult parts of testing the software will be manual testing. The reason behind this is that a game can be tested better when played as the user can see errors and delays better.
However, automated testing will also be done in order to check the certain functionality of the program. For this, PyUnit testing will be done.
However, automated testing will also be done in order to check certain functionality of the software. For this, PyUnit testing will be used.
\subsection{Testing Tools}
...
...
@@ -124,37 +124,32 @@ PyUnit testing will be used as a testing tool for this program.
See \href{https://gitlab.cas.mcmaster.ca/hameea1/se3xa3/tree/master/BlankProjectTemplate/ProjectSchedule}{Gantt Chart} for details about the testing schedule
\section{System Test Description}
\subsection{Tests for Functional Requirements}
\subsubsection{Area of Testing1}
\paragraph{User Input}
\begin{enumerate}
\subsubsection{Testing of Functions}
\subsubsection{Testing Functions\& Methods}
\item{\textbf{TID1}\\}
Type: Functional, Dynamic, manual
Type: Functional, Dynamic, manual
Initial State: The desktop application starts waiting for the user to enter a command to begin.
Input: The user presses any button key.
Output: The desktop application begins moving the snake towards the Right.
How test will be performed: The test will be done dynamically, that means once the program will be executed the developer will press any key to see if it would run the game, making the snake to move.
How test will be performed: The test will be done dynamically, that means once the program will be executed the developer will press any key to see if it would run the game, making the snake move.
\item{\textbf{TID2}\\}
Type: Functional, Dynamic, manual
Type: Functional, Dynamic, Manual
Initial State: The desktop application executes and displays a screen with a headline \textbf{High Score:} in the top
...
...
@@ -164,15 +159,14 @@ Output: The game would display the highest score of the user from the day they s
How test will be performed: When the game is played for the first time its Highest Score should be 0, the developer plays for a while and tests the score they made by playing should be the highest score when playing the second time.\\
When the game is restarted or turned off the game still holds the highest score.\\
Two more scenarios to test the highest score requirement.\\
E.g., the current highest score is 85:\\
Two more scenarios are present to test the highest score requirement. Take for example a current high score of 85:\\
1. The user beats the highest score, and the highest score is updated to the user's score when playing the next time.\\
2. The user is not able to defeat the highest score and the highest score will still be 85 when they play the game next time.
\item{\textbf{TID3}\\}
Type: Functional, Dynamic, manual
Type: Functional, Dynamic, Manual
Initial State: The desktop application executes and displays the snake at a random location.
...
...
@@ -184,7 +178,7 @@ How test will be performed: The user can track the location of the snake the fir
\item{\textbf{TID4}\\}
Type: Functional, Dynamic, manual
Type: Functional, Dynamic, Manual
Initial State: The snake's food is at a random location.
...
...
@@ -194,12 +188,10 @@ Output: The food reappears on the screen at a random location when the snakes ea
How test will be performed: The developer will test this requirement by moving the snake's head location equal to the food's location. When the snake eats the food, instantly another food should display on the screen at a random location.
\subsubsection{Area of Testing2}
\subsubsection{Testing of Keyboards/Mouse}
\subsubsection{Testing of Keyboard/Mouse Interactions}
\item{\textbf{TID5}\\}
Type: Functional, Dynamic, manual
Type: Functional, Dynamic, Manual
Initial State: The desktop application starts waiting for the user to enter a command to begin.
...
...
@@ -211,7 +203,7 @@ How test will be performed: The test will be done dynamically, that means once t
\item{\textbf{TID6}\\}
Type:Functional, Dynamic, manual
Type:Functional, Dynamic, Manual
Initial State: The game waits for the user to press a direction key to move the snake.
...
...
@@ -223,7 +215,7 @@ How test will be performed: The test will be done dynamically, that means once t
\item{\textbf{TID7}\\}
Type: Functional, Dynamic, manual
Type: Functional, Dynamic, Manual
Initial State: The game waits for the user to press a direction key to move the snake.
...
...
@@ -236,7 +228,7 @@ How test will be performed: The test will be done dynamically, that means once t
\item{\textbf{TID8}\\}
Type: Functional, Dynamic, manual
Type: Functional, Dynamic, Manual
Initial State: The game waits for the user to press a direction key to move the snake.
...
...
@@ -248,7 +240,7 @@ How test will be performed: The test will be done dynamically, that means once t
\item{\textbf{TID9}\\}
Type: Functional, Dynamic, manual
Type: Functional, Dynamic, Manual
Initial State: The game waits for the user to press a direction key to move the snake.
...
...
@@ -260,7 +252,7 @@ How test will be performed: The test will be done dynamically, that means once t
\item{\textbf{TID10}\\}
Type: Functional, Dynamic, manual
Type: Functional, Dynamic, Manual
Initial State: The desktop application executes and displays three modes to be played.
...
...
@@ -272,7 +264,7 @@ How test will be performed: Different modes in the game will be opened using the
\item{\textbf{TID11}\\}
Type: Functional, Dynamic, manual
Type: Functional, Dynamic, Manual
Initial State: The desktop application executes and displays three modes to be played.
...
...
@@ -284,7 +276,7 @@ How test will be performed: If the game is initially set to Light mode. On click
\item{\textbf{TID12}\\}
Type: Functional, Dynamic, manual
Type: Functional, Dynamic, Manual
Initial State: The initial length of the snake would be one-unit length.
...
...
@@ -296,7 +288,7 @@ How test will be performed: The developer moves the snake by pressing the direct
\item{\textbf{TID13}\\}
Type: Functional, Dynamic, manual
Type: Functional, Dynamic, Manual
Initial State: The game is already executed, and the user is playing the game.
...
...
@@ -309,7 +301,7 @@ To test the pause movement, we can think of pausing and resuming of the game as
\item{\textbf{TID14}\\}
Type: Functional, Dynamic, manual
Type: Functional, Dynamic, Manual
Initial State: The snake's movement has been stopped.
...
...
@@ -317,15 +309,13 @@ Input: The user presses the Space key to resume the snake's movement.
Output: The snake's movement has been resumed.
How test will be performed: The developer will test this requirement by pressing the Spacebar key in between the game, will track down's snake location and see if the snake moves on the screen of the Spacebar key is pressed for the second time.
To test the pause movement, we can think of pausing and resuming of the game as two states. If the Spacebar key is pressed odd time it will be in the pause state else, it will be in the resume state.
\subsubsection{Area of Testing3}
How test will be performed: The developer will test this requirement by pressing the spacebar key in between the game, will track down's snake location and see if the snake moves on the screen if the spacebar key is pressed for the second time.
To test the pause movement, we can think of pausing and resuming of the game as two states. If the spacebar key is pressed odd time it will be in the pause state else, it will be in the resume state.
\subsubsection{Testing of the game ending}
\subsubsection{Testing Game Ending}
\item{\textbf{TID15}\\}
Type: Functional, Dynamic, manual
Type: Functional, Dynamic, Manual
Initial State: The snake is not one-unit length..
...
...
@@ -337,7 +327,7 @@ How test will be performed: The developer will test this requirement by moving t
\item{\textbf{TID16}\\}
Type: Functional, Dynamic, manual
Type: Functional, Dynamic, Manual
Initial State: The snake is red colour
...
...
@@ -578,8 +568,8 @@ Currently, we have the following tests that compare to the existing comparison:
\section{Unit Testing Plan}
The PyUnit testing framework would be used to test our desktop application.
\subsection{Unit testing of internal functions}
The PyUnit testing framework will be used to test our source code's functions, this is an automated testing unit, and it provides classes which can ease different testing functions. Such functions that take arguments and return values can be tested in our unit testing. By using PyUnit we can check the robustness of our program, if wrong inputs are given will the program be able to handle such cases without crashing. Besides, the requirement of the program can be tested to see if our program matches with the functional and non-functional requirements of the program. E.g., the function that moves the snake in X-axis and Y-axis can be tested by entering the snake's X, Y location, the axis it wants to go and its direction (up or down for y-axis, and left or right for x-axis). The goal is to test as many functions examining all possible cases which can make our application run smoothly without crashing. \subsection{Unit testing of output files}
The testing of the output files through unit testing will tell the developers if all the test cases designed by them run efficiently. The snake's movement would be compared to the actual output if the user is pressing the UP key and the snake is moving in the respective direction it would pass the unit testing. Testing the output files can also help us to find that if different modes of the game are selected then different rules of the games should be followed. The game being played in the Hard mode could be tested that the snake is not allowed to cross boundaries and this could be compared with automated testing resulting us to know if our output files have passed their unit test.
The PyUnit testing framework will be used to test our source code's functions, this is an automated testing unit, and it provides classes which can ease different testing functions. By using PyUnit we can check the robustness of our program, if wrong inputs are given will the program be able to handle such cases without crashing. Besides, the requirement of the program can be tested to see if our program matches with the functional and non-functional requirements of the program. For example, the function that moves the snake in X-axis and Y-axis can be tested by entering the snake's X, Y location, the axis it wants to go and its direction (up or down for y-axis, and left or right for x-axis). The goal is to test as many functions examining all possible cases which can make our application run smoothly without crashing. \subsection{Unit testing of output files}
The testing of the output files through unit testing will tell the developers if all the test cases designed by them run efficiently. The snake's movement would be compared to the actual output if the user is pressing the UP key and the snake is moving in the respective direction it would pass the unit testing. Testing the output files can also help us to find that if different modes of the game are selected then different rules of the games should be followed. The game being played in the Hard mode could be tested that the snake is not allowed to cross boundaries and this could be compared with automated testing allowing us to know if our output files have passed their unit test.
