diff --git a/Doc/TestPlan/TestPlan.pdf b/Doc/TestPlan/TestPlan.pdf
index 56e6aa6e4f59b5e46d96a410b4178633b4e2560c..0370ec5a925410e12cde3f4ae98048b3c4a0bc18 100644
Binary files a/Doc/TestPlan/TestPlan.pdf and b/Doc/TestPlan/TestPlan.pdf differ
diff --git a/Doc/TestPlan/TestPlan.tex b/Doc/TestPlan/TestPlan.tex
index 347436ceed324bda6a5cd565c4710f13da1d81bd..0bc0d9060d763207062df90ba299aaaf1ae19f9e 100644
--- a/Doc/TestPlan/TestPlan.tex
+++ b/Doc/TestPlan/TestPlan.tex
@@ -3,8 +3,8 @@
\usepackage{float}
\usepackage[dvipsnames]{xcolor}
\usepackage{booktabs}
-\usepackage {graphicx}
-\usepackage {tabularx}
+\usepackage{graphicx}
+\usepackage{tabularx}
\usepackage{mdframed}
\usepackage{tabto}
\usepackage{keyval}
@@ -12,6 +12,7 @@
\usepackage{hyperref}
% ============= Requirements Table =============
+
\makeatletter
\define@key{test}{type}{\def\test@type{#1}}
@@ -73,10 +74,9 @@
\begin{table}[bp]
\caption{\bf Revision History}
\begin{tabularx}{\textwidth}{p{3cm}p{2cm}X}
-\toprule {\bf Date} & {\bf Version} & {\bf Notes}\\
+\toprule {\bf Date} & {\bf Version} & {\bf Notes} \\
\midrule
-Date 1 & 1.0 & Notes\\
-Date 2 & 1.1 & Notes\\
+October 30, 2016 & 1.0 & Completed Test Plan Rev 0 \\
\bottomrule
\end{tabularx}
\end{table}
@@ -86,95 +86,83 @@ Date 2 & 1.1 & Notes\\
\section{General Information}
\subsection{Purpose}
-The purpose of this project is to recreate a tactical, turn based game much like Fantasy Heroes. The game shall test the macro management skills of the user. The user will have a bunch of information to process in order to determine their course of action for their turn. The game will progress based on user inputs and decisions. However, software like this will involve a wide variety of test cases. The testing for this software will follow the Visual Studio Unit Testing Framework for all automated unit tests. This document will highlight most test cases the software will follow, and provide information on the unit testing framework.
+
+The purpose of this project is to recreate a tactical, turn based game similar to Tactics Heroes. The game shall test the strategical skills of the user by presenting a large quantity of information to process in order to determine the best course of action for the player's turn. The game will progress based on user inputs and decisions. However, such software will involve a wide variety of test cases to ensure proper functionality. A specific category of testing includes automated unit testing, which will follow the Visual Studio Unit Testing Framework. This document will provide a complete overview of test cases the software will follow, and more specifically, provide information on the unit testing framework.
\subsection{Scope}
-Software such as what Blaze Brigade aims to recreate has a complex interaction with the user. Giving the user many options for each decision they make. This means that each one of those options much function properly. Actions such as moving, attacking, equipping a different weapon, et cetera. Each one of these actions will need a proper test case in order to ensure their proper functionality. Other test cases based on functional requirements include, unit properties, menu navigation, structural properties of the game, and handling user input. The non-functional requirements of this software project are based on usability, performance and security. Proper test cases will be orchestrated to fulfil these requirements as well.
+
+Software such as what Blaze Brigade aims to recreate has a complex interaction with the user, giving the user many options for each decision they make. As such, each one of these options, such as moving, attacking, equipping a different weapon, and et cetera, must function properly. Each action requires a proper test case in order to ensure their proper functionality. Other test cases based on functional requirements include unit properties, menu navigation, structural properties of the game, and handling user input. The non-functional requirements of this software project are based on usability, performance and security. Proper test cases will be orchestrated to fulfil these requirements as well.
\subsection{Acronyms, Abbreviations, and Symbols}
\begin{table}[h]
-\caption{\textbf{Table of Abbreviations}} \label{Table1}
+\caption{\textbf{Table of Abbreviations}}
\begin{tabularx}{\textwidth}{lX}
\toprule
\textbf{Abbreviation} & \textbf{Definition} \\
\midrule
- HP & Health points\\
-
- Str & Strength\\
-
- Int & Intelligence\\
-
- Def & Defense\\
-
- Res & Resistance\\
-
- GUI & Graphical user interface.\\
+ HP & Health points \\
+ Str & Strength \\
+ Int & Intelligence \\
+ Def & Defense \\
+ Res & Resistance \\
+ GUI & Graphical user interface \\
\bottomrule
\end{tabularx}
\end{table}
\begin{table}[H]
-\caption{\textbf{Table of Definitions}} \label{Table2}
-
+\caption{\textbf{Table of Definitions}}
\begin{tabularx}{\textwidth}{lX}
\toprule
- \textbf{Term} & \textbf{Definition}\\
+ \textbf{Term} & \textbf{Definition} \\
\midrule
- Unit & A movable character that the user will manipulate to defeat the opponents army.\\
-
- Class & A category of unit type. Different classes have different strengths and weaknesses.\\
-
- Stat & A numerical value that belongs to a unit. There are a variety of stats that make each class of unit unique.\\
-
- Health Points & A stat determining how much damage a unit can take before it dies.\\
-
- Strength & A stat used in calculating physical damage dealt to opposing units.\\
-
- Intelligence & A stat used in calculating magical damage dealt to opposing units.\\
-
- Defense & A stat that lessens the amount of physical damage the unit takes.\\
-
- Resistance & A stat that lessens the amount of magic damage the unit takes.\\
-
- Skill & A stat that determines how skillful a unit is on the battlefield. Used to determine hit rate, and critical hit rate.\\
-
- Speed & A stat that determines how many times a unit will get to attack in combat.\\
-
- Graphical User Interface & A system that interacts with the user through visual representation.\\
-
- Hit Rate & The percent chance that unit A will successfully hit unit B.\\
-
- Critical Hit & Multiplies the damage of a units attack by 3.\\
-
- Critical Hit Rate & The percent chance that unit A will perform a critical hit on unit B.\\
+ Unit & A movable character that the user will manipulate to defeat the opponent's army. \\
+ Class & A category of unit type. Different classes have different strengths, weaknesses, and attributes. \\
+ Stat & A numerical value that belongs to a unit. There are a variety of stats that make each class unique. \\
+ Health Points & A stat determining how much damage a unit can take before it dies. \\
+ Strength & A stat used in calculating physical damage dealt to opposing units. \\
+ Intelligence & A stat used in calculating magical damage dealt to opposing units. \\
+ Defense & A stat that lessens the amount of physical damage the unit takes. \\
+ Resistance & A stat that lessens the amount of magic damage the unit takes. \\
+ Skill & A stat that determines how skillful a unit is on the battlefield. Used to determine hit rate and critical hit rate. \\
+ Speed & A stat that determines how many times a unit will get to attack in combat. \\
+ Graphical User Interface & A system that interacts with the user through visual representation. \\
+ Hit Rate & The percent chance that unit A will successfully hit unit B. \\
+ Critical Hit & Multiplies the damage of a unit's attack by a numerical factor. \\
+ Critical Hit Rate & The percent chance that unit A will perform a critical hit on unit B. \\
\bottomrule
\end{tabularx}
-
\end{table}
\subsection{Overview of Document}
-This document will explain in depth what the plans for testing this project are, and provide a comparison to the existing implementation. In this document, a description for each test case is provided along with expected input and output for each case. This document will referenced by the team of this project when conducting any tests on developer code. A brief description of what automated testing is, and the groups chosen framework to simulate such automated tests. The document will also contain a comparison of the project to the existing implementation (a game called Fantasy Heroes). The goal of the comparison is to determine how much progress has been made, and if any changes are necessary for the scope of the project.
+
+This document will explain in depth the plans for testing of the project, Blaze Brigade, and will provide a comparison to the existing implementation, Tactics Heroes. In this document, a description for each test case is provided along with the expected input and output for each case. This document will be referenced by the team of the project when conducting tests on developer code. This document also provides a brief description of what automated testing is, and the group's chosen framework to simulate such automated tests.
\newpage
\section{Plan}
-
+
\subsection{Software Description}
-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.
+
+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 produce a stable build for the user to interact with, a set of software descriptions need 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.
+ \item \textbf{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 \textbf{Gameplay window:} The map will be created in the gameplay window, in which all of the mouse trigger events would happen to provide interaction 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 \textbf{Menu option:} The menu is the first screen the users will see to select an option to start a new game, learn how to play or exit the game. Each selection will be tested to ensure that it directs the user to the correct use case.
+ \item \textbf{Map creation:} When the terrain is constructed, it will display a field which includes moveable positions and obstacles such as a tree, which dictate positions that a unit may step on. Further testing will need to be conducted on these obstacle nodes to ensure that an unit does not accidentally take an illegal position, or that an unit may take a legal position.
+ \item \textbf{Movement of units:} After a unit has been selected, there shall be a limited amount of highlighted positions that it can move onto. The constraints within the path finding mechanism would need to be simulated as a test case to ensure that the highlighted grid shows the correct layout and the move onto a position is valid to abstain from any invalid operation.
+ \item \textbf{Attack mechanism:} During an attack, the affected unit(s)' 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 \textbf{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}
-\begin{tabularx}{\textwidth}{lllX}
+
+The test team includes all of the members from the development team to encourage that testing takes places at all stages of the development process to meet the central objectives of the project. This requires the involvement of all team members in regular code inspection, producing unit test cases, and the design for suitable user interaction.
+
+\begin{table}[h]
+\caption{\textbf{Description of the Test Team}}
+\begin{tabularx}{\textwidth}{lX}
\toprule
\textbf{Team Member} & \textbf{Testing Type}\\
\midrule
@@ -185,21 +173,29 @@ The test team includes all of the members from the development team to encourage
\bottomrule
\end{tabularx}
\end{table}
+
\subsection{Automated Testing Approach}
-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.
+
+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 better use of resource allocation to move the manual testers to work other aspects of the code or documentation. As the project grows, the automated testing approach would further educate the team in producing more reliable code as well as minimizing the time of manual testing. \\
+
+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 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 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 to run the automated unit tests repeatedly over 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 scripts 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. \\
+
+With the aid of automated testing, there will be less reliance on the team members to constantly check whether a certain feature is correctly implemented for 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}
-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. \\
+
+The following test schedule has been derived from the development plan to ensure that the product is functioning correctly as it continues to evolve. In that regard, 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.
-\begin{table}[!htbp]
-\caption{\textbf{Test deliverable schedule}} \label{Table5}
-\begin{tabularx}{\textwidth}{lllX}
+For additional detail, please consult the \href{https://gitlab.cas.mcmaster.ca/yuens2/Blaze-Brigade/tree/master/Doc/DevelopmentPlan}{Gantt Chart} (link provided).
+
+\begin{table}[h]
+\caption{\textbf{Test Deliverable Schedule}}
+\begin{tabularx}{\textwidth}{llX}
\toprule
\textbf{Deliverable ID} &\textbf{Test Deliverable} & \textbf{Due Date}\\
\midrule
@@ -210,26 +206,27 @@ For additional details, consult the \href{https://gitlab.cas.mcmaster.ca/yuens2/
\bottomrule
\end{tabularx}
\end{table}
-\begin{table}[!htbp]
-\caption{\textbf{Test cases schedule}} \label{Table6}
+
+\begin{table}[H]
+\caption{\textbf{Test Cases Schedule}}
\begin{tabularx}{\textwidth}{lllX}
\toprule
- \textbf{Sprint \#} & \textbf{Due Date} & \textbf{Task} & \textbf{Test Case}\\
+ \textbf{Sprint \#} & \textbf{Due Date} & \textbf{Task} & \textbf{Test Case} \\
\midrule
- 0 & Oct 19 & Proof of Concept & Initial testing to ensure proof of concept demonstration works as planned\\
- 1 & Oct 31 & Menu creation & Main menu re-direct to correct page. Sub menu of each unit to show available commands\\
- 1 & Oct 31 & Unit highlight & Highlight state is active when an unit is selected\\
- 1 & Oct 31 & Unit movement & Unit movement works as designed\\
- 1 & Oct 31 & Unit animation & Unit is being triggered upon each command\\
- 1 & Oct 31 & Full-scope testing & Testing of Sprint 1 to ensure the overall system is correct\\
- 2 & Nov 11 & Add units & Check to see which unit is selected on which team\\
- 2 & Nov 11 & Combat system & Combat attributes work as designed\\
- 2 & Nov 11 & Unit collision & Unit collision logic works as designed\\
- 2 & Nov 11 & Full-scope testing & Testing of Sprint 2 to ensure the overall system is correct\\
- 3 & Nov 16 & Terrain obstacles & Position with obstacles should not be valid moves for units\\
- 3 & Nov 16 & Full army & Check the state of the unit with full army specification on which team\\
- 3 & Nov 16 & Full-scope testing & Testing of Sprint 3 to ensure the overall system is correct\\
- 3 & Nov 16 & Extensive testing & Stress testing of the game as a whole system\\
+ 0 & Oct 19 & Proof of Concept & Initial testing to ensure proof of concept demonstration works as planned. \\
+ 1 & Oct 31 & Menu creation & Main menu re-direct to correct page. Sub menu of each unit to show available commands. \\
+ 1 & Oct 31 & Unit highlight & Highlight state is active when an unit is selected. \\
+ 1 & Oct 31 & Unit movement & Unit movement works as designed. \\
+ 1 & Oct 31 & Unit animation & Unit animation is visible upon movement. \\
+ 1 & Oct 31 & Full-scope testing & Testing of Sprint 1 to ensure the overall system is correct. \\
+ 2 & Nov 11 & Add units & Check to see which unit is selected on which team. \\
+ 2 & Nov 11 & Combat system & Combat attributes work as designed. \\
+ 2 & Nov 11 & Unit collision & Unit collision logic works as designed. \\
+ 2 & Nov 11 & Full-scope testing & Testing of Sprint 2 to ensure the overall system is correct. \\
+ 3 & Nov 16 & Terrain obstacles & Position with obstacles should not be valid moves for units. \\
+ 3 & Nov 16 & Full army & Check the state of the unit with full army specification on which team. \\
+ 3 & Nov 16 & Full-scope testing & Testing of Sprint 3 to ensure the overall system is correct. \\
+ 3 & Nov 16 & Extensive testing & Stress testing of the game as a whole system. \\
\bottomrule
\end{tabularx}
\end{table}
@@ -254,6 +251,8 @@ For additional details, consult the \href{https://gitlab.cas.mcmaster.ca/yuens2/
output = The game behaves as expected from user mouse input.
}
+\addvbuffer
+
\requirements {
name = Game will contain a main menu on screen upon launch.,
type = Structural Dynamic Manual Testing,
@@ -280,7 +279,7 @@ For additional details, consult the \href{https://gitlab.cas.mcmaster.ca/yuens2/
name = Select Load Game from the main menu.,
type = Structural Dynamic Manual Testing,
execution = Load game will be selected and checked if the pre-existing game state is loaded.,
- initialState = Structural Dynamic Manual Testing,
+ initialState = Game is currently on main menu.,
input = Load Game is selected.,
output = Previous saved game state is executed.
}
@@ -570,7 +569,7 @@ For additional details, consult the \href{https://gitlab.cas.mcmaster.ca/yuens2/
\subsection{GUI}
\requirements {
- name = Terrain grid with an unit is constructed onto the GUI window,
+ name = Terrain grid with an unit is constructed onto the GUI window.,
type = Structural Dynamic Manual Testing,
execution = Attempt to launch the game by the user\mbox{,} will prompt a window in which a terrain shall be initialized for the gameplay interactions.,
initialState = Game is not yet opened.,
@@ -581,7 +580,7 @@ For additional details, consult the \href{https://gitlab.cas.mcmaster.ca/yuens2/
\addvbuffer
\requirements {
- name = The game will remain in its current state when the application is minimized,
+ name = The game will remain in its current state when the application is minimized.,
type = Structural Dynamic Manual Testing,
execution = Attempt to minimize the game during the gameplay and shortly after reopen the game to continue from the same game state.,
initialState = Game is initialized and showing the terrain grid.,
@@ -592,7 +591,7 @@ For additional details, consult the \href{https://gitlab.cas.mcmaster.ca/yuens2/
\addvbuffer
\requirements {
- name = The game and its operation will be closed when the application is closed,
+ name = The game and its operation will be closed when the application is closed.,
type = Structural Dynamic Manual Testing,
execution = Attempt to close the gameplay window to end the game and its operations.,
initialState = Game is initialized and showing the terrain grid.,
@@ -605,7 +604,7 @@ For additional details, consult the \href{https://gitlab.cas.mcmaster.ca/yuens2/
\subsection{Unit Movement}
\requirements {
- name = Unit can be selected and deselected when clicked,
+ name = Unit can be selected and deselected when clicked.,
type = Functional Static Automatic Testing,
execution = Attempt to trigger selection and deselection mode on an unit when it is being clicked on from the user.,
initialState = The game is opened and initialized.,
@@ -616,18 +615,20 @@ For additional details, consult the \href{https://gitlab.cas.mcmaster.ca/yuens2/
\addvbuffer
\requirements {
- name = Units are able to move onto any grid position when selected,
+ name = Units are able to move onto any grid position when selected.,
type = Functional Static Automatic Testing,
execution = Attempt to move units anywhere on the grid only when they are selected by being clicked on from the user.,
initialState = The game is opened and initialized.,
- input = The unit is clicked on by user who then select any available grid position placed on the terrain .,
+ input = The unit is clicked on by the user who then selects any available grid position placed on the terrain.,
output = The unit will take the new position and the old position will be empty as expected.
}
+
\newpage
-\section{Comparison to Existing Implementation}
-The final product of Blaze Brigade is supposed to be a turn based, strategy, role playing game. Blaze Brigade is based on a previous implementation of this style of game called Fantasy Heroes. It is important that this project is compared to it's previous implementation in order to determine the future of the project. Depending on the project's progress, there might need to be changes in the scope for the final product. This would mean that if there are some requirements that cant be met within the time constraint, then the scope could be narrowed. Fantasy Heroes helped derive a set of constraints for the project.The subsections of the functional requirements were named, GUI, Game Structure, Unit Movement, Unit Attacking, Combat Damage calculations. The requirements that belong to Unit Movement have been fulfilled, and this section is completed. The GUI section is nearly completed, and everything else still needs to be developed. Seeing that this much work has been made so far, most of requirements of the software will be fulfilled by the end product of this project. If other requirements seem like they are not worth the project's time, then they may be removed from the list of requirements in order to narrow the scope of the project. Comparing Blaze Brigade to Tactics Heroes at this is point shows that the project is becoming much like it was modelled to do by it's requirements.
+\section{Comparison to Existing Implementation}
+
+The final product of Blaze Brigade is a strategical Tactical, Grid based role playing game. Blaze Brigade is based on a previous implementation of this genre called Tactics Heroes. It is important that this project is compared to it's previous implementation in order to determine the future of the project. Depending on the project's progress, there might need to be changes in the scope for the final product. This would mean that if there are some requirements that can't be met within the time constraint, then the scope could be narrowed. Tactics Heroes helped derive a set of constraints for the project.The following subsections of the functional requirements were named, GUI, Game Structure, Unit Movement, Unit Attacking, Combat Damage calculations. The requirements that belong to Unit Movement have been fulfilled, and this section is completed. The GUI section is nearly completed, and everything else still needs to be developed. Seeing that this much work has been made so far, most of requirements of the software will be fulfilled by the end product of this project. If other requirements seem like they are not worth the project's time, then they may be removed from the list of requirements in order to narrow the scope of the project. Comparing Blaze Brigade to Tactics Heroes at this is point shows that the project is becoming much like it was modelled to do by it's requirements.
\section{Unit Testing Plan}
@@ -635,23 +636,16 @@ The Visual Studio Unit Testing Framework shall be used to write and execute the
\subsection{Unit testing of internal functions}
-The automated unit tests will test internal functions of the program by passing controlled input(s) into a function in order to ensure correct behaviour or output of that single function. Each testable function in the program shall thus have corresponding unit tests that test each possible type of input to ensure expected behaviour and/or output of that function under possible edge cases, regular cases, or abnormal cases. Functions that return a value will have their output tested for the expected output, and void functions shall be tested for correct behaviour, such as changes to the model and its state variables. As such, the unit tests will provide thorough whitebox testing of the game's code. Test coverage tools, which are integrated in Visual Studio 2015, will be used as a metric to determine the degree of unit testing code coverage. The goal of the team is to achieve a minimum of 80\% code coverage to ensure that the majority of the code has undergone white box testing, resulting in fewer errors regarding incorrect coding implementation of the functional requirements.
+The automated unit tests will test internal functions of the program by passing controlled input(s) into a function in order to ensure correct behaviour or output of that single function. Each testable function in the program shall have corresponding unit tests for each possible type of input, to ensure expected behaviour and/or output of that function under possible edge, regular or abnormal cases. Functions that return a value will have their output tested for the expected output, and void functions shall be tested for correct behaviour, such as changes to the model and its state variables. As such, the unit tests will provide thorough whitebox testing of the game's code. Test coverage tools, which are integrated in Visual Studio 2015, will be used as a metric to determine the degree of unit testing code coverage. The goal of the team is to achieve a minimum of 80\% code coverage to ensure that the majority of the code has undergone white box testing, thus resulting in fewer errors regarding incorrect coding implementation of the functional requirements.
\subsection{Unit testing of output files}
-The only output file of the game is a window which comprises the visual representation and graphical aspects of the game. To completely ensure proper function of the output file, manual testing must also be taken into consideration to test expected behaviour of the game. In addition, the game engine, XNA Game Studio, handles the majority of the rendition from code to output. Our task does not involve testing proper functionality of the game studio, however, unit testing of the team's code still plays a key role in ensuring proper output. Unit tests for functions that call on the view, as well as unit tests written for the view are necessary to ensuring proper output of the game's visual representation. The unit tests will additionally verify that proper method calls to game studio methods are being executed, most likely with the use of mock objects to mock the actual game visuals, and to verify that these mock objects are being called upon.
-
-\bibliographystyle{plainnat}
-
-\bibliography{SRS}
+The only output file of the game are a collection of windows which comprises the visual representation and graphical aspects of the game. This includes the Main Menu, the How-To-Play, and Game window. To completely ensure proper function of the output file, manual testing must also be taken into consideration to test the expected behaviour of the game. In addition, the game engine XNA Game Studio handles the majority of the rendition from code to output. Our task does not involve testing proper functionality of the game studio, however unit testing of the team's code still plays a key role in ensuring proper output and results. Unit tests for functions that call on the view, as well as unit tests written for the view are necessary to ensuring proper output of the game's visual representation. The unit tests will additionally verify that proper method calls to game studio methods are being executed, most likely with the use of mock objects to simulate the actual game visuals, and to verify that these mock objects are being called upon.
\newpage
\section{Appendix}
-
-
-
\subsection{Symbolic Parameters}
The definition of the test cases will call for SYMBOLIC\_CONSTANTS.