GNKSA Testing Tips

General Hints

The following list is meant to be helpful in the context of filling in the GNKSA evaluation form.

A few tips that might be of general use:


Tips for specific GNKSA categories

  1. After installing the software (making no changes to the factory default configuration), have it display some articles, and observe. You may have to hunt around a bit for articles containing Reply-To: or Followup-To: headers, or create some yourself.

  2. Feel your way around the program; examine the menus, of the directions on-screen. Consult the documentation, if things aren't that obvious. If they are there, the (separate!) commands for "New Usenet Posting", "Followup", "Reply by Mail" should appear somewhere. Are they clearly named? Do they use standard terminology, i.e. something adhering to the usual followup/reply terminology?

  3. To test this, you'll have to post test messages, and see how the program behaves. Be careful not to annoy others by confronting them with your testing material in places where it shouldn't be!

  4. These should be obvious; just try. If you're really unfamiliar with the type of user interface, of the user interface of the program has a rather steep learning curve, you might have to consult the documentation.

  5. Try initiating a followup to a new posting (create one if that's convenient), a posting that is not a followup to another posting. Do the same to a posting that is a followup; check to see what happens to the Subject: header. Try a few followups to postings with very long subjects as well. There usually should be no need to actually post these followups.

  6. You may have to create a few test messages in order to test whether or not the software interprets the Newsgroups: and Followup-To: headers correctly when you initiate a followup.

  7. Poke around a bit; initiate followups, and inspect their References: header. Look in particular for what happens when following up to an article with an extremely long existing References: header.

    Typical damage in References: header occurs because it has been truncated, because one of the previous newsreaders in the thread did not keep it within proper length limits. The exact rules that determine the validity of a Message-ID are quite complex, and outside the scope of this document.

    As a rule of thumb: Message-IDs begin with `<', followed by a `local part', followed by `@', followed by a `domain part', and ended by `>'. The domain part, basically, is the kind of thing usually encountered in the domain part of an email address, the local part more or less any unique identification string. It typically contains a username, some form of timestamp, and a random number.

    To spot damaged Message-IDs in a References: , look for any text not enclosed within `<' and `>'. Look for text between paired brackets that includes whitespace (spaces, tabs, carriage returns, line feeds), or multiple or zero `@' characters; post a test message, and check that such text is removed.

    Example:

    References: <goodref@fqdn.com> <badhas whitespace@fqdn.com> 
      <bad-no-at-sign.do.main> <good-though-uncommon@192.168.0.1>
      <goodref1@fqdn.com> bad@no.left.bracket> <goodref2@fqdn.com>
      <goodref3@fqdn.com> <bad@no.right.bracket <goodref4@[192.168.0.1]>
    

    Note that server behaviour for invalid input varies between versions and implementations: a broken message may or may not be rejected, but even if it's accepted, safe propagation isn't guaranteed.

  8. Post a test message with a Reply-To: header, if you can't find such a message. Initiate an email reply, and see what happens; you shouldn't have to actually send the reply to draw your conclusion.

  9. Initiate a followup, and try to change that to a mail reply; vice versa, initiate a mail reply, and try to change it into a Usenet followup. In particular, check what happens when combining one message to be offered as a mail message as well as a Usenet posting; the software must never do so by default, neither as a factory default nor as a user preference. Mail copies are to be added only by explicit user request; and if one is sent, it should be clearly marked, in order to prevent confusion. Check that it does.

  10. See what happens on a few followups; check to see that material gets quoted correctly, and that signatures (everyting after `-- ', i.e. dash dash space) gets omitted. Check whether there is some way of indicating which part of a message you're responding to (mouse selection, or some special command).

  11. Generate a new posting, and fiddle around with the Subject: header. The program should not allow posting a message without one, neither should it provide some default string: it really must be there, and it really must be provided by the user.

  12. These depend highly on the particular architecture the software is running on; if you can influence the content of the From: header at all, try some obvious bad addresses.

  13. Be very, very careful when checking this; don't even consider hoping for the best, trusting the software to prevent you from canceling (or superseding) articles you really shouldn't. Experiment on test messages only.

  14. These should be fairly obvious. Try, feel around, observe.

  15. Set a signature, and see what happens. Is the `-- ' included automatically when appending a sig? Is there some checking to prevent inadvertent double occurrences?

  16. Try to post the offending messages, and see what happens. Be careful.

  17. Post a few test messages, and examine them. Browse through the program's configuration options, to check for options to get it to misbehave by default.

  18. Inspect the documentation if this isn't obvious at first glance.

  19. In the pathological cases, this can be very hard to test. However, usually a good idea can be obtained from observing the program closely. Documentation might help too.