- Published
- 8 October 2026
- Last reviewed
- 8 October 2026
How to use these FAQs
Describe a reproducible defect, distinguish retesting from regression checks and keep test evidence useful.
Select a question to expand its answer. The first answer is open initially; each answer can be opened or closed independently. These are original RDE practical explanations. Any example described as fictional is a teaching scenario.
Common questions
What should a defect report explain?
State the environment, relevant starting conditions, steps, expected behaviour and observed behaviour. Include a useful reference and supporting evidence without exposing private data. For a fictional form, explain which field and input produced the problem. Another person should be able to investigate the same situation rather than receiving only “the page is broken”.
Are severity and priority the same?
No. Severity describes the effect of a problem; priority concerns the order or urgency of addressing it. Teams define their scales differently. A minor visual fault may be urgent for a launch, while a serious fault in an unused route still needs careful assessment. Explain the impact and let the authorised process determine scheduling.
How do I report an intermittent problem?
Record what you observed, how often it occurred in your attempts and the conditions you could identify. Preserve useful logs or references through approved channels. Do not invent a reliable reproduction step if none is known. A report that states uncertainty clearly can still help investigation, especially when timing, network conditions or a particular account may matter.
What is confirmation testing?
It checks whether the reported defect has been corrected, often by repeating the previously failing test under suitable conditions. Record the version and result. For a fictional validation fault, repeat the input that triggered it and check the expected message. A successful check confirms that case; it does not automatically prove that every related behaviour is unaffected.
How is regression testing different?
Regression checks look for unintended effects of a change in areas that previously worked. Choose relevant checks based on dependencies and risk. After a fictional form correction, you might also check a valid submission and confirmation. Repeating only the failing case can miss a new problem elsewhere, while a broad test list without purpose may waste effort.
Can I close a defect when a developer says it is fixed?
Follow the team’s agreed closure and verification process. A fix notification is evidence that a change was made, not necessarily that it meets the expected behaviour. Record the tested version, result and remaining limitations. If the environment prevents verification, state that status honestly instead of marking the issue as confirmed without the required check.
Put one answer into practice
Choose the question closest to your current task. Write one action in your own notes, identify the information or permission you need and set a review point. Use the related resources below to develop the task further. No response is submitted or stored by this page.
Sources and scope
The sources below provide relevant context and terminology. The examples, practical suggestions and wording are original RDE teaching material. Apply your organisation’s policies and the guidance relevant to your situation. Reviewed 8 October 2026. Author: Jefferson Otonbara Imgbi.
Cover image: AI-generated illustrative scene created specifically for this resource.