Quality Controle
Quality Control
/ 0
- Gegevens
- Gepubliceerd op zondag 11 april 2010 18:01
- Hits: 7366
Quality Control
Quality Control Procedures
Why Quality Control for osFinancials
As growing of the installed base of osFinancials is a main goal, to be the only open source accounting package relevant for users worldwide and relevant for other software packages to connect to (like e.g. OSCommerce), Quality Control is key to secure the quality of the delivered osFinancials software.
Quality Control describes the procedures where Software Maintenance and Software Development are in place. osFinancials will deliver a central place where users can register there found bugs, feature requests and post their self made contributions (patches) as a request to adopt them into the standard software.
Stick to the procedures..........procedures are there to follow!! If a procedure is not working, the procedure needs to be changed. This procedure is not editable by the community. If you have comments to this procedure please send a message to Jan Verlaan
Which tool do we use
We will be using the tracker systemon the SourceForce project page.
Maintenance Processes
Purpose: We have written this process to efficiently assess incoming user issues within osFinancials Maintenance and to deliver a timely, quality solution in a manner that maximizes user satisfaction.
Scope: This Process is designed to meet Internal osFinancials requirements, External user requirements, and Development quality standards.
The Work Instructions are written to remind developpers what needs to be done. They are not written to exhaustively instruct developpers on how to do their job. Where detailed instructions are necessary, they are linked as separate documents so that they do not clutter this wiki.
This Process is subdivided into five phases. Each phase contains a logical grouping of activities that should be executed as a unit. The phases are:
1. Tracker Validation 2. Tracker Acquisition 3. Solution Design 4. Solution Implementation 5. Solution Delivery
PURPOSE:
* Resolve reporter issues through solutions, explanations, and recommendations.
PRE-CONDITIONS:
* A tracker is created by reporter or developer.
PROCESS REQUIREMENTS:
* The Tracker Validation phase is completed within 2 business days of Tracker creation.
DELIVERABLES:
* Solutions for "accepted" Trackers, delivering a fix or an enhancement.
* Resolutions for "rejected" Trackers, explaining why a Tracker cannot be resolved in the manner
the reporter or Developer requests and offering recommendations or workarounds.
OWNERSHIP:
* Quality Control Manager owns the procedure
* osFinancials Management are responsible for enforcing commitment to process
* Module Owners and Developers are responsible for knowing and following the process as well
as providing feedback to Management and Quality Control Manager
Outline of procedure
Decision 1: Is tracker valid?
Decision 1: Is Tracker valid?
Yes: Goto Activity 2: Acquire Tracker
Task 1: Verify if Catagory is correct
Responsibility: Domain Owner
Guideline:
PURPOSE:
* Ensure that a Tracker is logged in the proper Catagory
PRE-CONDITIONS:
* None.
EXPECTATIONS:
* None.
DELIVERABLES:
* A Tracker in the proper Catagory * A comment on the Tracker as to why the Tracker was moved to another Catagory.
WORK INSTRUCTIONS:
Step 1: Read the Tracker summary and all comments. Quick source code checks are ok. Step 2: Decide if the described issue belongs in the current Catagory or another. Step 3: If you move the Tracker to a new Catagory, add a comment explaining why.
ADDITIONAL RESOURCES:
Consideration for this Process:
Task 2: Verify if tracker information is complete
Responsibility: Domain Owner
PURPOSE:
* Ensure that the Tracker text and/or comments contain all necessary information to reproduce.
PRE-CONDITIONS:
* None.
EXPECTATIONS:
* None.
DELIVERABLES:
* An effectively documented Tracker.
WORK INSTRUCTIONS:
Step 1: Read the Tracker and all comments.
Step 2: Verify that the Tracker contains all "necessary" information from the Tracker template.
Step 3: If Tracker information is acceptable, continue to the next task.
Provide a comment on the Tracker explaining anything out of the ordinary.
Step 4: If Tracker requires more information:
* Add your name to the "Assignee" field
* Email the Reporter via Sourceforge, identify what is missing and what you need
* Set the Status of the Tracker on "Pending" and the Groupstatus on "Waiting"
ADDITIONAL RESOURCES:
See document "Acceptance criteria"
Consideration for this Process:
Task 3: Accept or reject tracker
Responsibility: Domain Owner
PURPOSE:
* To accept a Tracker as an issue/enhancement or reject it with explanation.
PRE-CONDITIONS:
* The Tracker needs to be in the right Catagory, with adequate information for determining fault or functionality.
EXPECTATIONS:
* The Domain Owner will not close the Tracker without agreement by the Reporter.
DELIVERABLES:
* A "Previewed" Tracker * Rejected Tracker with Clear Resolution Text.
WORK INSTRUCTIONS:
Step 1: Understand the Reporters Issue.
* Read the comments on the tracker
* Reproduce the issue or examine Reporter’s reproduction
* Read help text and/or design documentation
Step 2: Evaluate the reported problem.
Three outcomes exist: Enhancement, Accepted, or Rejected.
Enhancement:
* Change Datatype from "Bugs" to "Feature Requists"
Accepted:
* Set Tracker Groupstatus to "Previewed"
* Assign Tracker to the proper specific Catagory
* Add a comment to the Tracker and include any appropriate comments or instructions for the Developer.
Rejected:
* Write a resolution text following the Resolution Text template, and completely fill in all
Capitalized sections.
This is important. If we cannot satisfactorily explain the rejection to the Reporter, the user community
will also never be satisfactorily accepting the explanation.
* Set the Tracker Groupstatus through to "Review" and assign it to the Domain Owner for review
* Email the Reporter via SourceForge with the Resolution Text and discuss it
Step 3: In case the reporter does not accept the outcome "Enhancement" and/or "Rejected" request an other developer
to give a second opinion.
ADDITIONAL RESOURCES:
See template " Resolution text "
See document " Resolution text "
Consideration for this Process:
Activity 2: Acquire tracker
Task 1: Search the appropriate queues
Responsibility: Developer
PURPOSE:
* Find a Tracker to solve.
PRE-CONDITIONS:
* The Tracker chosen must be "Previewed" by a Domain Owner.
EXPECTATIONS:
* The Developer will work FIFO based a manner as possible. No "cherry picking".
DELIVERABLES:
* A new Tracker in the personal queue of an Developer.
WORK INSTRUCTIONS:
Step 1: Sort the “Previewed” Trackers by order of weight in the Group. Step 2: Start at the top of the list (highest weight) and perform a fast analysis of each Tracker. Step 3: Select one you are capable of effectively solving. Step 4: Assign the Tracker to yourself.
ADDITIONAL RESOURCES:
Consideration for this Process:
Activity 3: Analyze Issue
PURPOSE:
Determine if the Tracker is an actual problem. Identify the breadth of the problem. Develop a complete understanding of the issue, reporters expectation, and intended functionality. Begin the process of planning a solution.
PRE-CONDITIONS:
Previewed Tracker assigned to an Developer. Tracker Groupstatus should be in "Design" in Developers queue.
EXPECTATIONS:
The Developer will put thorough effort into understanding what the reporter, what the software is actually doing, and what the software is intended/designed to do.
DELIVERABLES:
The Tracker goes into the "Design" phase
DESCRIPTION:
With "Analyze the Tracker" begins the solution design phase. The design phase includes:
1.Analyze Tracker (Activity 3)
2.Is this a Bad Fix? (Decision 4)
3.Does tracker lead to a Functional Change? (Decision 5)
4.Plan to resolve Reporters Issue (Activity 6)
Task 1: Read tracker information
Responsibility: Developer
Guideline:
PURPOSE:
* Understand the Reporters issue. * Understand the Domain Owner’s instructions. * Understand the software design (if one exists)
PRE-CONDITIONS:
* A Previewed Tracker in your name.
EXPECTATIONS:
* The Developer will take time to understand the Reporters issue and their expectations. * The Developer will pay attention to any instructions or hints given by the Domain Owner.
DELIVERABLES:
* None.
WORK INSTRUCTIONS:
Step 1: Set Tracker Groupstatus from "Previewed" to "Design". Step 2: Read the Tracker summary and all comments. Step 3: Read any available design/development documentation.
ADDITIONAL RESOURCES:
None
Consideration for this Process:
Task 2: Reproduce problem
Responsibility: Developer
Guideline:
PURPOSE:
* Gain an understanding of how the reported issue occurs so that an Developer can
determine if it is actually a bug in the software or standard functionality.
* Have test data prepared for efficient solution testing.
PRE-CONDITIONS:
* The Developer understands the reporters expectations as written on the Tracker
EXPECTATIONS:
* An Developer will think critically about the reproduction steps and keep in mind:
- The reporters expectations for the session
- The intended functionality (design) of the session
DELIVERABLES:
A Tracker ready for a solution design or a Resolution text.
WORK INSTRUCTIONS:
Step 1: Reproduce the issue (or review reproduction) on an up- to-date server.
ADDITIONAL RESOURCES:
Consideration for this Process:
Task 3: Check other modules
Responsibility: Developer
Guideline:
PURPOSE:
* Understand the depth or extent of the problem to help determine:
- how one addresses the issue
- who must be involved
- how long it could take to resolve it
* Understand how similar sessions or modules deal with the same issue.
PRE-CONDITIONS:
* Developer understands the reporters expectations as expressed on the Tracker * Developer understands the intended/designed functionality of the session * Developer understands how the session is actually functioning
EXPECTATIONS:
* The Developer will carefully look at similar sessions and other modules.
DELIVERABLES:
* A Tracker ready for further analysis or a Resolution Text.
WORK INSTRUCTIONS:
Step 1: Look for sessions with similar functionality within the module. Step 2: Consult with other developers or the Domain Owner.
ADDITIONAL RESOURCES:
Consideration for this Process:
Decision 4: Is Issue a bad fix?
Task 1: Determine if the issue is a result of a former bad fix
Responsibility: Developer
Guideline:
PURPOSE:
* Determine if a solution less than 1 year old caused the problem.
PRE-CONDITIONS:
* The Developer understands:
- The reporters expectations
- What the intended functionality is
- What the session is currently doing and why
- Where else the problem may occur
* The Developper is fairly confident that the issue is a problem and not standard functionality.
EXPECTATIONS:
* The Developer will inform the "bad fix Developer" about the bad solution found and discuss the background of it.
DELIVERABLES:
* None.
WORK INSTRUCTIONS:
Step 1: Look in the scripts. Determine if the problem is caused by a solution.
Step 2: If a solution caused the problem, check the date of the solution in the Script header.
Step 3: If the solution is older than 1 year, this task is complete. Do nothing.
Step 4: If the solution is less than 1 year old, then update the following on the Tracker:
- Enter the offending Trackernumber into a comment in the Tracker.
Step 5: Call, or email the Developer who created the bad fix and discuss it.
ADDITIONAL RESOURCES:
Consideration for this Process:
Decision 5: Does tracker lead to a Functional Change?
Task 1: Is the required Functional Change a Functional Modification or a Functional Addition?
Responsibility: Developer and Domain Owner
Guideline:
PURPOSE:
* Determine if the Tracker leads to a Functional Change and needs to be discussed in leadership team.
PRE-CONDITIONS:
* The Developer is convinced that the Tracker leads to a functional change
EXPECTATIONS:
* None.
DELIVERABLES:
* The Tracker processed through the leaderships team.
WORK INSTRUCTIONS:
Step 1: Start the leaderships evaluation process with the Tracker.
ADDITIONAL RESOURCES:
Consideration for this Process
Activity 6: Resolve reporters issue
Task 1: Determine if resolution or solution is required
Responsibility: Developer
Guideline:
PURPOSE:
* To finally decide if the issue on the Tracker can (or should) be solved through a software fix or a resolution text.
PRE-CONDITIONS:
* The Developer understands what the reporter wants and what the session actually does.
* For Resolution Text: The Developer is convinced that the session is functioning correctly or
that the requested change is not possible or acceptable.
EXPECTATIONS:
* The Developer must consider and provide as many workarounds and recommendations as possible
in the Resolution Text.
* A Tracker will not be solved with a Resolution Text until the Module Owner agrees that the resolution
is complete and acceptable.
DELIVERABLES:
* Clear Resolution Text
WORK INSTRUCTIONS:
Step 1: Weigh all the information gathered from reading, discussing, and reproduction. Step 2: Decide whether to accept the Tracker or reject it. Step 3: If the Tracker is accepted, set the Groupstatus to "Design" and proceed to Solution Design. Step 4: If the Tracker is rejected, then a clear, complete resolution is required. Step 5: Write the resolution text. * Email the Module Owner with the resolution Text and discuss it * Set the Tracker Groupstatus through to "Review" and assign it to the Module Owner for review
ADDITIONAL RESOURCES:
Consideration for this Process:
Task 2: Determine optimal solution
Responsibility: Developer
Guideline:
PURPOSE:
* Identify multiple solution designs and choose the best blend of "complete" and "possible"
PRE-CONDITIONS:
* The developer understands what the reporter wants, what the session actually does,
and what the session is supposed to do.
EXPECTATIONS:
* The solution will not decrease session/system performance * The solution will fit within current functionality
DELIVERABLES:
WORK INSTRUCTIONS:
Step 1: If multiple solution options exist, document in a comment the different solutions options. Step 2: Include in the comment the reason why one solution design is chosen over another.
ADDITIONAL RESOURCES:
Consideration for this Process
Task 3: Create "Analysis and Design"
Responsibility: Developer
Guideline:
PURPOSE:
* Create the "Analysis and Design" comment, if required by the Domain Owner.
PRE-CONDITIONS:
* The Developer understands what the reporter wants, what the session actually does,
and what the session is supposed to do.
* The Domain Owner requests an "Analysis and Design" to be created.
EXPECTATIONS:
* The "Analysis and Design" will be created before any coding is done. * The Domain Owner will review the "Analysis and Design"
DELIVERABLES:
* Tracker with an "Analysis and Design" comment, in "Review" status
WORK INSTRUCTIONS:
Step 1: This task is only executed upon the request of the Domain Owner.
Create a new comment named "Analysis and Design" for the Tracker.
Step 2: Select "Analysis and Design Template" from the Template selection.
Step 3: Fully complete the template.
The intension is to fully document your Tracker analysis and solution design for review.
Step 4: Submit the Tracker for review to the Domain Owner
ADDITIONAL RESOURCES:
Consideration for this Process:
This step exists for those situations where the Domain Owner wants to review the Tracker analysis and approve of the solution design before any code change occurs. Three common instances exist where this task is useful: * Training new Developers * Tracker requiring significant modifications * Tracker requiring changes in multiple packages and modules
Activity 7: Implement solution
Task 2: Implement Solution in latest version
Responsibility: Developer
Guideline:
PURPOSE:
* Modify components to create a solution to the issue.
PRE-CONDITIONS:
* None.
EXPECTATIONS:
* None.
DELIVERABLES:
* None.
WORK INSTRUCTIONS:
Step 1: Set the Groupstatus on the Tracker to "In Process" Step 2: Make modifications Step 3: Test your modifications.
ADDITIONAL RESOURCES:
None.
Consideration for this Process:
Activity 8: Submit Solution for Review
Task 1: Create "Technical Release Notes" and "Solution Text"
Responsibility: Developer
Guideline:
PURPOSE:
* Create Technical Release Notes to describe what was wrong, what is right, how to fix it,
what has been changed, and the testing results.
* Create the text for the Solution Comment.
PRE-CONDITIONS:
* The Developer has developed, coded, and tested a solution to the problem.
EXPECTATIONS:
* The Technical Release Notes must fully document all information on the solution for the problem. * Writing standards must be followed. * The template should be used.
DELIVERABLES:
* A Tracker ready for Domain Owner review.
WORK INSTRUCTIONS:
Step 1: Fill out the Solution template fields. Step 2: Fill out the Technical Release Notes template fields. Step 3: Run spell checker.
ADDITIONAL RESOURCES:
osFinancials Writing standards
Consideration for this Process:
Task 2: Assign Tracker to Domain Owner
Responsibility: Developer
Guideline:
PURPOSE:
* Move the Tracker to the Domain Owner for review.
PRE-CONDITIONS:
* Technical Release Notes is written, solution is written, and everything is tested and ready for the quality review.
EXPECTATIONS:
* None
DELIVERABLES:
* A Tracker assigned to Domain Owner
WORK INSTRUCTIONS:
Step 1: Assign the Tracker to the Domain Owner Step 3: Set the Tracker Groupstatus to "Review"
ADDITIONAL RESOURCES:
Consideration for this Process:
Activity 9: Review Design or Solution
Task 1: Review Design
Responsibility: Domain Owner
Guideline:
PURPOSE:
* Verify that the problem analysis is on target and the Developers solution proposal is both correct and doable.
PRE-CONDITIONS:
* The Domain Owner has requested an Analysis and Design. * The Developer has researched the problem and created an Analysis and Design.
EXPECTATIONS:
* The Domain Owner will determine if the proposal is correct and possible to do.
DELIVERABLES:
* The Analysis and Design is approved (Tracker returned to Developer "In Process") * The Analysis and Design is rejected (Tracker returned to Developer "In Design") and a Resolution Text is requested. * A comment is created stating that the Design is approved or rejected with reasons.
WORK INSTRUCTIONS:
Step 1: Read the comments on the Tracker, pay close attention to the Analysis and Design.
Step 2: Judge if the Developers analysis of the problem is complete and correct.
Identify anything missing and record in the Design Review comment.
Step 3: Judge if the Developers solution proposal is complete correct.
Identify anything missing and record in the Design Review comment.
Step 4: Determine if the proposal can be implemented.
The change may be too drastic or cause too much difficulty.
A resolution text may still be required.
ADDITIONAL RESOURCES:
Consideration for this Process:
Task 2: Review Solution (Technical Review)
Responsibility: Domain Owner
Guideline:
PURPOSE:
* Common Sense Quality Control * Review the solution from a technical viewpoint to ensure correct implementation.
PRE-CONDITIONS:
* The Developer has implemented and tested a solution. * Technical Release Notes exists. * Solution comment exists.
EXPECTATIONS:
* The Domain Owner will:
- Catch bad fixes before they are delivered.
- Verify all osFinancials standards are followed.
- Ensure that the solution exists in all the necessary places (nothing missing).
DELIVERABLES:
* A Review Comment on the Tracker. * If rejected, the Tracker returned to the Developer with a Groupstatus of "In Process".
WORK INSTRUCTIONS:
Step 1: Read all the comments on the Tracker, pay close attention to the Technical Release Notes.
Step 2: Do a Technical Review of code/component changes and check for:
- Correct markings and spacing
- Programming Standards
- Impact on session performance
- Future maintainability of the solution
Step 3: Identify anything that must be fixed from the Technical Review in a Review Comment.
If all is well, state that the Technical Review is good.
Step 4: If the Tracker fails, return it to the Developer with Groupstatus "In Process".
Step 5: If the Tracker passes the Technical review, continue to the Functional review.
ADDITIONAL RESOURCES:
Consideration for this Process:
Task 3: Review Solution (Functional Review)
Responsibility: Domain Owner
Guideline:
PURPOSE:
* Common Sense Quality Control. * Ensure that the solution works as intended and functions properly within the larger business process.
PRE-CONDITIONS:
* The Developer has implemented and tested a solution. * Technical Release Notes exists. * Solution comment exists.
EXPECTATIONS:
* The Domain Owner will:
- Catch bad fixes before they are delivered.
- Verify all Development standards are followed.
- Ensure that the solution exists in all the necessary places (nothing missing).
DELIVERABLES:
* A Review Comment on the Tracker. * The Tracker returned to the Developer with a Groupstatus of "In Process" if rejected or "Deliver" if accepted.
WORK INSTRUCTIONS:
Step 1: Read all the comments on the Tracker, pay close attention to the Technical Release Notes.
Step 2: Do a functional review of the solution for completeness and correctness.
- Does the fix fit the current or intended design of the session?
- Does the fix impact the current/intended design of subsequent sessions in a business process?
- Did the Developer consider and handle all aspects of the problem?
Step 3: Identify anything that must be fixed from the Functional Review in a Review Comment.
If all is well, state that the Functional Review is good.
Step 4: If the Tracker fails the Functional Review:
- Identify the reasons for failure in the Review Comment.
- Return the Tracker to the Developer with Groupstatus "In Process".
Step 5: If the Tracker passes the Functional review, continue to the Solution comment review.
ADDITIONAL RESOURCES:
Consideration for this Process:
Task 4: Review Solution (Solution comment Review)
Responsibility: Domain Owner
Guideline:
PURPOSE:
* Common Sense Quality Control
PRE-CONDITIONS:
* The Developer has implemented and tested a solution. * Technical Release Notes exists. * Solution comment exists.
EXPECTATIONS:
* The Domain Owner will:
- Catch or Correct poorly written solution comment.
- Verify all osFinancials standards are followed.
- Review the Solution comment for proper English usage and descriptions.
DELIVERABLES:
* A Review Comment on the Tracker. * The Tracker returned to the Developer with a Groupstatus of "In Process" if rejected or "Deliver" if accepted.
WORK INSTRUCTIONS:
Step 1: Read all the comments on the Tracker, pay close attention to the Technical Release Notes.
Step 2: Review the Solution comment.
- Verify correct use of English language and grammar.
- Ensure compliance with osFinancials writing standards.
Step 3: If all is approved or fixed on the Solution comment, put Tracker on status "Deliver" to the Developer.
Step 4: Identify any changes necessary to the Solution comment in the Review Comment.
At the discretion of the Review, he or she may make the necessary changes to the Solution Document.
If all is well, state that the Solution comment is good.
Step 5: If the Solution comment fails, return to the Developer with Groupstatus "In Process".
Step 6: If the Solution Doc passes, continue to Final Review Tasks.
ADDITIONAL RESOURCES:
Consideration for this Process:
Task 5: Review Solution (Final tasks)
Responsibility: Domain Owner
Guideline:
PURPOSE:
* Common Sense Quality Control.
PRE-CONDITIONS:
* The Technical, Functional, and Solution comment reviews have been successfully completed.
EXPECTATIONS:
* The Domain Owner will ensure that the solution exists in all the necessary places (nothing missing).
DELIVERABLES:
* A Review Comment on the Tracker. * The Tracker returned to the Developer with a status of "Deliver" if all is acceptable.
WORK INSTRUCTIONS:
Step 1: Reminder: If all the reviews are acceptable, create a Review Comment that states:
- Code/Component Changes are reviewed and approved.
- Functional Test/Behavior is approved.
- Solution comment is reviewed and approved.
Step 2: If further testing is required, assign Tracker to the testing Developer.
Step 3: If all is well, assign the Tracker to the Developer in Groupstatus "Deliver".
ADDITIONAL RESOURCES:
Consideration for this Process:
Task 6: Extra Testing
Responsibility: Domain Owner & Developer
Guideline:
PURPOSE:
* Do a deep, unit and/or system test on a solution to verify correctness. * Have a second pair of eyes test the solution.
PRE-CONDITIONS:
* The Developer has implemented and tested a solution. * The Domain Owner (or designate) has reviewed and tentatively approved the solution.
EXPECTATIONS:
* The Test Developer will test the specific solution as well as the business process surrounding the defect.
DELIVERABLES:
* A Test Comment on the Tracker. * The Tracker returned to the Developer with a Groupstatus of "In Process" if rejected or "Deliver" if accepted.
WORK INSTRUCTIONS:
Step 1: Read all the comments on the Tracker, pay close attention to the Module Owners Comments. Step 2: Execute any actions requested by the Owner. Step 3: Determine if the Developer took into account all relevant functional issues. Step 4: Write up all results in a Testing Comment on the Tracker. Step 5: If the solution requires rework, assign back to the Developer with Groupstatus "In Process". Step 6: If all is well, state so in the comment and assign to Developer with Groupstatus "Deliver".
ADDITIONAL RESOURCES:
Consideration for this Process:
Activity 10: Deliver Solution
Task 1: Export solution to SourceForce download
Responsibility: Developer
Guideline:
PURPOSE:
* Export the solution to the Web.
PRE-CONDITIONS:
* The Domain Owner has reviewed the solution and approved. * The Developer has fixed anything requested by the Domain Owner. * If necessary, a follow-up review was done (if the solution failed a previous review)
EXPECTATIONS:
* None
DELIVERABLES:
* Exported solution.
WORK INSTRUCTIONS:
Step 1: Export the modified program.
ADDITIONAL RESOURCES:
Consideration for this Process:
Task 2: Set tracker in Solved and Closed status
Responsibility: Developer
Guideline:
PURPOSE:
* Complete Delivery Process by solving defect.
PRE-CONDITIONS:
* Tracker has Groupstatus "Deliver"
EXPECTATIONS:
* None
DELIVERABLES:
* Tracker is set to "Solved" and "Closed".
WORK INSTRUCTIONS:
Step 1: Review Solution comment one final time. Make sure that:
Step 2: If the solution contains a new generic correction program, contact Pieter Valentijn.
Pieter maintains the list of generic correction programs. Step 3: Set Groupstatus of the Tracker to "Solved". Step 4: Set the Status of the Tracker to "Closed".