Emergencies happen in life and it may occur that a QA engineer who is the lead for a project is not available for some reason. The backup plan is more of a philosophy or mindset that we adhere to rather than a concrete procedure.
If the lead QA Engineer is unavailable to QA a project that has a short turn around, you can reach out to another QA Engineer. Depending on the level of emergency, the Lead QA Engineer may help coordinate a Substitute QA Engineer covering for them, or the Project Manager may need to do this.
As stated in Project Lifecycle, QA engineers should have access to all projects in Basecamp, whether they are the lead or not. However, to cut down on unnecessary notifications, QA engineers unsubscribe from projects that they are not the leads on. Therefore, when pulling in an additional or Substitute QA engineer, that engineer must be tagged within a thread in the project (ideally the to-do that the engineer is needed in).
Project managers/coordinators are also encouraged to message/ping the Substitute QA Engineer to ensure that they are aware of being needed.
Finally, QA Engineers are also encouraged to checked their Assignments list (especially those with dates) as best practice to ensure that tasks do not get missed.
The basics of what QA expects to have when getting started testing, and what we'll produce for the team, are consistent. If one QA engineer needs to substitute for another, they would know to expect a QA document and a description of the tests; that we'll produce a list of issues for them to fix, etc. (Refer to the "QA Process and Stages" section within QA & Project’s Lifecycle.)
Testing a project is standard to the degree that the QA engineer follows the Checklist and reports issues with a standard nomenclature format. (Refer to "Naming/Labeling Issues" within QA Overview.)
Each QA engineer has their own unique approach for executing a QA test that cannot be replicated by others.
When the original QA engineer returns to the project, the Lead and Substitute may need to split work within the task until particular issues are resolved. If one engineer finds an issue that the other has no familiarity with, it makes more sense to have the engineer who found the bug work on that issue than to pull in a new engineer.
This is also true for when ownership of a project passes from one Lead QA engineer to another.
QA & Project’s Lifecycle
QA (Quality Assurance) Overview