How to make a bug report

[Nick Taylor]

Effective Bug Reporting
An effective bug report communicates well with the BMS developers and avoids confusion or miscommunication.

Before you add a new bug report, please use the search function to check if the same bug has been reported or not. A good bug report should be clear and concise without any missing key points. Any lack of clarity leads to misunderstanding and slows down the development process as well. The most important point that you should keep in mind is not to use a commanding tone or harsh words in the report. This breaks the morale and creates an unhealthy work relationship. Use a suggestive tone. The import information that a bug report must communicate is:

• Version and Build number

• Detailed Description

• Pictures

• Example files*

• Crash logs*

• Dump Files (*.dmp)

• Reproducibility Procedure

• Expected Behavior

• .cam, .tac, .twx, .ini, .vhs (ACMI), … if applicable depending on type of bug

The report should clearly answer how the test was performed and where the defect occurred exactly. The reader should easily reproduce the bug and find where the bug is. Hence it is best to split multiple issues into separate bugs. This ensures that each bug can be handled individually.

Always use KTO as your standard Theater of Operations and the current Vanilla installation without any further modifications!
If you discover a bug in another theater, please reproduce it in KTO as well. This can already exclude some sources of error.

It is very important to layout exactly what you did, in a step-by-step manner if necessary. Try to include all the information that you think would be helpful, but don’t be overly verbose. Now try to explain what happened the best you can. If you received an error message, it is always important to include the full, specific message. If you’re having trouble explaining it, pictures can be better than 1000 words. Use the attachment option whenever reasonable. Finally, try to explain what you expected to happen. This helps everyone understand what you were thinking and will often lead to improvements.

You can easily just copy and paste from this template:Version
4.34.0 (x64)

Build
19631

Detailed Description
…

Pictures
…

Example files
…

Crash logs
…

Reproducibility Procedure
1.
2.
3.
4.
5.
6.
7.
8.
9.

Expected Behavior
…

Your effort towards writing a good bug report will not only save the resources of our team, but also create a good relationship between you and the developers.

If you already solved the problem on your own, please report back.

Makes sense?

Thank you all!

Cheers,
Nick

[MaxWaldorf]

Please put your logs posting insde the </> logo you see in the editor…