Defect Report Checklist

Company
Revision Document Id
Date
Page
Schneider Electric Buildings Business

Author
2013 03 06 DefectReportChecklist
1(10)
Mats Johansson
Defect Report Checklist
Company
Date
Page

Author
2(10)
Mats Johansson
Table of contents
1. 2. Introduction ........................................................................................................ 3 1.1 Overview ............................................................................................ 3 Steps to take before writing a defect ...................................................................... 4 2.1.1 Search for duplicate ............................................................................. 4 2.1.2 Narrow down the defect ........................................................................ 4 2.1.3 Identify the impact............................................................................... 4 2.1.4 Tricky Defects ..................................................................................... 4 2.1.5 Very time consuming investigations ....................................................... 4 Creating defect report .......................................................................................... 5 3.1 Writing ............................................................................................... 5 3.2 Attachments........................................................................................ 7 3.2.1 Mandatory attachments for crashes or upgrade issues .............................. 7 3.2.2 Where to find the files .......................................................................... 8 3.3 Complementary Information .................................................................. 9 3.3.1 Modbus related .................................................................................... 9 3.3.2 BACnet related .................................................................................... 9 3.3.3 Work Station ....................................................................................... 9 3.3.4 LonWorks related ................................................................................. 9 3.3.5 I/A Related ......................................................................................... 9 Appendix Checklist............................................................................................... 10
3.
4.
Company
Date
Page

Author
3(10)
Mats Johansson
1. Introduction
1.1 Overview
The purpose of this checklist is to increase/maintain the quality standard of Software Quality Assurance defects. You can use this checklist as a tool to ensure nothing necessary is forgotten (information, spelling attachments, etc.) before submitting the defect. A well written defect containing the right attachments saves time and money. It also shortens the turnaround time of defect fixes and reflects the professional organization that we are. For more thorough information in how to write a defect see SQA Test Handbook chapter 6.2
Company
Date
Page

Author
4(10)
Mats Johansson
2. Steps to take before writing a defect

Below are actions to take before writing a defect
2.1.1 Search for duplicate

Search in the QC database for already filed defects equal to the found one
2.1.2 Narrow down the defect

Simplify defect environments if possible (can we reproduce with one AS vs. Multiserver, for example?) by simplifying the environments, we may double the savings development time saved in the setup and reproduction of the defect and SQA time saved to set up and verify the fix.
2.1.3 Identify the impact

Try to find more symptoms in other parts of the system (impact analysis) e.g. is this the only object making the system crash when save?. Is this fault also on AS or just ES?
2.1.4 Tricky Defects

For tricky defects fetch the Testleader, a developer might be needed to observe the problem, and troubleshoot together.
2.1.5 Very time consuming investigations

Test Lead and Tech Lead should work together to manage troubleshooting costs does it make more sense for SQA or developers to dig deeper into the defect? In some cases, it will be more cost-effective for SQA (large and varied environments. In other cases, it may be simpler just to have a developer reproduce it and debug to step through the code.
Company
Date
Page

Author
5(10)
Mats Johansson
3. Creating defect report

3.1 Writing
The text is essential in the defect. It is the first thing a viewer sees and uses to understand the problem. Put in extra effort to provide well formulated descriptions and scope. It will be read by many people in different positions and varying system knowledge. A well written and thought-out defect shortens its life cycle. We do not: Suggest how to correct Guess what went wrong Write internal SQA messages in Comment field Use any bad words or accusations Dont refer to test cases in the defect description the developer cant see the test case and/or the test case may be too much detail Refer to SI4b environment, Beta wall without closer description
Company
Date
Page

Author
6(10)
Mats Johansson
What? and Where?

(Keep it short and concise)
Detailed description
(Add details and information that dont fit in to the headline)
Step by step how to reproduce

(Do not write large conifuguration setup here)
Expected result of the action made

(Do not write No crash the action must have hade a expected result)
The actuall result

(e.g. If there is a crash write here also if the system recovers afterwards or not)
Workaround
(If there is a workaround it shall be described here)
Describe here the configuration the defect was found in

(Describe here the minimum environment this can be reproduced in)
Comment field
(Provide only information that Would be helpful to developers and descision-makers)
Company
Date
Page

Author
7(10)
Mats Johansson
3.2 Attachments
The attachments are essential for developers to try to sort out what caused the problem. Attachments are mandatory and shall always come with the defect. The below list is a general guide to follow. It does not include all possible types of data that may be necessary to provide developers. There are several more data collection methods for specific problems and providing this data is not yet mandatory because not all Test Engineers may have experience and knowledge for specific problems. These methods will just be mentioned as Complementary information and not described in detail. However, it is of great interest that all Test Engineers develop skills to use them.
3.2.1 Mandatory attachments for crashes or upgrade issues AS Crashes

Trace log from AS System log from AS Dump file from AS Platform variables from AS Trace log from corresponding ES (if multi server) System log from corresponding ES (if multi server)
TIP: Trace log, System log, dump file and platform variables from AS can easily be extracted using the Device Administrator
ES Crashes
Trace log from ES System log from ES Dump file from ES Platform variables from the corresponding AS (if multi server) Trace log from the corresponding AS (if multi server) System log from the corresponding AS (if multi server)
TIP: Trace log, System log, dump file and platform variables from AS can easily be extracted using the Device Administrator
WS Crashes
Error message including (Call Stack) Dump file (Win 7)
Upgrade failure
AS Upgrade log file Configuration DB dump folder Backup file from before the upgrade
Company
Date
Page

Author
8(10)
Mats Johansson
3.2.2 Where to find the files

Dump files (appears at crash in AS, ES and WS-Win7) AS: opt/tac/bin Important: old dump file must be deleted before a new can be created. ES: C:\ProgramData\Schneider Electric\StruxureWare 1.0\Enterprise Server\db\logs WS-Win7: Manually create dumpfile via Task manager Trace logs (AS and ES) AS: opt/tac/db/logs ES: C:\ProgramData\Schneider Electric\StruxureWare 1.0\Enterprise Server\db\logs System logs (AS and ES) if available AS: opt/tac/db/logs ES: C:\ProgramData\Schneider Electric\StruxureWare 1.0\Enterprise Server\db\logs Error messages (WS) Copy paste the Call Stack message Platform variables (AS) Manually create via Device Administrator C:\Program files\Schneider Electric\StruxureWare x.xx\Device Administrator Upgrade files Please note that you need to collect files before attempting to redo the upgrade as some files are overwritten on each upgrade! AS upgrade log file can be collected using Device administrator feature for the Upgrade Log or is found on c:\ProgramData\<SBO version dependent path>\Device Administrator\"log_"+<serial no of concerned AS>.txt Configuration db dump folder (zipped before attaching) is found on AS: c:\ProgramData\<SBO version dependent path>\Device Administrator\Sandboxes\<serial no of concerned AS>\db_backup\dump ES: c:\ProgramData\<SBO version dependent path>\Enterprise Server\db_backup\dump Backup file from before the upgrade is located on AS: c:\ProgramData\<SBO version dependent path>\Device Administrator\Backups\<serial no of concerned AS>\<SBO version dependent backup file name>.xbk ES: c:\ProgramData\<SBO version dependent path>\Enterprise Server\db_backup\LocalBackup\>\<SBO version dependent backup file name>.xbk
Company
Date
Page

Author
9(10)
Mats Johansson
3.3 Complementary Information

Depending on the protocol and/or devices used in testing, there are different data collection methods that provide more data than what is provided by default in logs. Here are some possibilities mentioned, for deeper knowledge talk to people in the different areas.
3.3.1 Modbus related

Increase log intensity via WorkStation UI
3.3.2 BACnet related

IP-level network captures (BCX) E.g. Wire shark logs MSTP-level captures (B3) E.g. Wire shark logs
3.3.3 Work Station

WS-Win7: Manually create dumpfile via Task manager Log level might be increased by editing a program file (by increasing the log level the logfile can get enormously big in very short time)
3.3.4 LonWorks related

LPA (Loytec Protocol Analyzer) Echelon Node Util (can be used for investigation but nothing from this can be attached) Document the type of NIC on ES (PCI, USB, IP or L-IP)
3.3.5 I/A Related

Memory, CPU usage and database size A Trend of CPU and/or memory usage can be attached For LON defects LON protocol analyzer files can be attached if the defect pertains to message handling on the FT-10 bus.
Company
Date
Page

Author
10(10)
Mats Johansson
4. Appendix Checklist
Checklist
Done?
Steps to take before writing a defect Check if this already is reported Narrow down the defect This is a tricky defect Time consuming investigation needed
Refers to 2.1.1 2.1.2 2.1.3 2.1.4 Refers to 3.1
Done?
Creating a defect report Writing is according to standards Spelling check made
Done?
Mandatory Attachments Video was attached (always when possible) Screenshots attached (might complement the video) Crash logs attached (if crash) Upgrade files attached (if upgrade issue)
Refers to
3.2.1 3.2.1 Refers to 3.3.1 3.3.2 3.3.3 3.3.4 3.3.5
Done?
Complementary information Modbus related BACnet related Work Station LonWorks related I/A related

Defect Report Checklist

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Defect Report Checklist

Hochgeladen von

Copyright:

Verfügbare Formate

Company

Schneider Electric Buildings Business