Step 4: Format your report for high readability Error logs, which exist for most applications, regardless of whether they are mobile, web, or legacy attach a copy of the log or copy and paste the text into your description be sure to identify which log file, if there is more than one.Screen shots or full text of error messages in the description or as an attachment.Database query and screen shot of the results.Recorded video of the steps you take and the application's reaction (choose from several free video programs available online or just use your smart phone).The five types of supporting documentation to consider using are: Similar to adding a note, this gives backup support that the defect exists and is not only a UI issue. ![]() Additionally, list any database query results or error log files. This helps developers figure out the problem more efficiently. It will create a screenshot-by-screenshot view of where you clicked and the location of the code. If you're using Microsoft products, there's a free Step Recorder application you can use to step through the problem. Step 3: Add supporting documentationĪdd or attach a step recorder file or video of the defect wherever possible. "Notes" are good ways to communicate to the developers what research you’ve done so they can determine where they need to start. Database table displays the correct allergy value on the patient. NOTE: Configuration set to block medication entry when any related allergy exists on the patient record regardless of severity value. Look for error log statements, if possible.īe sure to add any research performed to the end of your defect report in a note format. Do your best to ensure you have laid down an accurate foundation. Research means making sure the defect is truly a defect. You’ll want to check configuration settings, patient settings, user settings-anything in the application that affects how it functions. It may be the one thing many reviewers read, so it’s essential to describe the problem effectively. The description is going to be followed by additional detail, so keep it short and to the point. User is able to enter and save the medication that the patient is allergic to. Next, you need to add a brief description in the body of the defect report:Īllergy button fails to highlight in red when an allergy is saved on the patient record. Additionally, allergy entry is configured to disallow medication entry of the interacting medication. This is a brief statement of the problem in a concise and understandable sentence. In my summary title, I’ll enter the area and the general function:Īllergy button not highlighted in red and user able to enter medication. The allergy button doesn’t highlight in red to visually indicate the allergy, and worse, it allows the user to enter the very medication in question, regardless. Also, you can’t assume developers or other defect reviewers know how the application works in all instances.įor example, I’ve found a defect in a medication-management application a user is able to enter a medication that the patient record showed a severe allergy to. Why? Because most applications are highly integrated and therefore complex. When writing a summary in the defect title, include the area and function where the problem occurs. The first step is to define the defect by writing a summary in the defect title and providing a general description of the problem. ![]()
0 Comments
Leave a Reply. |