Why spend the time performing manual testing?
The importance of manual testing in dynamic applications.
In the current world of development we have a number of tools at our disposal to automate our jobs, we can even create new tools to automate the work that needs to be accomplished. This is great in practice and it should be a skill we lean into. However, there are many instances where we can automate a task, but we should still focus on manual testing to maximize the testing coverage.
In the gaming community, every time you turn on the game you are performing manual testing. That connectivity issue that got you killed, the table you could not shoot over because the collision was offset from the table, or the player that managed to get out of the map. These are issues that will only be reported after a couple controllers have been smashed, but they are issues worth reporting and great issues to identify before the player encounters them.
Currently, I have been spending my down time playing Path of Exile 2. This game is currently in pre-release, so issues are expected. While gaming is a hobby and more readers will have experience with video apps or their web browser, I believe game development is a great use case for why we need manual testing. There will always be a circumstance where a user will break something. This could be a page navigation issue, input field, or the difference in using a PC or mobile application. In games, just the difference in the device you connected with or your screen size can impact your interaction with the game. Below are some examples of issues I have ran into that I will discuss more in depth as you scroll down.
That is not a tree.
While it seems like a small mistake, the red cylinder stands out and breaks the immersion of the tropical biome.
I only wanted to fight one boss.
Why fight one boss when you can duplicate them in their final form?
I just wanted to pause the game and edit my settings…
A couple of the presented issues are minor, but in a game where you lose progression when you die, the major issues that make it into the build can quickly escalate frustration and break the user’s will to continue playing the game. Again, this game is in early access and these issues are expected. However, they make great examples for what needs to be spotted in testing and why manual testing is important. In the video presented, the testing checked that bringing up the menu paused the game, which worked. However, the game no longer remains paused when the user enters the options menu. While this is not much of an issue in a safe area, it does turn into an issue if you’re trying to tune the graphics settings and were not completely out of combat.
The two boss issue was probably my favorite. The reproduction steps were:
Get to the last boss of Act 4 and finish the first phase of combat.
Once the player is knocked to the ground, do not touch the controls and wait for the boss to leave the room to start the second phase.
Set a two minute timer and do not interact with the controls until the timer elapses.
Interact with the controls so the player stands up.
Proceed to the next room and observe the boss has been duplicated.
Now that hard mode has been engaged, attempt to fight the duplicated boss with the entire arena covered in damage effects. As I died, the person attempting to reproduce the issue will also likely die, resulting in a loss of experience and frustration with the boss mechanics.
These are just some examples of issues that could have been spotted with more manual testing. Overall, the game is still great and the experience has been positive, but manual testing is a skill that should be practiced constantly in software testing. While some issues may seem small, testing software the way the end user will interact with it can lead to a better program and experience. It shouldn’t take secondary tools to find out the user couldn’t complete a search because they accidentally added a number to the end of a word or that the post request allows for SQL queries to be passed through an input field.