Thursday 28 October 2010

Why Software Needs QA

(or Blow this for a Game of Soldiers)

Yesterday, I returned my copy of Medal of Honor for a refund due to it being faulty. I went prepared for a fight as refunding software is notorious for being "against policy" at many places.  The reason for this attitude was that my complaint was that the software was faulty, not the disc.

I had only played the game for a total of a few hours, but had hit two very similar, critical issues. In one mission I was instructed to infiltrate a warehouse only to discover I couldn't open the door. After some time searching for another way in, I became suspicious and checked on-line. It seemed many people were getting stuck in all sorts of places due to issues like this. Restarting from the last save point made no difference, I had to start the mission again from the beginning. This time, another member of the squad, who was MIA in my first run through, opened the door for me.
In the next mission, a team mate said "follow me" and ran into a building. I tried, I really did, but for some reason I could not walk through the open door! At this point I popped the disc and took it back to the shop.

Anyway.
There is no way I should be hitting bugs like this in released software. As a developer I can understand and forgive the odd issue (coding is a complicated business), but glaring errors that affect many people should really have been picked up before release and any competent play-testing should have found these issues.

I can only imagine that it was tested by people who knew what they were supposed to do and followed a precise path as it seems that some sort of event was failing to be triggered. This has been my argument for QA or testers for software in the past. Programmers should not be trusted to be the only testers of their own code, they will only test for paths they can think of and it is was they didn't think of that needs testing the most.

No comments: