The Tester: A reality show I just might watch

“The Tester, which will debut on February 18th, will star 11 video game fanatics who will compete against each others to determine who’s got the best skills to become a game tester.  The grand winner will be offered a job at SCEA San Diego plus $5000 as a signing bonus”  

The Tester: A New Reality Show for Gamers

What an interesting idea.   I have no idea how boring such a show would be to watch but if it’s testing games ok, I can see that.   With all due respect to the MS Access product group I suspect watching those testers test would be quite boring to an outsider.

It’s also quite interesting to talk to testers from Microsoft.   Yes, they test for the standard kind of stuff.  But I’m told the best kind of tester is a truly twisted, warped person.  Someone who takes great delight in tormenting the developer.  Ok, that last sentence is an exaggeration.  However I’ve learned that it’s impossible to make a user proof program.  A user will always, always figure out something totally different than what you meant. 

I’ve also learned that very few bugs get reported.    I do my best to fix bugs as soon as I hear about them because I’ve come to the realization that some of my bugs must be affecting many people and yet I only get one or two complaints.

I think I’m going to do my best to actually phone each person who sends me an email mentioning a problem or bug.  Especially a problem because this means I didn’t make the program smart enough or the documentation good enough.    If they mention a bug well, I’ll just fix it ASAP.

BTW I also don’t PS3 console (or any gaming system) or a television.

2 thoughts on “The Tester: A reality show I just might watch”

  1. I’ve been strongly considering finally incorporating bug logging in my apps. My last big project could have benefitted from it (I actually did log some user actions to see how they were using the current app in order to figure out priorities for a new search feature), though the users were pretty good bug reporters.

    My newest project is going to be tough. It’s an effort to revive an app that’s slowly fallen out of use because it didn’t keep up with changing requirements, so I’ve got to redesign it and introduce new features to win the users back over. But they are the type of users who don’t have time to spend an hour testing a new release, so I’m not going to get good bug reports.

    So I’m probably going to implement bug logging. Obviously, that’s going to log only the errors that happen inside my error handlers, but I’m wondering how many unforeseen bugs I can trap with form-level error handlers.

    Anybody have any thoughts?

  2. I enabled this once on an app about 13 years ago. Now if I had indeed looked at the error log I would’ve solved one problem before they reported it.

    But what I’ve found is extra frustration from the developers viewpoint. Errors in code while I’m working now get dropped to another subroutine. You can’t do the very convenient insert a Resume line, set the program execution to that line and then go back to the offending line of code.

    I do this a lot in the Auto FE Updater as well so I can display a message form with extra buttons. So far that works well because these messages are generally displayed due to a configuration file or other problem external to the utility. Not a code problem.

    However I’m going to be adding some logic to now log all the errors in the Auto FE Updater. Including code errors. So I’m going to be confronting this irritation very shortly. Not sure what I’m going to exactly. Maybe my standard error handling routine will have some code added so if it’s running in the IDE it displays a msgbox in the IDE. Given that I have 426 procedures this is going to take a while.

    Also the routine which logs the error to an Access MDB file can’t in turn log any errors to the MDB file. Infinite loop. So in that case I’m going to be added to an errorlog.txt file on the server. And warning the dev who opens up the Auto FE Updater utility that such a file exists which they should review.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>