Process Template - Of Mice and Winngarrettwinn.com/portfolio/Resources/NextPage/Process... · Web...

NEXTPAGE ENGINEERING Defect Tr a c k i n g P r o c e s s G u i d e

DEFECT TRACKING PROCESS GUIDE

5/25/2023 NEXTPAGE CONFIDENTIAL PAGE 1


TABLE OF CONTENTSDefect Tracking Process Guide................................................................................................................... 1Table of Contents........................................................................................................................................ 2Table of Figures........................................................................................................................................... 3Defect Tracking Overview............................................................................................................................ 4

Defect Tracking Responsibility Overview.................................................................................................5Responsibility Details............................................................................................................................... 7

Submitter.............................................................................................................................................. 7Component Manager............................................................................................................................ 8Assignee............................................................................................................................................... 8

Defect Etiquette........................................................................................................................................ 9Reporting Defects in Status Reports........................................................................................................9Filing High-Quality Defects.....................................................................................................................10

Defect Checklist.................................................................................................................................. 11Prioritizing Defects................................................................................................................................. 12Managing Critical Defects...................................................................................................................... 13Responsibility Details for Critical Defects...............................................................................................18

Submitter............................................................................................................................................ 18Escalating Defects Using the Defect Review Board...............................................................................19Understanding Unsupported Patches....................................................................................................19What is an Enhancement....................................................................................................................... 20Fields Reference Information.................................................................................................................20Issues..................................................................................................................................................... 22



TABLE OF FIGURESFigure 1. Defect process flow...................................................................................................................... 3Figure 2. Critical defect process workflow.......................12Table 1. Responsibilities during defect tracking.

............................................................................................................................................................. 6Table 2. Status Report fields....................................................................................................................... 8Table 3. Defect Checklist........................................................................................................................... 11Table 4. Defect Priority.............................................................................................................................. 11Table 5. Critical Defect Responsibilities.....................................................................................................17Table 6. Defect tracking fields...................................................................................................................20



DEFECT TRACKING OVERVIEW

Reporting, tracking, measuring, and correcting defects and then determining their root causes are important processes in our quest for zero-defect software. This document details the processes necessary for people to manage and work with the new defect tracking system.

When something does not work as a customer expects it to work, the customer does not know if it is a code defect, documentation problem, enhancement, good idea, bad idea, or customer error. And customers do not really care about the difference.

We see defects as opportunities to learn, respond, and improve quickly. We understand that defects result from incomplete software development practices, and we solve defects at the highest point of leverage. Be relentless about filing defects that you find: no matter how small. Be relentless about resolving defects assigned to you. Be obsessive about creating high-quality defect reports to make the process of reproducing and resolving defects as easy as possible.

Figure 1. Defect process flow.



Figure 1 shows the typical process flow for every defect. This workflow does not attempt to cover every conceivable step or issue in the process, but merely attempts to recreate the typical work pattern that you encounter when using the defect tracking system.

Each person in the workflow has specific responsibilities and functions that help us resolve defects in a timely and orderly fashion. Table 1 details these responsibilities for the submitter of the defect (the one who records it in the tracking system), the component manager (the person responsible for a specific product feature), the project manager (the person responsible for a specific project in which the product feature is needed), the VP Engineering, the team member assigned to fix the defect (also known as the assignee), and the product manager (the person responsible for the overall direction and scope of the product).

Defect Tracking Responsibility Overview

Who Does what DetailSubmitter Adds a defect to the defect

tracking system.Provides a precise, complete, and easy to read description of the problem. Uses their best judgment to assign the problem to a product feature.

Prepares a reproduction area if the defect requires the submitter's specific installation to reproduce the defect, or supplies the necessary configuration information if the defect can be reproduced with a default installation of the product.

See Filing High-Quality Defects for more information.

Confirms the defect priority. See Prioritizing Defects, belowWorks with component manager to resolve “need by” and “release date” conflicts.

Meets with manager and upgrades the defect, if required.

Confirms the change in defect status with a phone call to the component manager.

Requests an unsupported patch or one-off for critical defects.

See Prioritizing Defects, below.Confirms the fix. Installs the new release and verifies that

the recreation steps no longer result in a defect.

Changes the status of the defect to “Done” in the defect tracking system.

Component Manager

Reassigns defects that belong to a different team.

Updates the defect description with the reason for the reassignment.

Confirms the priority and severity of each defect and changes the Status to “Reviewed.”

Accepts the submitter's assigned values or works with the submitter to agree on a different value.



Assigns a component team member and proposes resolution and release dates.

See Prioritizing Defects below for assistance.

Reviews requests for an unsupported patch.

Works with the product manager to determine need and priority for critical defects.

Requests an unsupported patch or one-off from VP Engineering.

Reviews all critical defects in Monday Morning Meeting.

Performs root-cause analysis with team for all critical defects.

See Monday Morning Meeting Agenda template for more information.

Reports status of defects in weekly Status Report.

Queries the defect tracking system for a list of new, open, awaiting release, and released defects, and reports these defects in the Metrics section.

Adds dependencies that prevent engineers from resolving open defects in the Problems section.

See Reporting Defects in Status Reports, below.

Ensures that the defect is resolved in a timely fashion.

Updates the defect record with the release date.

Ensures that the defect is listed in the Release Notes for the component.

See Component Release Notes Template for more information.

Releases a new version of the component.

Releases a new build (runs all regression tests and follows our published release process) or creates an unsupported patch (a one-off to resolve a critical defect).

See Releasing a NextPage Application for more information.

Confirms the release of the fix. Updates all “Ready for release” defects to “Released.”

Publishes application Release Notes.Project Manager

Reviews requests for an unsupported patch.

Works with the component manager to determine need and priority for critical defects.

Requests an unsupported patch or one-off from VP Engineering.

VP Engineering Receives and reviews requests for an unsupported patch.

Approves or rejects all unsupported patch requests to resolve a critical defect.

Reviews all critical defects that require engineering resources in weekly meetings.

Reviews defects at the weekly Engineering Management Meeting and at NextPage Senior Staff Meeting.



See Performing Root-Cause Analysis for more information.

Team Member Reviews the defect. Reads the defect listing and understands what to do to fix the defect.

Commits to the resolution date (or changes the date, with component manager’s approval).

Adds appropriate detail to personal work plan.

Resolves the defect. Documents and builds an automated test that exposes the defect.

Fixes the defect.

Runs the automated test to confirm the fix.

Runs the component test suite to validate that other features continue to work properly.

Checks in validated code and adds the “Ready for release” label to the file.

Updates the Defect Status to “Ready for release” in the defect tracking system.

Product Manager

Releases a new, fixed version of the product.

Notifies component managers of release through an email, and attaches Release Notes.

Table 1. Responsibilities during defect tracking.

Responsibility Details

Submitter

If you are responsible (the submitter) for a defect, you file a high-quality defect with clear reproduction steps as soon as you discover a problem.

After you file a defect, you should do the following: Call defect assignee or manager when filing a critical-priority defect. See Managing Critical

Defects, below. If you cannot contact assignee or manager, you escalate the defect by calling the manager’s manager. You do not stop escalating the problem until you talk to someone who accepts responsibility to fix the defect.

Communicate clearly and in a timely manner with the assignee whenever you file or modify a defect. You might need to discuss your defect verbally and demonstrate reproduction sequences. (See Defect Etiquette below.). If your discussion with the assignee identifies important information missing from the reproduction steps, you add the missing information into the defect description.

Follow up with the assignee if they do not change the state in a reasonable amount of time. Confirm the defect priority with the component manager (see Prioritizing Defects, below).



Approve the defect solution when the assignee changes its state to released, and change the defect state to “Done.” If you do not approve of the solution, change the defect state back to “Open,” and explain why the solution does not meet your needs.

Provide additional information to the assignee or component manager when he or she requests it. Call the assignee or component manager, or, at a minimum, update the Description field with requested information.

If the defect is an enhancement request (see What is an Enhancement below), keep track of the progress, but expect the product team or organization to prioritize its resolution at their discretion.

Component Manager

Each product feature has a component manager assigned to it. If you are a component manager, you are responsible for all the features that belong to that component.

As the component manager, you are responsible for the following: Understand what product features belong to your component so that you can appropriately

reassign defects to another team if the defect does not affect a feature in your component. Learn the differences between a functional defect and an enhancement request (see What is

an Enhancement below) so that you can prioritize them accordingly. Assign a team member to the defect. This includes confirming the severity and priority of the

defect, proposing a resolution date and a release date, and changing the Status to “Reviewed.”

Assignee

If you are responsible (the assignee or Team Member) for a defect, you review it as soon as you receive it, and again whenever appropriate. If you need more information before you can fix the defect, call the submitter and change the defect state to “Information requested.”

If you are responsible for a defect, you should do the following: Communicate clearly and in a timely manner with the submitter whenever you modify a

defect. This might require verbal communication (see Defect Etiquette below.) Review the defect as soon as you receive it. Discuss it with the submitter to ensure that you

clearly understand the problem and that you agree with its priority. Commit to the resolution date or work with the component manager and submitter to change

the date to a date that you can commit to. If a defect does not contain enough information to clearly describe and reproduce the

problem, call, email, or visit the submitter and ask them for more information. Make direct contact with submitters so that you obtain all the information you require as early as possible. As a last resort, specify the additional information that you need in the defect tracking system (see Defect Etiquette below).

Change the defect state from “Open” to “Ready for release” after you resolve it, test it, and (if a product defect) check any changed files into source control. Our defect tracking system automatically sends an email note to the submitter.

Change the defect state from “Ready for release” to “Released” when you release the fix and it is available for the submitter to verify. Our defect tracking system automatically sends an email note to the submitter.

If the defect is an enhancement request (see What is an Enhancement below), resolve it according to the prioritization that your product team or organization determines.



Defect EtiquetteWe use our defect tracking system as a business tool to track and resolve defects and enhancements. Our customers sometimes review defects. Be professional when using our defect tracking system. Keep the following guidelines in mind:

Do not record conversations or disputes in the system. If you cannot get your point across clearly with one attempt, contact the person directly. Do not carry on an email conversation by changing a defect back and forth between two states.

Resolve defects, do not shuttle them. We strive to have zero defects in our application. To do this, we demand high-quality defects, and resolve those defects quickly.

Do not show frustration in your defect. We know that defects often show up at inopportune times. Showing your frustration in the defect description only serves to create an emotional reaction, and does not resolve the problem any faster.

Follow NextPage precision writing standards. Be concise, be thorough, and use active voice. Following the NextPage writing standards helps you communicate more clearly, which helps developers solve the problem faster. It is also important to use good grammar and spelling, complete sentences, appropriate punctuation, normal capitalization, and editorial indicators. Avoid using abbreviations and short hand since those who read the defect may not understand these.

Expect enhancements to take longer. Be aware that enhancement requests proceed at the rate that the product team or organization determines best matches their priorities. If you require a commitment on an enhancement, talk to the project manager and obtain approval for a Change Order with a committed delivery date.

Reporting Defects in Status ReportsWe consider the arrival rate and number of unresolved defects when we assess team performance. Setting better expectations, better regression testing, and prompt defect correction are behaviors that we encourage.

Engineering teams use the following definitions when reporting defects in their Status Report:

Title MeaningNew (C/H/M/L) Defects only. Logged this week. C = Critical; H =

high; M = medium; L = low.Open (C/H/M/L) Defects only. State: “Open,” or “Information

requested.” Separate count by priority level. Ready for release (C/H/M/L) Defects that are currently ready to be released.Released (C/H/M/L) Defects you released this week.Open enhancements Enhancements only. State: “Open,” “Information

requested,” “Ready for release.”

Table 2. Status Report fields

One way to decrease your defect count is to prematurely change Status to “Done.” We do not let you do this. A defect is done only when you correct it, release your correction, the customer installs your correction, and the customer confirms that you solved their problem. Only the person reporting a defect (the submitter) can close it by changing its Status to “Done.”

Another way to decrease your defect count is to reclassify a defect as an enhancement. We do not let you do this. You can reclassify the incident as an enhancement only if you provide your customer with a way



to solve their problem and the customer agrees that the defect is really an enhancement. Only the person reporting a defect (the submitter) can classify or reclassify it as an enhancement.

Occasionally someone erroneously reports a defect (people can make errors, misunderstand, suggest a bad idea, and so forth). If the person reporting a defect agrees to close it without further action, it is okay. Only the person reporting a defect (the submitter) can change its Status to “Cancelled.”

We rely on the person reporting the defect to maintain the proper priority. If those responsible for fixing a defect disagree with the priority, they must work with the submitter to evaluate the need. If the submitter and assignee disagree on the priority, they escalate their disagreement to the Defect Review Board, who can then set a new priority. Only the person reporting a defect (the submitter) can change its priority level.

Filing High-Quality Defects

NextPage teams continually strive to eliminate all open defects in NextPage applications. Filing high-quality defects helps NextPage accomplish this task. Reporting, tracking, measuring, and correcting defects (and then determining their root causes) are important processes in our quest for zero-defect software.

A defect exists anytime that a NextPage application does not match its corresponding documentation or does not pass existing application regression tests. When you discover that a NextPage application does not work as documented, you should log a high-quality defect immediately. This is important even when a workaround for the problem exists. Any workaround means that the original functionality is insufficient and requires improvement.

NextPage relies on you to communicate defects immediately.

Specifically, when you are working on a project, there should be one, and only one, person through whom everyone else on the team reports their defects and workarounds. This person can verify the defect for completeness and accuracy and then report the defects to NextPage; this avoids duplicate defect reporting and ensures your team maintains one person responsible for filing high-quality defects.

For features that do not have acceptance test documentation or adequate requirements, we expect the client to file a report based on how the system should work and to provide additional detail indicating why they think it should work differently. Until proper documentation can be developed for all system features, there is an acknowledged need to communicate about the differences between an enhancement and a defect (see What is an Enhancement).

When you report a defect to NextPage, you need to provide the following:

Enough information for others to thoroughly understand the problem. Do not assume that others have customer or applications knowledge. Use plenty of detail. Elaborate (to the extent of redundancy, if needed) to help your target audience understand exactly what you are seeing and experiencing. In fact, assume that those who read the defect do not know what you are talking about.

Environmental detail to ensure we solve the problem in a similar environment. In order to increase productivity and begin immediately resolving the defect we require system configuration information such as your Operating System version (Windows NT 4.0), application version, browser version, service pack information, and any non-standard installed Microsoft application suite information.

Explicit test cases and instructions for how to access those test cases. The assignee needs to recreate the problem to ensure they are solving the correct problem. They require exact, reproducible steps to recreate and observe the unexpected application behavior you report.



When the problem started and if the feature ever worked properly. This is important information; it lets others review the history of the problem and identify possible reasons why a feature stopped working.

Detailed descriptions of any error messages that you see. The engineers build error messages into NXT 3 applications to help identify problems. Please record this information carefully and completely. It saves others time in solving defects.

Priority. Because many different groups report defects to NextPage, we need a way to set priorities. Please give careful consideration to your actual needs when reporting defects, so that we are best able to put our efforts where we most need them (see Prioritizing Defects).

No solutions. You do not need to provide possible solutions to the defect, although you may provide details for any workaround you are aware of.

Expected results. Explain what is it that you expected to happen that did not occur, which then caused you to report the defect.

Information for Defect Descriptions

When filing new defects, review this checklist (Table 3) for information you can add to ensure engineering has the information required to solve the problem. When in doubt, it is better to include more information and have it be extra than to have others wonder what you mean.

Item DescriptionTitle A short summary of the defect.Problem Description A detailed description of the defect.Expected Behavior The expected or desired behavior.When did this problem begin

Date or event that initiated the defect.

Server The server being accessed.Browser Info Information about the browser, browser version, build number, cipher

strength, and service patch used to display the defectJVM Java Virtual Machine version (server or client, or both). OS The operating system version, build number, and service patch for server

machine, client machines, or both.Machine Specs Include the number of CPUs and speed, amount of RAM, amount of L2

cache, total disk space, free disk space on the server, client, or both depending on where the problem may exist.

Space/File If the problem exists in particular Matrix spaces or particular files, export those spaces or files and attach them to the defect report.

Log Files Attach application, security, system, JVM, BakerMAKS, Matrix, or NXT 3 log files.

Concurrent Users Estimate of the number of concurrent users at the time of the problem.Additional Software Note additional software installed on the server and client machines (virus

scanners, AppShield, SQL Server, Tivoli, SMS, and so forth).Memory/Processor Report any unusual activity in your server's memory or processor usage.Additional Info Provide any additional information needed to reproduce the defect.Duplication Steps Duplication steps includes the BakerMAKS server being accessed, location

within the product, such as the space the defect is in, the object being used, user name, password, the tab being used, the filters that are active, context path, number of tasks, files, file sizes, events, et cetera.

Table 3. Defect Checklist



Prioritizing DefectsThe submitter assigns a priority to each defect according to when resolution is needed, and whether or not a workaround exists. When reporting a defect, specify the priority of the defect to help the defect owner determine how and when to resolve the defect. Also, be prepared to justify a defect’s assigned priority. If a component manager does not agree with the priority, they must work with the submitter to come to a solution where the submitter changes the priority or the component manager accepts the current priority. If a component manager and the submitter cannot agree on a priority, the component manager may escalate the disagreement to the Defect Review Board.

Table 4 shows the priorities for defects and how to determine which priority to assign. Critical defects must be worked on continuously (around the clock if needed) and a fix make as soon as possible. The submitter can request an unsupported patch or one-off for critical defects if the defect cannot be incorporated into the product by the proposed deadline (see Managing Critical Defects, below).

The other defects should all be resolved in a timely manner, according to the priority and the advice of the submitter, component manager, and assignee.

Priority Previously Known

When To UseTime CommitmentWorkaround

Available? Severity

Critical Priority 1 No Severe usability problems, Data loss, Physical harm to user,Legal implications

The submitter and assignee work together (around the clock if necessary) until the defect is resolved.

High Priority 2 No Usability issues for some users,No legal implications

Address defect within a short amount of time, but only after critical defects are resolved.

Medium Priority 3 Yes May aid usability,Time-consuming workaround,Not deployable

Negotiable, but not too long a time. Should be resolved in the next minor release.

Low Priority 4 Yes Not severe Should be fixed in the next major release of the product.

Table 4. Defect Priority

Managing Critical DefectsFiling a critical defect means work stoppage, and implies a catastrophic failure in our development process (we released something important that does not work, and the fact that it does not work stops our customer from doing anything). Customers file a critical defect if they do not have a workaround, and cannot work on anything else (see the Prioritizing Defects for more information).

When a defect prevents you from making further progress on any task, or forces development to stop, you file a critical-priority defect. Assignees react quickly and aggressively to resolve critical-priority defects. Assignees and their team drop whatever they are doing, assign someone to work with the submitter to resolve the problem, and work around the clock, if necessary, to resolve it until you all agree that you have resolved the defect.



Figure 2 shows the basic process flow for critical defects.

Figure 2. Critical defect process workflow

The following table shows the responsibilities for each person involved with a critical defect.

Who Does what DetailSubmitter Identifies a critical defect. Details the reproduction steps.

Reserves a test area for Engineering to work on the defect, or supplies configuration information if defect can be reproduced in a default product environment.

Works with their manager to file the critical defect.

See Filing High-Quality Defects for more information.

Component Manager

Confirms that the defect is critical (this may be done by a Project Manager or Guru instead).

Reviews and completes reproduction steps.

Confirms the test area location (if one is reserved).



Who Does what DetailFiles the critical defect. Only managers or Gurus can file critical

defects.

Files a high-quality defect in the NextPage defect tracking system.

Makes personal contact with the defect owner, using chain of command, to escalate the critical defect during normal work hours, or calls the Support Pager Assignee after hours.

See Obtaining Emergency Engineering Support for more information.

Remaining available, on task, and at desk until the defect is resolved.

Leads the resolution of a critical defect during normal business hours.

Stops everything and focuses on the critical defect.

Contacts the Submitter immediately after receiving the defect.

Resolves the defect by suggesting a workaround, a new release, or an unsupported patch.

Confirms the solution for the defect (this may be done by a Project Manager or Guru instead).

Accepts workaround and changes defect priority to High.

Accepts release date for fix and changes defect priority to High.

Requests an unsupported patch from VP Engineering.

Confirms the resolution of critical defect (this may be done by a Project Manager or Guru instead).

Reviews and confirms the fix or workaround.

Changes the defect priority to High.

Contacts the Component Manager or Support Pager Assignee and confirms that Engineering can stand down.

Reproduces the defect. Reproduces the defect in the default development environment, running the latest build if possible; or reproduces the defect in the default development environment running the same code as the customer if unable to reproduce the defect using the latest code.

Reproduces the defect in the component test area running the same code the customer is running if unable to reproduce the defect using the default development environment; or reproduces the defect in



Who Does what Detailcustomer test area if unable to reproduce in the component test area.

Reproduces the defect in the customer test area if this is a localized problem.

Reviews all critical defects in Monday Morning Meeting.

Performs root-cause analysis with team for all critical defects.

See Monday Morning Meeting Agenda template for more information.

Project Manager

Confirms that the defect is critical (this may be done by a Component Manager or Guru instead).



Files the critical defect. Only managers or Gurus can file critical defects.





Confirms the solution for the defect (this may be done by a Component Manager or Guru instead).



Requests an unsupported patch from VP Engineering.

Confirms the resolution of critical defect (this may be done by a Component Manager or Guru instead).




Support Pager Assignee

Leads the resolution of a critical defect after normal business hours.

Stops everything and focuses on the critical defect.

Contacts the Team Manager, Project Manager, or Guru immediately after receiving the support page. Reviews the defect with them and has them file the



Who Does what Detaildefect (or, if they cannot access the system, files the defect for them).

Reproduces the critical defect (if possible).

Determines which component team owns the problem.

Confirms with the Team Manager that Engineering now owns solving the problem, and that the Support Pager Assignee owns resolving the problem.

Contacts the Component Team Lead or assigned component support staff to resolve the defect.

Ensures that the component team resolves the defect.

Stays on call, on task, and at desk until the defect is resolved.

See Providing Engineering Pager Support for more information.

Guru Confirms that the defect is critical (this may be done by a Project Manager or Component Manager instead).



Files the critical defect. Only managers or Gurus can file critical defects.





Confirms the solution for the defect (this may be done by a Project Manager or Component Manager instead).



Requests an unsupported patch from VP



Who Does what DetailEngineering.

Confirms the resolution of critical defect (this may be done by a Project Manager or Component Manager instead).




VP Engineering

Receives and reviews requests for an unsupported patch.

Approves or rejects all unsupported patch requests to resolve a critical defect.

Reviews all critical defects that require engineering resources in weekly meetings.

Reviews defects at the weekly Engineering Management Meeting and at NextPage Senior Staff Meeting.

Conducts root-cause and tip-of the iceberg analysis.

See Performing Root-Cause Analysis for More Information.

Release Manager

Releases the fix to the Submitter (this may be done by the Component Team Lead instead).

Releases a new build (following our release process).

Creates an unsupported patch (after approval from VP).


Component Team Lead

Releases the fix to the Submitter (this may be done by the Release Manager instead).

Releases a new build (following our release process).

Creates an unsupported patch (after approval from VP).


Assignee Confirms permanent resolution of the critical defect.

Documents and builds an automated test that exposes the defect.

Fixes the defect.

Runs the automated test to confirm the fix.

Runs the component test suite to validate that other features continue to work properly.

Updates the Defect Status to “Checked-in” in the defect tracking system.

Table 5. Critical Defect Responsibilities



Responsibility Details for Critical DefectsSince critical defects are so costly (in terms of time, development energy, and coordination) Engineering reviews each critical defect, performs root-cause analysis on each one, and reviews them with NextPage management and senior staff.

Submitter

We clearly detail submitter responsibilities for critical defects. If the submitter does not meet their responsibilities for critical-priority defects, assigned teams escalate the defect and non-compliance to the manager and lower the defect priority.

The submitter assumes the following responsibilities when filing a critical defect: Make personal contact. Discuss the problem with the recipient of the defect by telephone or in

person within five minutes of filing it. Use team support pagers if necessary (see Obtaining Emergency Application Support for more information).

Be available. You must be available to the team working on the problem until they resolve it. You must be willing to commit to making your entire time available for resolving the problem, attempting solutions and alternatives, and so forth. Engineering commits their time and resources for emergencies, and you should behave similarly. If you cannot be reached, Engineering assumes that you are not treating it as an emergency and stops their work. You must be available to the team working on the problem until they resolve it. Do not file a critical defect unless you can maintain continual communication until the problem is resolved.

Understand the defect and how to reproduce it. Carefully research the problem before filing your critical defect (you should be doing this careful research before filing any defect, but be especially diligent before you file a critical defect). Good research and a clear characterization of the problem often lead to the solution, thus avoiding the need to file the critical defect in the first place.

Accept a workaround. A critical-priority defect prevents assigned teams from working on scheduled deliverables and other defects. Be receptive to discussions about workarounds or other tasks that you might work on as alternatives to prioritizing your defect as critical. If assigned teams provide a workaround, reduce the defect priority to high and supply a defect resolution “Need By” date.

Be willing to discuss your prioritization. A critical-priority defect prevents assigned teams from working on scheduled deliverables and other defects. Be receptive to discussions about workarounds or other tasks to work on as alternatives to prioritizing the defect as critical.

Do not wait until a defect becomes critical to file it. If someone discovers a non-critical defect, they should file it immediately. It is an abuse of the system in cases where a critical defect is filed that could have been filed earlier at a lower priority.

Do not abuse the system. Assigned teams are responsive to help the submitter. If their responsiveness is abused, the submitter can jeopardize the assigned team’s deliverables schedule, which in turn can jeopardize other teams’ schedules, and ultimately the project’s schedule as a whole.

Be available for root-cause analysis. When you file a critical defect, you commit to following through on root-cause analysis. Engineering does root-cause analysis on every incident, and may need your help as they backtrack through the problem (see Performing Root-Cause Analysis for more information). The results of these analyses may require action from you to file a defect or to communicate information among your team. You should be committed to this process if you file a critical defect.



Escalating Defects Using the Defect Review BoardOur VP Engineering, VP Marketing, and VP Professional Services are the defect review board (OR IS IT “NextPage Project Manager, the Client Project Manager, and the Change Order Review Board”). They meet as necessary to settle disputes. Examples of disputes are:

An submitter is unwilling to close a defect. An submitter is unwilling to reclassify a defect as an enhancement. An submitter is unwilling to change priority for a defect.

Our CTO (OR IS IT “VP of Support”) arbitrates any non-unanimous decision of the defect review board.

When the review board has settled a dispute, our VP Engineering (OR IS IT “NextPage Project Manager”) notifies all appropriate parties.

Understanding Unsupported PatchesCustomers get fixes in two ways: either when we release the component (on schedule) or through an unsupported patch (unsupported code that we hope actually installs) or some other one-off (these are unscheduled events). The VP of Engineering determines whether we provide any unsupported patch.

We plan to release components and we publish what defects we complete in release notes (published ahead of schedule). Since we have already provided a commitment date when we accepted the defect, the date that we provide the fix should come as no surprise (in fact we think that as long as we consistently deliver, customers prefer knowing when we plan to fix something and waiting than screaming for a unsupported patch).

When someone wants a defect resolved and cannot wait for the defect to be resolved, they talk to their manager and upgrade the priority of the defect. Since our attention to the defect depends on the priority, we respond accordingly (we also track, escalate, and perform root-cause analysis if an submitter decides a defect is now critical).

What is an EnhancementAn enhancement is a suggestion for new functionality or improvements to existing functionality that you do not need by a particular date (enhancements do not follow our defect process). Enhancements are explicitly not defects. If you require an enhancement by a particular date, request a development commitment through the Project Manager or Product Manager (or, if the project is in its build phase, direct the request to the project’s Guru). See Obtaining Development Commitments for more information.

Fields Reference Information

The following fields in Table 6 are part of the new defect tracking system:

Field Name Field Type Description How Used

Abstract Text: Fixed Length, 255 characters max

A short general description of the defect. A quick reference to identify the defect.

Assigned To User The name of the person responsible for fixing the User who owns defect in



defect. “Assigned” state.

Customer Multi-Relational Support field. Shows name of customer who called in the defect.

Description Text: Memo A description of the defect, the expected result, or any other detail not covered in other fields.

Provide as much detail about the defect that is useful.

Description of Fix Text: Journal Information about what files were changed in the fix.

What source code changed, what the changes were, what DLL or class file the fix is in.

Description of Release

Text: Journal What version or build this defect is fixed in. Type of release, product, and date.

Feature Single Select What general product feature this defect falls under.

Drop-down list based on product.

Support Tracking Number

Text: Fixed Length of 20

Support field. Internal tracking number for support.

Issue ID Number The defect number. Unique ID of defect.

Issue Type Single Select Used to indicate if this is a defect or an enhancement request.

Options are Bug report or Enhancement Request

Priority Single Select How urgent the fix is needed. The submitter sets this for all defects except critical ones. A manager or a Guru must file critical defects.

Product Single Select What product this occurs in. NXT, Matrix, and so forth.

Submitter User Person who verifies the fix. In most cases, this is the submitter.

Recreation Sequence

Text: Memo The recreation sequence; how to get the defect to happen.

The exact sequence needed to reproduce the defect.

Root Cause Text: Memo The root cause that allowed this defect in. Track trends that are causing defects to appear.

State Single Select Options of “New,” “Assigned,” “Ready for release,” “Released,” and “Done.”

Team Single Select Which component or group has responsibility over this defect.

Version Single Select In some cases we want version numbers, but in pre-release we want build versions that will be new every day.

Work Around Text: Memo Support field. Details of any workaround for this defect.

Need by Date Date (MM/DD/YYYY) In addition to the priority requested, the submitter my type a “Need by Date” to indicate a more precise date a fix is needed by.

Manager User Person who is the manager of the team that owns the component.

User who owns the defect when the state is new and ready for release.

Commitment Date

Date (MM/DD/YYYY) Date that manager commits to have the defect fixed and released by.

Release Date Date (MM/DD/YYYY) Actual date that the defect fix is released.

Active/Inactive Single Select Replaces former responsibility of State. If item is “Inactive,” the defect requires no further action by any party.



Owner User Person who needs to take action on the defect in its current state.

Other Products Multi-Select Used to indicate other products or versions where the defect occurs, the earliest product or version being the instance where the defect was first introduced or discovered.

So we know all versions where the defect exists.

Table 6. Defect tracking fields.

Examples

The first example of a defect submittal leaves everyone but the submitter wondering what they are talking about. The submitter may think it is adequate because they already know all of the details of the environment, their actions, and their expected result.

The second example follows the “Defect Checklist” by giving details on as many items from the checklist as apply to the defect. The second example also uses good defect etiquette. This example has a concise abstract of the defect and detailed duplications steps.

Writing a defect should be like writing an article for a newspaper: a defect should answer who, what, when, where, why and how. When you write a defect, assume that those who read it have no idea what you are talking about.

Example 1 (Bad example) Title: Folder Description: The add folder function doesn't work. Duplication Steps:

Example 2 (Good example)Title: The New Folder action in the Tasks quick view does not work as designed.Description:

-Problem Description: The "New Folder" option in the "Actions" drop-down list in the "Tasks" quick view section of the "Project" context does not work properly. When I click on "New Folder" the result is that the drop-down menu disappears. The pop-up window does not appear. I have tried this on several different machines running Windows 2000 Professional with several different builds of Internet Explorer version 5.5. -Expected Behavior: When I click on "New Folder" I expect it to open a pop-up window and allow me to fill in information for the creation of a new folder.-When did this problem begin: I have never seen this function work in this build. This function did work in the previous build (BakerMAKS Build 145).-Server being accessed: bakermaks.nextpage.com-Build Number: BakerMAKS Build 146, Baker UAT2 Version-OS: Windows 2000 Server and Workstation-Browser(s): 5.50.4807.2300 using 128 bit encryption, SP2-JVM: Java Plug-in 1.3.1.02-Machine(s): Single 700MHZ Intel III CPU, 512mb RAM, 40GB drive, 30GB free space



-Space/File: Happens in every Space we have tried it in-EventLog: Application log gives the following information whenever this happens:Computer: JSMITH, Source: Microsoft Internet“The description for Event ID ( 1001 ) in Source ( Microsoft Internet Explorer ) cannot be found. The local computer may not have the necessary registry information or message DLL files to display messages from a remote computer. The following information is part of the event: 01888691.”-Concurrent Users: There are usually 2 concurrent users at any given time-Additional software: We have Doom 2000 Server and McAfee Virus Scan both running-Memory/Processor: Whenever this problem occurs the CPU spikes for about 3 seconds and the memory used during those 3 seconds is not released.-Additional Info: This is similar to an issue previously submitted, issue 6142.

Duplication Steps:-I logged into the BakerMAKS server on bakermaks.nextpage.com using my own username and password (jsmith/jrules).-I selected the "Worldwide Team Test" space from the "My Spaces" drop-down menu.-I selected the "Context" view from the left-hand navigation bar.-I changed the "Context Path" from Collaboration to Project.-I selected "Tasks" from the left-hand navigation bar.-In the Tasks quick view I clicked on the "Actions" menu.-From the "Actions" menu I highlighted "New" and then clicked on "New Folder".

Issues1. We use the word “Unsupported Patch” until we find a better name (we’ll find and replace with a

term that creates trepidation in the recipient). We don’t want to use the word “patch” because it’s an innocuous-sounding word. [Rob]

2. We do not define our enhancement process. The process would mirror the bug process in how enhancements are dealt with. As of this moment, there is no feedback mechanism for the customer that “truly” gets enhancements added into a later release. And, I would make sure that Product Management and Engineering are involved with this process. Just as we have a review process for the bugs that get assigned to a particular release, so we should have a review process for the enhancements. How enhancements are handled, will be, in my opinion, just as important as how we handle the bug process (in the customer’s eyes). [Kurt]


Process Template - Of Mice and Winngarrettwinn.com/portfolio/Resources/NextPage/Process... · Web...

Documents

Transcript of Process Template - Of Mice and Winngarrettwinn.com/portfolio/Resources/NextPage/Process... · Web...