Difference between revisions of "Bugs"

From OdaWiki
m (Good examples)
 
(21 intermediate revisions by 7 users not shown)
Line 1: Line 1:
 
== Why bother? ==
 
== Why bother? ==
  
* Help odamex
+
*• This helps improve Odamex by making it more robust ;
* Improve your IT and testing skills
+
*• This will help improve your bugfinding and testing skills ;
* You might get mentioned in the credits if your report was very helpful
+
*You will get mentioned in the credits/contributors list if your report was very helpful (i.e. fixed a major problem).
 +
 
 +
== Bug Tester's Guide ==
 +
 
 +
You can contribute to Odamex by finding new bugs and testing to see if existing bugs have been resolved.
 +
 
 +
=== Resources ===
 +
 
 +
There are several resources open to you:
 +
 
 +
* ► '''[http://odamex.net/bugs Bugzilla]''',
 +
* ► Your '''[[debugger]]''',
 +
* ► A guide to '''[[regression|regression testing]]''',
 +
* ► Our '''[https://github.com/odamex/odamex Github]''' repository.
 +
 
 +
=== Things to do ===
 +
If you are involved in testing, you should generally build Odamex in [[debug]] mode and run it from within a [[debugger]] to obtain helpful information.
 +
 
 +
==== Known bugs ====
 +
If stuck for things to do, please browse through our bug list to see if any bug needs testing. This will usually become obvious if you read the bug comments. Test for the bug and post your own comments. Make sure you are running the latest Odamex code, from our [https://github.com/odamex/odamex Github] repository.
 +
 
 +
==== New bugs ====
 +
Read and search the bug list before you post new bugs. Chances are, the bug has already been noticed by someone else. Bugs you should report commonly include [[incompatibilities]], [[vulnerability|vulnerabilities]] and [[crash|crashes]]. Also report any major annoyances, unintuitive, malfunctioning and missing features. Be reasonable in your assessment and always include exact instructions needed to reproduce the bug.
  
 
== How to report a bug ==
 
== How to report a bug ==
  
 
The [http://odamex.net/bugs Odamex Bug Tracker] is an active list of issues. Look through the bugs to see if the bug you want to report is already listed. Please only post reproducible bugs, with steps to reproduce them.
 
The [http://odamex.net/bugs Odamex Bug Tracker] is an active list of issues. Look through the bugs to see if the bug you want to report is already listed. Please only post reproducible bugs, with steps to reproduce them.
 
If the bug is new and did not appear in a previous [[svn]] revision, it would also be helpful to determine which revision caused the bug. You may need to do regression testing to work this out.
 
  
 
== What to include ==
 
== What to include ==
  
For a [[crash]], be sure to include [[debugger]] information, including the callstack. You need to detail exact steps to reproduce the crash. Including anything relevant, such as the wad, map, OS, compiler, and config.
+
For a [[crash]], the following information should be included in your report (or as much as you can):
 +
*• [[Debugger]] information '''including the callstack'''
 +
*• Steps to reproduce the crash (what you did to make it happen)
 +
*• Other information including WAD files, map, operating system, compiler used and configuration (being server config, etc)
  
== Regression testing ==
+
If the bug appears to be new and did not appear in a previous [[svn]] revision, it would also be helpful to determine which revision caused the bug. You may need to do [[regression]] testing to work this out and include the revision at which the bug was introduced.
  
Find a revision from which the bug was absent. Then find a revision in which the bug was present. Pick a revision in the middle, and test that. Now you know which suspect block of revision to test next. Divide and conquer. A bug in a block of 1024 revisions should only take about 10 tests.
+
== Good examples ==
 +
*• A textbook example is shown in {{Bug|163}}
 +
*• A good report is provided by {{Bug|116}}

Latest revision as of 15:35, 17 January 2019

Why bother?

  • • This helps improve Odamex by making it more robust ;
  • • This will help improve your bugfinding and testing skills ;
  • • You will get mentioned in the credits/contributors list if your report was very helpful (i.e. fixed a major problem).

Bug Tester's Guide

You can contribute to Odamex by finding new bugs and testing to see if existing bugs have been resolved.

Resources

There are several resources open to you:

Things to do

If you are involved in testing, you should generally build Odamex in debug mode and run it from within a debugger to obtain helpful information.

Known bugs

If stuck for things to do, please browse through our bug list to see if any bug needs testing. This will usually become obvious if you read the bug comments. Test for the bug and post your own comments. Make sure you are running the latest Odamex code, from our Github repository.

New bugs

Read and search the bug list before you post new bugs. Chances are, the bug has already been noticed by someone else. Bugs you should report commonly include incompatibilities, vulnerabilities and crashes. Also report any major annoyances, unintuitive, malfunctioning and missing features. Be reasonable in your assessment and always include exact instructions needed to reproduce the bug.

How to report a bug

The Odamex Bug Tracker is an active list of issues. Look through the bugs to see if the bug you want to report is already listed. Please only post reproducible bugs, with steps to reproduce them.

What to include

For a crash, the following information should be included in your report (or as much as you can):

  • Debugger information including the callstack
  • • Steps to reproduce the crash (what you did to make it happen)
  • • Other information including WAD files, map, operating system, compiler used and configuration (being server config, etc)

If the bug appears to be new and did not appear in a previous svn revision, it would also be helpful to determine which revision caused the bug. You may need to do regression testing to work this out and include the revision at which the bug was introduced.

Good examples

  • • A textbook example is shown in Bug 163
  • • A good report is provided by Bug 116