Bug Submitting Specifications

 Title: make sure as much as descriptive title is written

 Category: ‘Designers’ should be used when submitting a bug which applies to the product providing special
features to designer’s tools, e.g. our components listed in VS Toolbox or Blend Asset Library. ‘Visual Design’
should be used when there are issues with components visual appearance like styling, theming, etc. ‘Samples’
and ‘Documentation’ should be set when submitting a bug in the corresponding PG products (note: the Area
Path should be set to reflect the corresponding component / feature).

 Visibility (for DS only): bugs from Forums should be marked ‘Public’, in all other cases ‘Internal’ should be set
(Georgi, these specifications could be useful to DS too, because we’ve had problems in the past when working
with bugs created by them)
This document was created by Stoimen. I actually kept everything that the document had, added missing things,
and then added some VD requirements. I think most of our requirements will be useful for other teams too, like
having good descriptions and / or better screenshots.

Classification
 Area Path: set the value locating as much as close the affected feature, make sure you do not use any root level
paths like ‘NetAdvantage’
 Iteration Path:
o Set to the oldest supported version where the feature where the bug was found is available and also
where the bug is reproducible
o This will add some extra effort for making additional testing, but this gives us valuable information to
assess bug’s state anyway as well as will give more information to developers
o Also, we will ensure we’ve set the earliest / latest version boundaries for the bug fix verification later –
this will give us extra confidence – e.g. if the developer fixed the issue only in 10.2 and 10.3 codebase
(and set the corresponding ‘Resolved in Versions’ field), but the issue is also existing in 10.1, we will be
able to ensure this is not missed. This actually is one of the risks with a high likelihood which we will be
able to prevent.
o It will also make possible separation between bugs in versions in maintenance (e.g. 12.1, 12.2, 13.1) for
which only fixes are released in Service Release project, and the current Volume Release version.

Planning
 Priority: this field is normally not set by QE, it determines the timeline for when the bug will be addressed,
more information can be read from the Rules for Assigning Severity and Priority document
  Severity: refer to the Rules for Assigning Severity and Priority document for guidelines for how to set this field

General
 Regression: set to ‘Yes – Not Released’ only if the behavior changed after the latest publicly available build for
the corresponding version (bug is being introduced in the current cycle and not in any previous cycle)
Set to “Yes – Released” if the behavior changed between the initial version and the latest publicly available build
(it was working in a released version and it’s broken in the latest publicly available build).

 IDE, Operating System, Browser: fill in the data for the environment where you Found the bug

Versions
 Found in Build: keep it in sync with ‘Iteration Path’ – provide the full build name for the build which you tested
and found the bug. For the cases when the same bug is reproducible in two builds for the two platforms for the
components with cross-platform support, put only one of the builds. The latter should correspond to the
platform which was supported by the former WPF / Silverlight teams.

 Verified in Build(s): fill in all the builds for which the verification has been done, using the original long full
format build number (this will normally be done by copying the value of the ‘Resolved in build’ field and pasting
it in the ‘Verified in Build(s)’ field and then updating the specific build numbers)

Description
 Steps to reproduce: add an easy-to-follow list of the minimal set of steps necessary to trigger the bug.
 Actual Result / Symptom: What the application did after performing the above steps.
 Expected Result: What the application should have done if the bug was not present.
o If an image has the wrong size please provide the right size
o If something looks wrong provide a sample of how it should look

File Attachments
 Attach any resources which might be needed to investigate the issue like images, samples, videos, etc.
 If during the life of the bug item there is a need for another sample, add new attachment without deleting the
old one
 Use Windows ‘Compressed (zipped) folder’ feature to create any archives, this will ensure compatibility on all
environments

IMAGES
 Please when including a picture, make sure the image files are in BMP, PNG format
 Always attach an image of the “Current State” and the “Expected State” (if you know the expected state).
SAMPLES
 Must attach a sample application which can be run to reproduce the issue.
 Sample applications should contain only the code and resources necessary to reproduce the issue. As long as we
have the required assemblies to build the project inside source/build, we should be able to run it by just
pressing F5.

VIDEOS
 Sometimes if the bug is really hard to reproduce or if the steps to reproduce the bug are hard to follow you can
consider attaching a video
o You can use SnagIt to record your videos or Expression Media Encoder
o There’s no requirement about the file format