Edited online

Module Five Project Log - Team Reflection.md

@@ -18,20 +18,34 @@ As a team, you will routinely conduct reviews based on your progression towards
 
 ## **What parts of the plan did the team perceive to go well in relation to the last stage evaluation?** ##
 
+In the alpha testing stage, we were not always consistent in updating our traceability matrix or test plan document accordingly to reflect changes or additions that we made to the game features. For the beta testing, we were more thorough in updating any game design documents that needed it to reflect these changes. This helped us avoid duplicating work or wasting time during our playtest to make changes to the game design documents or actual prototype. (*Group Decision*).
+
+In the alpha testing stage, we were not prepared to do QA testing until almost the last minute. This made the testing process somewhat stressful and did not allow us much time to resolve more complex bugs that were found while testing (*Group Decision*). We stepped back and readjusted our timeline to get back on schedule. We also had backup plans in case a tool or technique we were using failed to be successful—this helped us immensely and ensured that we had a playable prototype ready on schedule for testing (*Group Decision*). As a result, we were able to start fixing any additional bugs that were found immediately and have continued to test as we implemented those fixes.  
+
 -----------------------------------------------------------------------------------------------------------------
 
 ## **What parts of the plan did the team perceive to go wrong in relation to the last stage evaluation?** ##
 
+For the most part, the team considered this testing stage an overall success (*Group Decision*). However, we do see room for improvement in our test plan process. There were issues that we noticed during our alpha testing that we thought were not ‘game-breaking’ but just took away from the end-user experience in terms of how difficult the mechanics were (*Group Decision*). A primary example of one of these issues is the jump pad in the stomach. At the time, we believed that this was just a bit too difficult of a jump to make successfully, but we were unsure that it needed to be resolved because it was still working. However, once we fixed other issues in the game the question of whether this jump pad was an issue or not became glaringly obvious—not only is it an issue, but it can almost be considered a game-breaking issue to a player who was not involved in the game development process (*Brigitte Rollain, Daniel Noel*). In retrospect, we should have focused on every issue even if we weren’t sure that it was truly a problem (Joe Rafferty). It is important to have a fix ready to implement if it becomes a larger issue once other bugs are addressed (Kylie Nencetty). In the future, we will be broadening our focus when implementing bug fixes to a wider array of what we consider a ’bug’ (Jenji Sayre).
+
 -----------------------------------------------------------------------------------------------------------------
 
 ## **How were the previous evaluations wrapped into this latest stage?** ##
 
+Previous evaluations were wrapped into the beta testing by going through each alpha test case scenario again. We were sure to test every scenario again, even if it had previously passed the test case scenario in the alpha stage. By doing this, we were able to determine that none of our bug fixes had introduced new bugs to previously tested features (*Group Decision*). We also continued to test frequently throughout the development process prior to the formal beta testing stage (*Group Decision*).
+
 -----------------------------------------------------------------------------------------------------------------
 
 ## **What would you do differently to improve the process?** ##
 
+To improve our testing process, we would like to have handed out our alpha and beta prototypes to our friends and family for unbiased playthrough feedback (*Joe Rafferty, Kylie Nencetty, Daniel Noel*). There are often things within the game that as developers, we easily understand. However, what seems obvious to the developers may not seem as obvious to an outside player (*Jenji Sayre*). We tried to think in terms of the end-user experience, but it can be hard to completely detach yourself from the vision of the game (*Kylie Nencetty*). We have now begun showing the beta test to friends and family to get their feedback, but it would have been beneficial to have started doing this earlier in the process (*Group Decision*). 
+
+Another improvement to our testing process would have been to include sound integration earlier in the project development (*Kylie Nencetty*). The idea of creating and integrating sounds was overlooked until alpha testing when it became clear we had created an almost entirely silent game (*Brigitte Rollain*). For immersion, we thought it was important to start working on adding sounds to certain features of the game (*Jenji Sayre*). However, because this was an afterthought it was not easy to include this in our schedule. We have been having multiple roles working on adding sounds here and there throughout the testing phase, which is not ideal (*Daniel Noel, Joe Rafferty*). By doing this, we run the risk of duplicating work and losing focus on other aspects of our bug corrections (*Group Decision*). For example, we achieved some great sound integration in our level but forgot to complete work on correcting one of the bugs prior to testing (*Daniel Noel*). We have since gone back and fixed the bug, but had we remembered to include sound in our original game design document this mistake could have been circumnavigated (*Daniel Noel*). 
+
 -----------------------------------------------------------------------------------------------------------------
 
 ## **Were there any tools or techniques that you did not find helpful in the success of your project development? Why?** ##
 
+Some tools and techniques that we found were not helpful in the success of our project development were previously discussed in the Module Four Project Log wiki page. However, we did come across a technique that failed us in this latest stage as well. We wanted to try various ways to address our issues in the capillaries. One of the solutions we discussed was using the hollow brush tool in Unreal Engine to construct the capillaries as one large static mesh (*Joe Rafferty, Brigitte Rollain*). However, our level designer found this technique to be too time-consuming and difficult to use. The level designer had to click on every face and extrude them but realized that it just wasn’t coming together as it was envisioned (*Brigitte Rollain*). Because of this, we quickly pivoted and began reconstructing the capillaries using one of the other methods that we had previously discussed (*Jenji Sayre, Daniel Noel*).
+
 -----------------------------------------------------------------------------------------------------------------