Sprint 3 Testing

For testing in sprint three, coding added in previous sprints was largely tested following the previous sprint therefore testing focussed on newly added components and extending previous ones.

Automated Testing

Most coding elements were covered utilising automated testing to ensure it was properly covered for all builds of the game as the final major integrations between teams would occur by the end of this sprint.

Functional Testing

Testing for the GUI elements was carried over from the previous sprint alongside some additional GUI testing for the added shop screen

ShopMenuDisplay

In summary there are a few things that the shop UI will need to be tested on. Firstly, when different item image button is clicked, specific description and name of the item should be displayed on the UI. The system also checks if player has the item selected equipped or not and if it is the case the purchase button will dynamically be changed to equipped. When button is changed to equipped, the button is disabled which disables the user's ability to check if user can purchase selected item. If player is not equipped with selected item and player attempts to purchase item, the system will check to see if player has sufficient amount of funds to make the purchase. However, if player does not have sufficient funds, the purchase button will not dynamically change and if player does have sufficient funds - then money is deducted (as shown on player's HUD and on the shop UI of how much money player has) and the equipped button will then appear. The system is also programmed to equip player with most recent purchased item and ensures that it is updated to most current player state.

Testing Method: Testing should be done as linked here

PlayerLightingComponent lighting

As the player is holding a torch during the game, a halo of light is around the player while they have a torch. As it is a visual aspect of the game it is not able to be automatedly tested therefore in order to ensure it is correctly working, functional testing was used.

Testing Method: A glow of light should surround the player during the game. When the player moves the light should follow their body. They should then wait until the torch runs out (100 seconds) and the light around the player should disappear. When the player moves the light should still not be present.

PlayerLightingComponent torch animations

As the player is holding a torch during the game, the torch should stay with the player and animate as it is active. As this is visual animations the only way to test this is through visual confirmation in functional tests.

Testing Method: A torch should be in the players hand. When the player moves the torch should stay with the player no matter the direction (staying linked to the players hand). When the torch runs out (in 100 seconds) the torch should no longer be attached to the player. If a torch is bought in the store, upon existing the store the player will once again have a torch.

UnlitRenderer, RenderFactory & Renderer

Within the pre existing renderer a new renderer was added that renders elements without the lighting effect, which was necessary for the HUD health and cooldown bars. As this is a visual effect of the HUD elements not being effected by the lighting it had to be tested functionally.

Testing Method: Enter the game, the HUD health and cooldown bars should render unaffected by the lighting (fully visible). When lighting conditions change (torch going out or walking towards an environmental torch) this should not change.

User Testing

As many new featured were added to the game this sprint, user testing was performed on elements added to ensure they were appropriate and functioned correctly within the pre existing game. This included the design and interactions for the shop screen, the new shop NPC and the newly added weapons. These user testing documents included: Sprint 3: User Testing Shopkeeper: Design, Sprint 3: User Testing Shop: Shop popup box and buying system, Sprint 3: User Testing Player: Initial New Weapon Designs, Sprint 3: User Testing Player: Final Weapon Designs.

Future Testing

As there is only the final polishing sprint left a lot of work in testing will go into user testing to finalise design decisions and less into automated code testing (though to ensure the game is working correctly on finalisation it is important these tests are still worked on during the final sprint to increase coverage)

Automated Testing

• Improving current Junit tests/adding more to increase coverage to ensure correct integration and individual functionality
• Optional: exploring automated testing for GUI elements to ensure correct functions consistently

Functional Testing

• Maintaining aspects of some current functional tests as means of verifying bug testing (specifically the displays)

User Testing

• Testing the final design of the shop buying screen
• Testing the final game as a whole for difficulty balancing
• Testing the final game designs / aesthetic to find out of place elements
• Testing the final game to check for emotional goals being achieved