The software component of the project is governed by various actions such as inputs required, outputs to be shown to the user and certain task computation to fulfill the desired set of requirements. To test the overall system of the project and being able to produce a stable build for the user to interact, a set of software descriptions needs to be covered in this test plan to discuss the main functionality and how they can be tested as outlined below.
\begin{itemize}
\item Mouse input - This is the primary interaction between the user and software to carry out actions within the gameplay. Such action include starting the game, moving the units and giving commands such as to attack the opponent. A test will need to be devised to ensure all mouse clicks are read and their accuracy of the position, to ensure that the resulting trigger is correct.
\item Gameplay window - The map will be created on top of the gameplay window, in which all of the mouse trigger would be happening to interact with the game. The window would need to be tested on all the subtasks it holds such making best use of all the space allocated to it and the ability to close and minimize the window application.
\item Menu option - The menu is the first screen the users will see to select an option to start a new game or learn how to play. Each selection will be tested to ensure that it directs the user to the correct use case.
\item Map creation - When the terrain is constructed, it will display a field which includes moveable position and obstacles such as a tree, which an unit will not be able to move to that position. A further testing will need to be conducted on these obstacle nodes, to ensure that an unit does not accidentally takes an illegal position.
\item Movement of units - After a unit has been selected, there shall be a limited amount of highlighted grids that he can move onto. The constraints within the pathfinding mechanism would need to be simulated as a test case to ensure that the highlight grid show the correct layout and the move onto a position is valid to abstain from any invalid operation.
\item Attack mechanism - During an attack, the following stats and health are taken into consideration to determine who shall be victorious in killing the opponent's unit. The test case will further breakdown the attack mechanism to ensure that the correct drop of health is calculated and presents a fair attack opportunity for both sides.
\item Turn based selection - Both players will alternate turns upon completing their set of actions. A checker would need to be in place to determine that a turn has successfully been completed and shifted to the correct player.
\end{itemize}
\subsection{Test Team}
The test team includes all of the members from the development team to encourage that the testing takes places at all stages of the development process to meet the central objectives of the projects. This requires the involvement of all team members to be involved in regular code inspection, the act of producing unit test cases and interacting with the design as how an user would to properly take on the test-driven development style as initially set in the beginning of the project.
\begin{table}[!htbp]
\caption{\textbf{Description of the test team}}\label{Table4}
An automated testing approach will be introduced in the development process of the project to ensure a new feature or code change does not affect the stability of the master build. Additionally, it would allow a better use of resource allocation to move the manual testers to work other aspects of the code or documentation. As the project tends to grow, the automated testing approach would further educate the team in producing more reliable code as well as able to test the project in a much less time than manual testing.\\
\noindent
Testing tools like Visual Studio Unit Testing Framework will play a big role in the creation of the unit test cases reflecting on the functions that impact the logic behind the game. With a reference to the functions, we can test for desired output with the anticipated inputs and further elaborate the testing scheme by checking for robustness by providing invalid inputs or extreme test cases. Since the automation can cover a large range of testing over a short period of time, it would be feasible to conduct stress testing of the game and conduct the test cases to be operated for a long period of time. Furthermore, the unit test cases are initially set to test features within each class, but a set of these automated test script would eventually cover the system data flow to better understand how the software is interacting with other pieces of code and whether a more efficient design approach is needed in the next development stage.\\
\noindent
With the aid of the automated testing approach, there will be a less reliance on the team member to constantly check whether a certain features is correct while consideration a large magnitude of inputs. The best practice of this technology would be to constantly develop new test cases in parallel to ongoing development process and to run all test scripts multiple times before pushing the source code onto GitLab. Since the nature of a game cannot be fully taken over by automated testing approach, manual testing will still play a part to ensure that the game behaves as it should and feels natural to the user.
\subsection{Testing Tools}
Visual Studio Unit Testing Framework will be the testing tool required to automate the unit test cases throughout each development phase and will cover a wide range of functional and system analysis.
\subsection{Testing Schedule}
See Gantt Chart at the following url ...
The following testing schedule has been derived from the development plan to ensure that the product is functioning correctly as it continues to evolve. In that regards, the schedule can be broken down into the test deliverable and test cases schedule. The test deliverable schedule outlines the required test plans and test reports to be made available for the team members and stakeholders. In contrast, the test case schedule focuses on the internal dynamic of the software outlining the testing period of each of the major development phases. \\
\noindent
For additional details, consult the \href{https://gitlab.cas.mcmaster.ca/yuens2/Blaze-Brigade/tree/master/Doc/DevelopmentPlan}{Gantt Chart} in the Blaze-Brigade/Doc/DevelopmentPlan/ repository.
