Which information is necessary to report a defect to the WinCC OA support?

Defects have to be reported and delivered to ETM in a reproducible status. Defect reports have to contain a short summary, a detailed description of the erroneous situation, the expected behavior and the actual behavior, the environmental conditions under which the error can be reproduced and an isolated project example, where the error can be reproduced with standard WinCC OA installations. A customer specific test environment is not available at ETM.

The quality of a defect report can dramatically impact how likely it is that the defect will be solved. A prerequisite for this is that a number of ETM specialists (for example developers, code reviewers, QA and release managers) are able to quickly understand and verify the issue by reading the report and potentially running a code example.

The text below describes how to report defects, and gives tips to make high quality reports. (Source: http://wiki.qt.io/ReportingBugsInQt )

Defect Report Content:

Summary

• Enter a short but descriptive text explaining the defect in a sentence.
• This should include an overall overview over how the defect happens without going into too much detail. They key is to think about what other people might search for.
  • Bad example: "Text field always goes wrong"
  • Too long: "My UI crashes in when I use a Text field and fill it with a CTRL script in a for loop with the description text of my DPEs. This happens if I save the panel in XML format and set my operating system language to Arabic, which also switches to right-to-left mode. Then I try to type something, and it crashes." A long text like this one should be put in the description instead; the summary should be kept short.
  • Good example: "UI crashes with text fields when using an input method in right-to-left mode."
  • If you are sure the defect affects only one platform, prefix it by the platform and a colon: "WIN7: UI crashes with text fields when using an input method in right-to-left mode."
  • If the defect is a regression, that is, it worked in a previous version of WinCC OA, indicate this as follows: "[REG 3.12->3.14] WIN7: UI crashes with text fields when using an input method in right-to-left mode."

Affected Version

• Define the WinCC OA version and patch level where you are able to reproduce the defect. If this is not the current patch level of your installation, please also verify against the current patch level to check whether the defect has been fixed in the meantime.

Components

• Define the component which best fits the location of the defect.

Description

• A longer text describing, step by step, the minimum amount of actions required to reproduce the defect.
• A good form to follow is this:
  • What did you do step by step? This ideally takes the form of short bullet points. However, try to be as precise as possible when describing something like a touch gesture.
  • What did you expect to happen?
  • What happened instead?
• If the defect leads to a crash, a vital piece of information in crash reports is a core dump. Retrieving a core dump is platform specific. If successfully created a core dump, submit it together with the crash report.
• Finally, please supply any more details that you may have. For instance "This defect only occurs if I use Aero in Windows 7, it does not happen when I have opened the UI with Windows classic theme", or "This is a regression from WinCC OA 3.11.1".
• Example:
  • Open attached example myPanel.xml
  • Click on the button „First“
  • In the shown menu choose item "Red"
  • Note: Wait a few seconds
  • EXPECTED: the panel background will now be red
  • ACTUAL: the panel background stays gray

Environment

• A detailed description of your operating system, network, settings, and any other pertinent information is requested to help reproduce the defect.

Attachments

• A simple example that reproduces the defect is always welcome.
• If log files are attached, please describe them. Important information is for example: when did something happen, how is the topology of devices/machines/components and what are their names

In short

Always provide as much information as possible together with your defect report. The more the better. Also, please specify if a defect is a regression or not. If it is, then specify what version it worked in last to your knowledge. Finally, supplying a small test panel is a sure-fire way to solve a defect faster.

By creating a high quality defect report, you will gain priority over those less descriptive, and your chances of a speedy resolution increased.

Some defects may be hard to reproduce, for example, it may happen only occasionally, it cannot be reproduced in a small example, or it only happens in a specific environment. However, for the support to be able to help you, it is still important that the defects are analyzed in enough detail so that a developer is able to see the problem for himself. At this point, it is important not to lose hope. These defects are tricky, and solving them typically requires a lot of back and forth communication, since the defects can only be reproduced on the reporter's system.