| Quality Control |
 |
 |
 |
| Written by Domé Giuliano | |||
|
There are no translations available. Quality ControlQuality Control ProceduresWhy Quality Control for osFinancialsAs 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.
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 useWe will be using the tracker systemon the SourceForce project page. Maintenance ProcessesPurpose: 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
* Resolve reporter issues through solutions, explanations, and recommendations.
* A tracker is created by reporter or developer.
* The Tracker Validation phase is completed within 2 business days of Tracker creation.
* 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.
* 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 correctResponsibility: 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 completeResponsibility: 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 trackerResponsibility: 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 trackerTask 1: Search the appropriate queuesResponsibility: 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 IssuePURPOSE: 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 informationResponsibility: 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 problemResponsibility: 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 modulesResponsibility: 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 fixResponsibility: 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:
Activity 6: Resolve reporters issueTask 1: Determine if resolution or solution is requiredResponsibility: 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 solutionResponsibility: 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 solutionTask 2: Implement Solution in latest versionResponsibility: 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 ReviewTask 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 OwnerResponsibility: 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 SolutionTask 1: Review DesignResponsibility: 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 TestingResponsibility: 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 SolutionTask 1: Export solution to SourceForce downloadResponsibility: 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 statusResponsibility: 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:
|
