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.
<aside> 🔬 To see which QA Engineer is assigned to particular website projects, look at that project’s documentation or visit the table view of ‣ (which pulls from the ‣).
<aside> 🕸️ Web visitors: Project data is private in order to protect client confidentiality, so you will see blank spaces when clicking these links. Sorry!
</aside>
</aside>
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 QA & Project’s Lifecycle, QA Engineers should have access to all projects, 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.
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 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 (Quality Assurance) Overview.)
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.
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.