To maintain a continuity of specialized knowledge, QA Engineers are assigned to clients and their encompassing projects. When a new project starts, the Strategist and PM on the project determine who the lead QA Engineer will be.
That being said, emergencies happen in life. It may occur that the QA Engineer assigned to a project is not available for some reason. This is where the backup plan comes in.
The Backup Plan
The backup plan is more of a philosophy or mindset that we adhere to rather than a concrete procedure.
If the assigned QA Engineer on a project is unavailable to QA a task according to its deadline, the Project manager can reach out to another QA Engineer to substitute. Depending on the level of emergency, the project’s typical 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 managers/coordinators are also encouraged to message/ping the Substitute QA Engineer to ensure that they are aware of being needed.
The basics of what information QA engineers expect to be given when receiving an assignment and what they know to produce for the team are consistent. So, if one QA engineer needs to substitute for another, they would know to expect a QA document and a description of the tests; that they will produce a list of issues for the dev team to fix, etc. (Refer to the "QA Process and Stages" section within
Be Prepared for Different Approaches
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
Beyond the boilerplate expectations, it should be remembered (and embraced) that each QA engineer has their own unique approach for executing a QA test that cannot be replicated by others.
Integrating QA Engineers
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.
(Not Public Accessible)
(Not Public Accessible)