wiki:ReportingBugs

Version 3 (modified by lucsch, 16 years ago) (diff)

--

Prerequites

  1. Having a login account : If you don't please contact me through the CREALP's website ​contact page (Lucien Schreiber) for creating one.
  2. Having ToolMap 2 installed and running :
    • For people using the VS cantonal network : go to the G:\CREALP\Project\SIG-SION\ and copy the "latest-bin" folder to your hard drive. Inside that folder is located the !ToolMap2 executable.
    • For other people or other OS (such as Linux or MacOS), we appologize but for now on only internal test is planned. But in a few weeks we may be able to open it to the world.

Reporting bugs

Please consider following guidelines for writing effective bug reports:

  • Please take a moment to check that your problem hasn't already been reported : Search module
  • Be specific. If you can do the same thing two different ways, state which one you used. “I selected Load” might mean “I clicked on Load” or “I pressed Alt-L”. Say which you did. Sometimes it matters.
  • Be verbose. Give more information rather than less. If you say too much, the programmer can ignore some of it. If you say too little, they have to come back and ask more questions. One bug report I received was a single sentence; every time I asked for more information, the reporter would reply with another single sentence. It took me several weeks to get a useful amount of information, because it turned up one short sentence at a time.
  • Be careful of pronouns. Don’t use words like “it”, or references like “the window”, when it’s unclear what they mean. Consider this: “I started FooApp. It put up a warning window. I tried to close it and it crashed.” It isn’t clear what the user tried to close. Did they try to close the warning window, or the whole of FooApp? It makes a difference. Instead, you could say “I started FooApp, which put up a warning window. I tried to close the warning window, and FooApp crashed.” This is longer and more repetitive, but also clearer and less easy to misunderstand.
  • Read what you wrote. Read the report back to yourself, and see if you think it’s clear. If you have listed a sequence of actions which should produce the failure, try following them yourself, to see if you missed a step.

Personnal pages for Testers

  • ChloéCrealp -- Chloé is testing the database part of ToolMap 2

Bibliography