QA Engineer Onboarding Checklist
Everything you need to onboard a qa engineer from Day 1 through their first 90 days. Customizable for your company size and work setup.
Last updated May 21, 2026 • By Pro Sulum • Free to use, no signup
Get My Free QA Engineer Onboarding ChecklistSample QA Engineer Onboarding Checklist
Day 1: Complete administrative setup, get oriented in the office or remote environment, and understand the QA team structure.
- Complete new hire paperwork and benefits enrollment — Finish all required HR documents including tax forms, direct deposit setup, and benefits selection. critical
- Receive laptop and configure development environment — Set up the local machine with required OS, dev tools, and security software per IT standards. critical
- Get access to Jira and review the active bug backlog — Log into the bug tracking system and browse open defects to understand current product quality status. critical
- Meet the QA team and engineering leads — Attend a brief intro meeting with direct teammates and the engineering leads who will file and receive bug reports. important
- Review the employee handbook and security policies — Read through the company handbook, acceptable use policy, and any security requirements specific to the engineering team. critical
- Get assigned an onboarding buddy from the QA team — Connect with a senior QA team member who will answer day-to-day questions during the first month. important
- Set up Slack and join relevant QA and engineering channels — Configure messaging tools and join the channels used for bug triage, releases, and team communication. critical
- Review the 30-60-90 day plan with your manager — Walk through performance expectations and milestones for the first three months on the job. important
Week 1: Get test environments running, understand the CI/CD pipeline, and read through existing test documentation.
- Install and configure the primary test framework (Cypress, Selenium, or Playwright) — Set up the automated testing framework used by the team and run an existing test suite to confirm the environment works. critical
- Walk through the CI/CD pipeline with a senior engineer — Understand how code moves from commit to deployment, where tests are triggered, and how test failures block releases. critical
- Read through the full test plan for the current sprint — Review the test cases and acceptance criteria for features currently in development to understand scope and standards. important
- Get access to all QA and staging environments — Confirm login access to every test environment needed to execute manual and automated tests. critical
- Review the bug severity and priority definitions used by the team — Understand how the team classifies defects so that new bug reports are filed consistently from day one. important
- Sit in on a sprint planning and a sprint review meeting — Observe how the team scopes work and reviews completed features to understand the product and release cadence. important
- Get access to the test case management tool (TestRail or equivalent) — Log in and browse existing test suites to understand the organization, naming conventions, and coverage areas. critical
- Shadow a senior QA Engineer during a full test execution session — Watch how the team runs regression tests and files bugs to understand the practical workflow before doing it independently. important
Month 1: Execute test cases independently, file well-documented bug reports, and contribute to the current sprint cycle.
- Write and execute test cases for an assigned feature area — Take ownership of test case creation for one product area, applying the team's standards for format and coverage. critical
- File at least five bug reports following team documentation standards — Practice writing clear, reproducible defect reports with environment details, steps to reproduce, and expected versus actual results. critical
- Set up local test data scripts or database seeds used by the QA team — Configure the data setup tools used to create repeatable test conditions in the staging environment. important
- Complete any required training on the CI/CD tool (Jenkins, GitHub Actions, or equivalent) — Finish internal or vendor training to understand how to read pipeline results and trigger test runs. important
- Attend the end-of-sprint retrospective and share one observation — Participate actively in the retrospective by sharing one quality-related observation from the sprint. important
- Set up one-on-ones with each engineer whose features you will be testing — Build working relationships with the developers whose code you review so that bug triage conversations are productive. important
- Review the regression test suite and identify any gaps in coverage — Read through the full regression suite and note any untested scenarios to discuss with the QA Lead. nice-to-have
- Complete a 30-day check-in with your manager — Review progress against the 90-day plan, discuss any blockers, and clarify expectations for Month 2. critical
- Learn how to read and triage automated test failures in the CI dashboard — Understand how to distinguish a real regression from a flaky test and know when to escalate. important
90 Days: Own a testing area, contribute to test automation, and operate as a fully independent member of the QA team.
- Own end-to-end test coverage for at least one product module — Take full responsibility for the test strategy, test cases, and defect reporting for an assigned module or feature area. critical
- Contribute at least three automated test cases to the regression suite — Write, review, and merge new automated tests that cover scenarios not previously automated. critical
- Complete the 90-day formal performance review with your manager — Discuss accomplishments, areas for growth, and goals for the next quarter in a structured review session. critical
- Present a quality summary to the engineering team — Share a brief summary of defect trends, coverage gaps, or process improvements observed during the first quarter. nice-to-have
- Define personal OKRs for the next quarter with your manager — Set measurable objectives aligned to team priorities for the next 90 days. important
- Identify and propose one process improvement for the QA workflow — Based on 90 days of observation, recommend one concrete change that would improve test coverage, speed, or reliability. important
- Participate in at least one cross-functional meeting (product, design, or architecture) — Join a meeting outside the engineering team to understand how quality fits into broader product decisions. nice-to-have
- Review and update any outdated test cases discovered during the quarter — Clean up test cases that no longer reflect current product behavior to keep the test suite accurate. important
Hiring a QA Engineer for the first time can feel overwhelming for small business owners who have no HR team to guide the process. With only a handful of employees and a packed schedule, finding time to onboard someone new properly is tough. You might be worried about missing important steps or training them inefficiently because you don’t have a playbook or prior experience. This pressure often leads to rushed onboarding or unclear expectations, which doesn’t set the new QA Engineer or your business up for success. In a small business, the most crucial priority during the first week is getting the QA Engineer familiar with your product and testing environment. Unlike large companies where QA might focus on specific areas, here they need to quickly understand how your product works end-to-end and what quality means for your customers. Early exposure to your product, basic processes, and tools gives them the context they need to start identifying bugs and writing test cases. This foundation helps them contribute faster and reduces the learning curve. One effective way to onboard without micromanaging is the "Record & Delegate" method. Before the QA Engineer starts, record a short 5-minute video showing yourself performing the top three to five QA or product-related tasks. These could include how you run a basic test, log bugs, or use your issue tracker. This video becomes a simple training standard operating procedure (SOP). The new hire watches it to see exactly what you expect and then takes over those tasks themselves. This method saves you time, avoids constant interruptions, and prevents you from becoming the bottleneck in their learning. A very common mistake small business owners make when onboarding a QA Engineer is not setting clear priorities and boundaries around their role early on. Sometimes owners expect QA to fix all problems immediately or mix their duties with development or customer support without clarifying expectations. This leads to confusion, frustration, and wasted effort. A clear list of initial responsibilities and goals avoids this issue and helps the QA Engineer focus on what matters most. At 90 days, a QA Engineer ready to work independently in a small business can manage the entire testing process with minimal supervision. They should be able to write test plans, execute tests across your product, report and prioritize bugs clearly, and suggest improvements based on their findings. They will also have built a good understanding of your product’s quirks and be comfortable using your tools. This level of independence means you can trust them to keep quality high and free yourself to focus on growing your business. If you want a QA Engineer who documents their own processes and builds systems as they go, rather than requiring you to document everything first, that is what a Virtual Systems Architect does. Start with this checklist.
Frequently Asked Questions
I hired someone for this role before and it did not work out. What usually goes wrong?
Most failed QA Engineer hires come down to one of three problems: the owner skipped structured onboarding in week one, there was no documented process for the hire to follow, or expectations were never made explicit. The new hire guessed, made mistakes, and the owner assumed the person was the problem. In most cases the process was the problem. This checklist closes all three gaps. Start with a clear first week, a Record and Delegate video for each core task, and written expectations before the hire ever logs in.
What skills should I look for when hiring a QA Engineer for a small business?
Look for practical testing skills, attention to detail, good communication, and the ability to work independently. Experience with your product type or industry helps but is not always required.
How long does it usually take for a QA Engineer to become productive?
Most QA Engineers start contributing basic testing within the first week if given clear guidance. Full independence typically develops around 60 to 90 days depending on complexity.
Do I need to provide any special tools or software?
Basic tools like an issue tracker (e.g., Jira, Trello), test case management software, and access to your product environment are important. Many tools offer free tiers suitable for small teams.
Should I have the QA Engineer write test cases from day one?
Initially, focus on hands-on testing and understanding the product. Writing detailed test cases can come after the first few weeks once they know the product well.
How can I avoid micromanaging during onboarding?
Use the "Record & Delegate" method by creating short videos showing key tasks. This lets the QA Engineer learn at their own pace and reduces your interruptions.
What if I don’t have time to create training materials?
Start small with quick videos or simple checklists for the most critical tasks. You can build these materials gradually as the QA Engineer settles in.
Related Onboarding Checklists
Read Next
Go beyond the checklist
What if someone else ran this onboarding process for you?
Pro Sulum's Virtual Systems Architects document your processes and run new-hire training from Day 1 through Day 90, so you never have to.
97% stay past year one.
Schedule a Free 30-Minute Discovery Call