Team 5 Testing Plan Sprint 4

User Testing

Heuristic Evaluations

In the 1990's, Jakob Nielsen created 10 general principles for interaction designs. The term "heuristics" was used because of the broad rules that are not specific to all usablity guidelines but can be adapted for any interface. The user answers either 1 (the system does follow this rule) or 0 (the system does not abide by this rule) to each of the questions and an explanation can be given. This data is both qualitative and quantitative as graphs are created to view a wider range of users feedback. The 10 rules are as followed and adapted by team 5 in order to relate more to the expanded levels, music and overall visual design of each level:

1. Visibility of system status

"The design should always keep users informed about what is going on, through appropriate feedback within a reasonable amount of time." In terms of team 5, this rule didn't seem to follow exactly. Instead, we made this rule relate more to each level being unique and recognisable in itself. The sound also needed to be distinguishable to the action being performed.

2. Match between system and the real world

"The design should speak the users' language. Use words, phrases, and concepts familiar to the user, rather than internal jargon. Follow real-world conventions, making information appear in a natural and logical order." In relation to team 5, we changed this rule to relate more to the sounds and if users distinguish these sounds from using previous windows software. As our background and sounds all relate to different versions of windows, we needed to make sure this was relatable and understood by the user.

3. User control and freedom

"Users often perform actions by mistake. They need a clearly marked "emergency exit" to leave the unwanted action without having to go through an extended process." As the loading screen had not been completed during the process of these user tests, this rule was not marked and had no relation to team 5's features.

4. Consistency and standards

"Users should not have to wonder whether different words, situations, or actions mean the same thing. Follow platform and industry conventions." As music, background and the overall level's visual design should be consistent and recognisable, this rule was used in relation to the consistency of level backgrounds visually and the music being linked to a performed task.

5. Error prevention

"Good error messages are important, but the best designs carefully prevent problems from occurring in the first place. Either eliminate error-prone conditions, or check for them and present users with a confirmation option before they commit to the action." This rule was more related to JUnit testing and was not used to evaluate the users but rather other teammates, to make sure our code always had a subsequent JUnit test.

6. Recognition rather than recall

"Minimize the user's memory load by making elements, actions, and options visible. The user should not have to remember information from one part of the interface to another. Information required to use the design (e.g. field labels or menu items) should be visible or easily retrievable when needed." This was not applicable for team 5's features.

7. Flexibility and efficiency of use

"Shortcuts — hidden from novice users — may speed up the interaction for the expert user such that the design can cater to both inexperienced and experienced users. Allow users to tailor frequent actions." This was not applicable for team 5's features.

8. Aesthetic and minimalist design

"Interfaces should not contain information which is irrelevant or rarely needed. Every extra unit of information in an interface competes with the relevant units of information and diminishes their relative visibility." This rule is really about making sure the team is keeping the content and visual design focused on the essentials. we need t ensure that the visual elements are supporting teh user's primary goals. In this aspect, team 5 uses this question in order to gain an understanding of whether the background, music and overall design takes away from the actual games performance. If this was due to the actual visual elements or in terms of its relation to the game.

9. Help users recognize, diagnose, and recover from errors

"Error messages should be expressed in plain language (no error codes), precisely indicate the problem, and constructively suggest a solution." This was not applicable for team 5's features.

10. Help and documentation

"It’s best if the system doesn’t need any additional explanation. However, it may be necessary to provide documentation to help users understand how to complete their tasks." This was not applicable for team 5's features.

Website used for reference: https://www.nngroup.com/articles/ten-usability-heuristics/

Pluralistic Walkthrough

For team 5's user testing in Sprint 4, a pluralistic walkthrough was also undertaken in order to gain understanding of our features usability. In terms of visual design for each level, as well as music, the pluralistic walkthrough was in relation to the users ability to play the game with the background and with the music. The participants were asked to go to each level, play the game to the end, and then discuss how they felt interacting with the actual game. Questions asked were as followed:

• How did the background effect your gameplay for each level?
• How did the background music effect your gameplay for each level?
• How did the sound effects change your gameplay?

Furthermore, more question were asked to different testers in regards, to the music after the tester completed the game. This was done in order to gain further insight towards the level of unity the game had with the music. Specifically, if the game itself and the music felt to be in "unison" and produce a more complete experience. The following questions were also asked:

• Did the background music across all levels sound to be coming from a similar theme, or the same collection?
• At any moment whilst playing the game, did you feel as if the background music was out of place?
• Were there any specific levels, where you thought the background music did not share a similar theme with the other levels?

Think Aloud

Think Aloud testing was also used through sprint 4 for team 5 as it gives clear understanding of what the participants think of the visual design and music. The qualitative data allows for participants to focus on our features rather then being distracted by the gameplay. The following guiding questions were formulated before tests:

• Does each level background relate to the chosen level theme?
• Does the level background relate to the entire games theme?
• Do the sound effects relate to the action being performed?
• Does the background music relate to the entire games theme?
• Does the background towards the end of the level create tension during gameplay?