Scenario 1 – Make a Cup of Tea
Welcome to the new office kitchenette! Please feel free to use the supplies on hand to enjoy a fresh cup of tea at any time.
To make tea:
Remove empty tea kettle from the range and bring under the sink spigot. Remove the kettle center lid and fill halfway with water, making sure water does not cover the interior spout. Re-cover the kettle and place on the center of one of the range burners.
To start the range, push the knob firmly inward while turning slightly to the “light” position. Once a flame is produced turn the knob further until the med-high temperature marking. While the water in the kettle is being heated prepare your cup of tea.
First retrieve a cup and a tea bag packet of black tea. Open the tea bag packet and remove the actual tea bag from the pouch. You will need to gently tug the string free from the bag itself to later retrieve the tea bag from the hot cup of tea. Place the dry tea bag inside of the empty cup and allow the string to hang over the rim of the cup and down the outside. Have at hand any other ingredients you would like to add to the tea before drinking, such as milk and sugar.
Once the kettle begins to whistle this indicates that the water inside has reach boiling. Remove the kettle from the burner while extinguishing the remaining flame. Place the kettle on a heat safe, level surface.
Depending on what you like to add to your tea will determine how much water to the cup. For people who like their tea black, you may fill the cup with about 7 ounces of hot water while holding onto the end of the tea bag string to prevent it from being carried into the cup. This will give you some room in the 8-ounce cup so that the liquid will should not spill when the cup is carried back to the workstation. For anyone who likes a spoon full of sugar and a generous amount of milk in their tea, like me, it is recommended that you fill the cup with about 4 ounces, or about halfway, to leave room for the increased volume once the milk is added.
Once you have added the hot water allow the tea bag to steep, sit in the water, for 3-5 minutes before using the tea bag string or a spoon to remove the bag from the water to a paper towel for disposal. Remember that the tea bag will be quite hot at this time so use caution when removing and transporting it to the disposal. Once that is complete feel free to add any additional ingredients you enjoy to your tea.
Scenario 3 – Developing, Editing, and Approving Procedures
1. Purpose
1.1. Procedures can be developed at any time by creating new documents or revising existing Procedures. These documents must be uploaded, approved, and maintained using the ABC Document Management System which is governed by SOP 890-123: ABC Document Management System General Use. All procedures must be created using the master Procedure Template stored in the ABC Document Management System.
2. Scope
2.1. In scope for this Procedure are any newly created, existing, or revised Procedures. Any Procedure document written by any SME or team members.
3. Procedure
3.1. Content Creation
3.1.1.Content may be developed by a single SME or group as well as team members.
3.1.2.Content may be given to the technical writer for review/processing.
3.1.3.The SME, team, or Technical Writer are responsible to work together to build and facilitate the draft of any documents
3.1.4.The Technical Writer will be responsible for executing the procedure, including managing the approval process in ABC Document Management System.
3.2. Content Review
3.2.1.Content must be reviewed by a minimum of two members of the department that will be executing the procedure while in a draft state.
3.2.2. A member of the Quality Team must review all Manufacturing procedures, prior to moving on to the initiate state.
3.2.3.The Technical Writer should ensure that there are no errors in the document, including grammar and formatting.
3.2.4.Documents can often be held up in this state while awaiting review if the reviewers have a queue of documents waiting. This could lead to late or missing deadlines, so it is important to monitor the review process.
3.3. Submitting to Document Management System
3.3.1. Source documents must be rendered in the ABC Document Management System before they can be approved
3.3.2.When uploading documents there may be errors in formatting and other issues. This may require that the document is uploaded more than once until there are no errors.
3.4. Sending for Approval
3.4.1.Once the document has been initiated it is time for it to go through the formal review process in the Document Management System. The final approver should always be listed as the General Operations Manager once all other approvals are completed.
3.4.2.Documents can often be held up in this state while awaiting approval. It is important to monitor the progress of the document, so it is not sitting in any one reviewer’s queue for any length of time. This is important to maintaining target deadlines.
3.4.3.The team is not automatically notified when a document is fully approved in the ABC DMS so monitoring of the document status is important.
3.5. Finalizing Document
3.5.1.The final approved PDF will be stored in the ABC Document Management System.
In this presentation we are going to be talking about tracking bugs and defects found in testing environments. First, we are going to look at the difference between bugs and defects, and how they compare to incidents. Then, we will talk about logging and tracking the bugs and defects in Jira. And finally, the workflow to resolve the bugs and defects. The important thing to note is the priority and severity which allows us to better resolve the bugs and defects.
Slide 2
A bug is software failure, unplanned software feature or error in the software in any of the test environments. This is listed in Jira as a standalone issue. A defect is an error in the software that is observed during testing and is blocking a story from moving to “Done”. This is listed as a subtask of the parent story. Any errors found during production are listed as incidents which have their own triage and workflow separate from this presentation.
Slide 3
Recording a bug as a standalone issue in Jira is an important step in the tracking process. This can be linked to a relevant story if applicable to better define the bug. A bug may be detected at any point in any of the testing environments, Dev, QA, or Stage.
Slide 4
A defect is an intrinsic part of a story. Without the defect being fixed a story cannot be moved to “Done”. However, if the defect cannot be resolved in the current release it and be converted to an “issue” which then needs to be resolved in the following release.
Slide 5 and 6
Filling out the Bug information in Jira.
Slide 7
Priority is the measure of the impact to the Business. P1 If a risk in the Risk Assessment has a Risk Priority Number (RPN) of 10-25. Refer to WI-0049 for information about completing the RA. A priority of 1 means that the issue is preventing the completion of a release. This means that the issue could be blocking a piece of functionality, or that it is blocking further testing from moving forward. Anything with a priority level 1 must be fixed IMMEDIATELY, because it is blocking or breaking a feature, before the release can move forward.
P2 is any RPN of 5-9 in the RA. This is an issue that is critical to complete like the testing of a feature being blocked or serious performance degradation. In order to complete the story this issue Must be Fixed to close the release.
P3 issues should be fix, if possible, in this release. A P3 is generated when the RPN is below 5. The issue has a workaround that allows business to continue as normal. While its important to fix this issue, the release can still be closed without a fix. Examples are minor performance issues that do not block use of the product.
P4 is for issues that occur infrequently however, the fix is not apparent initially and requires more research. This issue has a workaround and does not affect the operations included in the release or is a cosmetic fix.
Slide 8
Severity is the measure of the impact to the consumer of the deliverable. S1 is for serious issues that can affect patient safety. Examples are Serious data loss or corruption, exploitable security vulnerability, critical compliance risk. There is no acceptable workaround to resolve the issue so it must be fixed immediately.
S2 is a major issue that can have a complicated workaround but should be fixed in the release, these issues are based on functionality and performance. Examples include the software operating contrary to the requirements, there is significant performance degradation or data issues that can cause non-patient related safety issues.
S3 is a minor issue that has a simple work around and does not impact a large group of users. This can be a minor compliance or performance issue. This does not affect patient safety.
S4 is an issue that is trivial. These issues are usually cosmetic and represent small distractions that distract from the overall experience, grammar or spelling, font or font color, vague error messages.
Slide 9
Description of bug or defect
Slide 10
Steps to reproduce
Slide 11
Actual Behavior, what is actually happening that different from the intended behavior.
Slide 12
Expected behavior, what should be happening that is not occurring.
Slide 13
Managing Bugs Process Diagram
What is the process for fixing a bug or defect and what does it look like as a workflow.