How do I keep testing from becoming boring, for my games or others'?

0 votes
39 views
asked Mar 23 in Authoring by AndrewS (250 points)
recategorized Mar 27 by Alex
Testing is something everyone knows needs to be done, but it can be hard to do it. There's a sameness to it that can be dreadful.

 

Also I find myself thinking in "don't think of a bear" terms of this. If I worry testing will be boring, it becomes boring. So if you've thought of it this way, rephrase it into, how can I get testing to try something new?

 

(Side confession: I've put off potentially repetitive testing of my games and others' with playing FreeCell, which is itself repetitive. Even recognizing this is a help--I think.)

1 Answer

+1 vote
answered Mar 23 by AndrewS (250 points)

This is tricky and subjective. From a programmer's perspective, you definitely want to test new features. You want to make sure you are not bored of your world, because if you are, players may be even less charitable. But it is tough to find anything new.

 

I find that focusing on one class of errors each run-through helps a lot. This goes for technical or nontechnical errors.

  • The stuff that just changed is an obvious first candidate. If you make daily backups of your code and have WinMerge, you have a ready-made chunk of code to test.
  • Maybe on one (early) run, you try default verbs (JUMP, WAVE, THINK, SLEEP)
  • Other acceptable defaults are worth it, too: ABOUT, CREDITS, VERB(S), HINT(S), HELP, WALKTHROUGH
  • Another, you try other commands like pushing or taking anything. In Inform, Juhana Leinonien's Object Response Tests lets you poke at a ton of stuff many different ways without repetitive typing. Even silly troll testing (BURN or CLIMB everything) is handy. Having one funny idea can spread.
  • Another, you try talking to NPCs. Do they make sense? Do they say enough/too much?
  • Another, try the verbs you yourself created for the game. Be sure they are clued and implemented. Try them as they weren't meant to be tried.
  • Try abusing activities in any added extension.
  • Imagine someone with a grudge against you is playing your game. What big things would they find? (Note: this isn't a good attitude to have in general. You may wind up fixing small bugs picturing some nitpicker. But it can help to look for the big stuff.)
    • Imagine they will be upset with any exits not listed.
    • Imagine they will be upset with any items not listed. (e.g. scenery)
  • In Inform, run the game in release mode. It should be roughly the same as debug, but if it has debug messages or you mistakenly marked a verb as "not for release," that will catch it.

 

From a tester's perspective, you can poke at areas you avoided the last time.

This site is now closed.
As of 1st November 2015, this site is a read-only archive. For more information see the intfiction forum post

Welcome to IF Answers, a site for questions and answers about Interactive Fiction.

Technical questions about interactive fiction development tools such as Inform, Twine, Quest, QuestKit, Squiffy, Adrift, TADS etc. are all on-topic here.

Non-technical questions about interactive fiction are also on-topic. These questions could be about general IF design, specific games, entering the IF Comp etc.
...