"Escaped Issues" represent a crucial challenge in the feedback loops of testing. In the Testlio platform, these issues are identified when they bypass our standard testing procedures. As a result, we empower both our clients and service delivery coordinators to highlight these overlooked problems. It's essential to note that the process for addressing Escaped Issues in the Testlio platform is distinct from that of routine issues reported by freelancers or clients during their testing efforts. In our system, Escaped Issues are documented, monitored, and managed separately.
Report an Escaped Issue
Go to the appropriate workspace on the platform → Issues → Select New Escaped Issue.
A new modal is raised with key information to fill in.
You can report an escaped issue with these basic flow fields:
Field | Required/Optional | Explanation |
Title | Required | A brief title of the escaped issue in the |
Description | Optional | A detailed description of the issue including any applicable links or reference information (if possible, attach the email [without disclosing PII] or screenshots of communication) |
Found Date | Required | The date issue occurred and came to be known to the customer. We distinguish between found and reported dates to understand the delay it takes often to notify Testlio. |
Reported Date | Optional | The date escaped issue was reported to Testlio. |
Link to issue | Optional | URL reference to the same escaped issue in an external system. Use full URL (http://.. ) |
Attach file | Optional | Optional field to collect reference materials - like recordings, logs |
Advanced options offer more needed fields and information in order to resolve and close an escaped issue, complementing the basic flow fields:
Field | Required/Optional | Explanation |
Affected application | Optional | If we are testing multiple applications within a workspace, please fill in the application’s name that the escaped issue affects. |
Source | Required | Define the original source of the discovered escaped issue:
|
Capturer | Optional | Name of the person who noticed and captured the issue (typically our customer) |
Run | Required | Run where we should have caught the issue / where the customer expected us to catch the issue. Mark the earliest run |
Task | Optional | Task with which the escaped issue should have been discovered |
Drivers | Required | There can be more than one driver, select all that apply:
|
Expectations |
|
|
Severity | Required | Severity between Low / Medium / High (use the same reasoning as we have by default on our platform) |
Affected feature | Required | Select the feature that the escaped issue affects (same as for any other issue report) |
Device | Optional | Device/configuration on which the issue appeared |
Resolved Date |
| The date when the analysis is fully completed and remediation steps done |
Root Cause Description | Required | Bring out if it was:
This will be completed after investigation and should include details about why the issue escaped |
Remediation Description | Required | Details on how the problem was addressed. This should include how we addressed this with the client (credits, etc) and how we will prevent this in the future (added test cases, reported tester, etc). |
Labels | Optional | Labels for future filtering or custom tracking |
Note – required fields in the above-advanced field table represent needed fields to close an issue, not required fields to report an escaped issue.
Explanation of drivers
Category | Driver | General Source | Description |
Process Integration | Limited Coverage | Client/Testlio | Devices, locations, languages, and/or other aspects of coverage were not tested, because of: 1) scope/budget; 2) a decision based on focus; and 3) a misunderstanding. |
Process Integration | Build Delivery | Client | The customer provided an unanticipated or problematic build (including a web environment). Can include building access and sample data problems. Also includes lack of build receipt. |
Process Integration | Issue Escalation | Client/Testlio | Issues discovered were not clearly presented to the correct action source. |
Process Integration | Issue Remediation | Client | Issues were not resolved sufficiently before the production release. |
Test Preparation | Team Onboarding | Client/Testlio | Testers, Coordinators, Scripters, and/or other participants were not sufficiently skilled, trained, or equipped to perform key tasks. This can include poor selection decisions. |
Test Preparation | Testing Instructions | Client/Testlio | The Run Instructions, Test Case, and/or other directions were problematic. This can include missing tests. |
Test Preparation | Testing Methodology | Testlio | Testing techniques (e.g. functional v exploratory, positive v negative) were poorly selected, badly designed, and/or weakly implemented. |
Testing Execution | Insufficient Testing | Tester | Unintentional missed issue. Tester did the work by following instructions but did not "see" the issue, potentially because of fatigue, misunderstanding, miscommunication, limited time, or other problems. |
Testing Execution | Misaligned Testing | Tester | The tester did not follow the instructions given in the task potentially due to lack of attention, sloppiness, or other factors, resulting in a wrong testing setup or incorrect testing scenarios. |
Testing Execution | Misrepresented Testing | Tester | Intentional breach of Freelancer Agreement. Tester knowingly misrepresented their work (e.g. false passes), location, equipment, skills, time, or other factors (can include tester subcontracting work to someone else and/or parallel testing). |
Close an Escaped Issue
Once an escaped issue is recorded and remediation completed, then closing the issue follows the same model as the regular issue. When closing issues, ensure that all required fields are completed and if possible, also collect optional data fields for greater impact on future testing loops and learnings.