Вложения в баг репорте

Each bug must be documented with at least one attachment. With your attachment(s), you provide evidence that the bug occurs on your device, operating system, and/or browser. Note: Attachments do NOT replace written information in your report.Attachments are a visualization of the problem and serve as proof.

Screenshot or screencast?

In general, most functional bugs require a screencast to be illustrated properly and effectively. Unless the instructions or the team leader asks for specific attachments, use the following rule of thumb to determine whether a screenshot or a screencast is required for your bug:

• Whenever an action is required to trigger a bug or when a process needs to be illustrated, upload a screencast. Screenshots as static images are snapshots and cannot illustrate the root cause.
• When the nature of a bug is static, e.g. for static GUI problems, a screenshot is enough and a better visualization than a video.

General attachment requirements

• New attachments have to be created for every bug report or reproduction.
• It is prohibited to copy attachments from other bug reports or reproductions.
• Attachments must show all relevant bug information to serve as proof.
• All relevant information must be displayed in English (or optional German if the bug report language is German), e.g. the date, system information, and error messages.
• Website contents may not be changed, e.g. by using the Google Translator service to translate the website into a different language, as it may lead to unexpected behavior.
• Don’t show any information about other customers (e.g. invitation emails or browser tab names revealing the company name).
• If you refer to multiple browsers or devices, upload an attachment for each of them.
• For website tests, the URL field must be visible on attachments.
• The current date must be visible on attachments.
• The date can be in any common date format, e.g. DD/MM or MM/DD.
• The resolution must be high enough, so that the text and elements can be easily identified.
• The recorded section of the screen has to be large enough for orientation purposes.
• The maximum file size for attachments is 25 MB.
• A crash log is mandatory for bug reports about app crashes. The video that documents the crash has to correspond to the attached crash log, i.e. timings must be coherent.

Showing the current date

By displaying the current date on your attachment, you prove that you recorded it on that date. The following list suggests where to find the date:

• Windows: Displaying the taskbar or blending in the calendar
• Mac: Displaying the calendar icon in the Dock or the menu bar
• iOS & Android: Swipe down the notification center at the beginning of your recording.

Further information: TecRevue

What needs to be included in a screenshot?

Screenshot-specific rules:

• The screenshot has to be in the JPG or PNG file format.
• Highlight the bug on your screenshot.
• When proving a bug via a screenshot on a mobile device, a second screenshot showing the date must be uploaded (battery charge and time must match with the first screenshot).

We recommend recording tools in the following article: Screenshot tools

What needs to be included in a screencast?

Screencasts should be as short as possible but as long as necessary. This means that you should leave out steps that do not cause the bug. For example, when the “Add to cart” button on a product detail page of a webshop is defective, it is generally irrelevant how you navigated through the webshop to reach the product detail page.

Relevant is usually the last navigational step, the step that triggers the bug, and the bug itself.

Example 1: Bug on website, tested on Desktop device

Steps to produce a screencast:

1. Go to the page where the bug occurs.
2. Start your recording.
3. Refresh the page.
4. Perform the action that triggers the bug.
5. Wait until the bug occurs.
6. Stop the recording.

Example 2: Bug in app, tested on mobile device

Steps to produce the screencast:

1. Run the app and go to the page where only one more navigational step is needed to reach the page where the bug occurs.
2. Start your recording.
3. Swipe down the notification center to show the current date for a couple of seconds.
4. Perform the last navigational step to reach the right page.
5. Perform the action that triggers the bug.
6. Wait until the bug occurs.
7. Stop the recording.

Team leaders might send you an information request asking for an external or additional recording. This is done to gain a better understanding of the bug or when in doubt due to the bug being non-reproducible.

Screencast-specific rules:

• Screencasts must have the MP4 file format.
• The maximum time for a screencast is 60 seconds unless your bug requires to show a loading process or long necessary manual inputs.
• Your clicks/taps/touches must be visible (only required for Android and desktop recordings).
• Make your recording in one go. Don't pause your recording in the middle.
• Don't cut parts of the resulting screencast in the middle. If necessary, only cut the beginning or the end of the file.
• The frame rate must be high enough to identify your actions and to analyze the course of events.
• Sound is not to be recorded if not instructed otherwise.

We recommend recording tools in the following article: Screencast tools