Sign in
PapaHR · Mike Pritula Academy · Roles

QA Engineer (Software Tester): Job Profile, KPIs and Interview Questions

Quality assurance (QA) helps teams catch defects before they harm customers. This page brings together a tester’s job profile, key performance indicators (KPIs), hiring questions and a plan for the first three months.

Build the profile for your company Open in PapaHR for free →

Job profiles, hiring, onboarding and reviews are in PapaHR. Free for up to 25 employees.

  1. Take the profile below or build your own with the builder.
  2. In PapaHR the profile turns into a job ad, an onboarding plan and probation goals.
  3. After 90 days, review the person against the same KPIs and competencies.

Job profile

Why the role exists

Identify product risks and defects before release, reducing customer losses and the cost of fixes.

Result in a year

Critical customer journeys have current tests, defect reports are reproducible, and every release has clear test results and remaining risks.

Place in the structure

  1. Reports toEngineering Manager, or QA Lead where the team has one.
  2. Direct reportsNone.
  3. Works withDevelopers: investigate defects and verify fixes., Product Manager: clarify expected behaviour and customer impact., Project Manager: agree testing deadlines and release readiness., Customer Support: understand reported defects and conditions., Designer: check interface states and error messages.
Key result areas
  1. Critical customer journeys have test coverage — Critical scenario coverage plan achievement100% of agreed critical scenarios have current tests.
  2. Release testing finishes by the agreed deadline — Release testing plan achievement100% of planned tests completed on time.
  3. Defects can be reproduced from their reports — Reproducible defect reports100% of reviewed defect reports allow reproduction.
  4. Fixes are confirmed through retesting — Fixes verified on time100% of available fixes verified within the agreed time.
  5. The team understands release risks — Release readiness reporting plan achievement100% of releases have complete summaries before release decisions.
  6. Releases keep critical features working — Releases without critical defects100% of observed releases have no critical defects.
Requirements

Experience: Manual web testing experience, from requirements review through fix verification.

Formal: No specific degree required; provide clear test and defect report samples.

Should know

  • Development stages and testing’s role in preparing a release.
  • Boundary values and grouping inputs into equivalence classes.
  • Retesting fixes and regression testing of existing features.
  • Application programming interfaces (APIs) and how to test responses.
  • Structured Query Language (SQL) for reading database records.
  • The difference between defect severity and fix priority.

Should be able to

  • Turn requirements into testable scenarios.
  • Find ambiguities before testing starts.
  • Record defect conditions and gather evidence.
  • Read browser messages and application interface responses.
  • Choose tests based on risk and available time.
  • Explain defect impact in business terms.
Competencies at three levels

Requirements and scenario analysis

Finds gaps in product behaviour before they become costly fixes.

  1. Tests the main path from documentation and asks about unclear conditions.basic
  2. Identifies boundaries, invalid data, states and dependencies between features.solid
  3. Finds conflicting requirements and helps the team agree on testable outcomes.strong

Risk-based test prioritisation

Focuses limited time on failures threatening payments, data and customer work.

  1. Starts with agreed critical scenarios and flags insufficient time.basic
  2. Reorders tests based on defect impact and affected features.solid
  3. Proposes release test scope and explains the remaining risk.strong

Defect investigation and reporting

Reduces developers’ time spent seeking clarification and rediscovering problems.

  1. Records steps, data, product version and the observed failure.basic
  2. Narrows reproduction conditions and attaches useful system messages.solid
  3. Finds patterns in intermittent failures and separates product defects from environment issues.strong

Consistent testing

Makes release readiness visible and important tests repeatable.

  1. Records each test result and distinguishes untested scenarios from passes.basic
  2. Updates tests after changes and checks fixes for effects on related features.solid
  3. Removes obsolete tests, closes coverage gaps and makes results clear.strong

Quality communication

Supports release decisions with facts and customer impact.

  1. Describes problems calmly and separates observations from assumptions.basic
  2. Explains defect importance through customer impact and discusses possible actions.solid
  3. Resolves release readiness disagreements by recording decisions, owners and accepted risks.strong

Testing process improvement

Prevents recurring defects and reduces unhelpful manual work.

  1. Reviews an escaped defect and adds a relevant test.basic
  2. Spots recurring reasons for missed defects and proposes process changes.solid
  3. Measures improvements through time and missed defects, then shares successful approaches.strong
Builder

Build the profile for your company

Tick what this person does at your company. On the right is the ready profile: copy it or open it in PapaHR.

QA Engineer (Software Tester)

Identify product risks and defects before release, reducing customer losses and the cost of fixes.

Duties
  1. Clarify expected feature behaviour before development starts.
  2. Identify scenarios where failures interrupt customer work or payments.
  3. Create test checklists for new features and related changes.
  4. Prepare test data and check the test environment.
  5. Test the interface and data exchange through application interfaces.
  6. Check boundary values, invalid inputs and access permissions.
  7. Report defects with steps, conditions, expected and actual results.
  8. Retest fixes and check related features after changes.
  9. Share test results and risks before release.
  10. Add tests based on defects reported by customers.
  11. Automate stable, repetitive tests where suitable skills are available.
  12. Test performance under an agreed load.
  13. Check usability with keyboards and screen readers.
  14. Test on additional devices and browser versions.
  15. Reconcile data after migration between system versions.
  16. Check interface translations, date formats and monetary amounts.
  17. Help support reproduce intermittent defects using anonymised data.
Open the profile in PapaHR

QA Engineer KPIs

  1. Critical scenario coverage plan achievement — Critical scenarios with current tests / planned scenarios × 100%. Mistake: Treating a test checklist as proof that the tests were run.weight 20% · month
  2. Release testing plan achievement — Tests completed on time / planned tests × 100%. Mistake: Counting blocked tests as successful.weight 20% · month
  3. Reproducible defect reports — Reproducible defect reports / reviewed reports × 100%. Mistake: Excluding complex defects to improve the score.weight 15% · month
  4. Fixes verified on time — Fixes verified on time / fixes due for verification × 100%. Mistake: Counting fixes as verified without retesting.weight 15% · month
  5. Release readiness reporting plan achievement — Complete summaries before release decisions / planned summaries × 100%. Mistake: Counting reports that omit untested scenarios and unresolved risks as complete.weight 10% · month
  6. Releases without critical defects — Releases without critical defects / releases within agreed observation window × 100%. Mistake: Blaming only the tester or hiding defects to protect the score.weight 20% · quarter
Calculator

Work out the KPI bonus

Enter how much of each target was met, in percent, and the bonus at 100%. You can change the weights.

KPIWeight, %Achieved, %Share
Critical scenario coverage plan achievement
Release testing plan achievement
Reproducible defect reports
Fixes verified on time
Release readiness reporting plan achievement
Releases without critical defects
KPI total
Bonus
Sum of weights

The weights are an example. They should add up to 100%.

Interview questions

Scorecard

Run the interview and get the result

Score each answer from 1 to 5 and the total is worked out by competency. Keep this page open on your phone during the interview.

Requirements and scenario analysis

Describe an ambiguous requirement: what did you clarify, which tests did you choose, and what changed?

✓ Listen for: Specific ambiguity, personal questions, agreed behaviour and test outcome.

⚑ Red flag: Tested assumptions without agreeing expected behaviour.

Describe a boundary-value defect: how did you choose data, find the issue and verify the fix?

✓ Listen for: Reasoned choice of values, observed discrepancy and retesting.

⚑ Red flag: Names techniques but cannot describe personal actions.

Risk-based test prioritisation

Describe a release with insufficient testing time: what came first, and how did you communicate the remaining risk?

✓ Listen for: Priorities based on customer harm, explicit gaps and an agreed decision.

⚑ Red flag: Chose only quick tests and did not report the rest.

When did new information change your test plan? What did you revise, and what happened?

✓ Listen for: New evidence, associated risk, revised tests and an observed result.

⚑ Red flag: Kept the original plan despite a threat to a critical feature.

Defect investigation and reporting

Describe a defect a developer could not reproduce: what did you investigate, add to the report and achieve?

✓ Listen for: Environment, data and version checks, clearer steps and confirmed reproduction.

⚑ Red flag: Insisted the defect existed without adding conditions or evidence.

Describe an intermittent failure: how did you gather facts, narrow conditions and hand over your findings?

✓ Listen for: Successive hypotheses, tested conditions and useful evidence.

⚑ Red flag: Presented a suspected cause as an established fact.

Consistent testing

Describe a fix that affected another feature: which tests did you add, and how did you confirm the result?

✓ Listen for: Feature dependencies, additional scenarios and recorded results.

⚑ Red flag: Only checked the original defect despite knowing about related changes.

Describe an outdated test suite: how did you revise it, and what became easier for the team?

✓ Listen for: Removed waste, closed gaps and established a clear maintenance approach.

⚑ Red flag: Added tests without addressing contradictions or duplicates.

Quality communication

Describe a disagreement about defect severity: what evidence did you use, what was decided, and what happened after release?

✓ Listen for: Customer impact, both positions, a recorded decision and the outcome.

⚑ Red flag: Relied on seniority or authority rather than defect impact.

Describe a release with a known defect: how did you explain risk, identify the decision owner and monitor impact?

✓ Listen for: Clear limitation, decision owner, fix plan and monitoring.

⚑ Red flag: Hid the defect or assumed sole responsibility for the release decision.

Testing process improvement

Describe a defect that reached customers: what did you change in testing, and how did you assess the benefit?

✓ Listen for: Reason for the miss, a specific change and evidence of use.

⚑ Red flag: Blamed someone and only promised greater attention.

Describe a repetitive manual test you improved: what did you do, and how did time or reliability change?

✓ Listen for: Original problem, personal actions and a before-and-after comparison.

⚑ Red flag: Automated an unstable scenario without assessing benefits or maintenance costs.

Score at least one answer and the result shows up here. ·
Track candidates in PapaHR

Test task

Test checkout in a practice environment · 2 hours

Provide a practice environment, a test account and a short checkout specification. Exercise rules: quantity must be a positive integer; discounts apply only when the stated condition is met; clicking twice must not create a second order. The candidate lists tests, prioritises the highest risks, runs available tests and reports any defects found. They finish with a short release readiness summary listing untested scenarios. If no defect is found, test results are sufficient; there is no need to invent one. Use test data and simulated payments only. After two hours, the candidate submits completed work and records limitations.

How to assess it

  • Covers the main path, quantity boundaries and discount conditions.
  • Priorities account for duplicate orders and incorrect payment amounts.
  • Reports include steps, conditions, expected and actual results.
  • Conclusions cite observations; assumptions are identified separately.
  • Passed, failed and unexecuted tests are clearly distinguishable.
  • The summary explains release risks and testing limitations.

Ready job ad

QA Engineer (Software Tester) at [company]

Test [product], find defects and explain risks before release.

What you will do

  • Review requirements and clarify unclear scenarios with the team.
  • Test new features, fixes and related product areas.
  • Write defect reports developers can reproduce.
  • Maintain tests for core customer journeys.
  • Test APIs and data within the assigned scope.
  • Report release readiness and remaining risks.

What we need

  • Manual web testing experience: [required experience].
  • Ability to choose tests and explain their priority.
  • Clear defect reports and attention to reproduction conditions.
  • API testing and reading data using SQL.
  • Ability to discuss defects with developers without assigning blame.
  • Test automation skills are helpful if required by [team].

What we offer

  • Salary: [salary] US dollars; review arrangements: [details].
  • Work arrangement: [remote/office/hybrid]; location: [city].
  • Working hours: [schedule]; working time zone: [time zone].
  • Team: [team structure]; reporting to: [manager role].
  • Equipment and test environment access: [details].
  • Training and testing skills development: [details].

In PapaHR this text becomes a job opening with a careers page and a candidate pipeline.

90-day onboarding plan

Before day one

  1. Coordinate start with human resources (HR) and information technology (IT).HR
  2. Prepare test environment, accounts and minimum required permissions.IT
  3. Choose the first feature to test and assign a mentor.Manager
  4. Prepare product documentation, known defects and upcoming changes.Mentor

Day one

  1. Show critical customer journeys and the consequences of failure.Manager
  2. Explain the path from requirement to release.Mentor
  3. Check access and complete the main test environment scenario.New hire
  4. Agree critical defect criteria and escalation steps.Manager

First week

  1. Write tests for the first feature and record requirement questions.New hire
  2. Review test coverage and the first defect report.Mentor
  3. Retest a fix with the mentor.New hire
  4. Agree probation period goals and performance measure calculations.Manager

30 days

  1. Independently test a change in the assigned product area.New hire
  2. Summarise results, unresolved defects and untested scenarios.New hire
  3. Reproduce reported defects without verbal guidance.Mentor
  4. Discuss environment, requirements and developer collaboration difficulties.Manager

60 days

  1. Update critical scenario tests for the assigned product area.New hire
  2. Run release tests and agree on remaining risks.New hire
  3. Review a customer defect and add a test preventing recurrence.New hire
  4. Assess independence and prioritisation on real changes.Manager

90 days

  1. Complete a change’s testing cycle without mentor guidance.New hire
  2. Present goal outcomes and unresolved test environment limitations.New hire
  3. Check the benefit of one testing process improvement.Manager
  4. Discuss probation period outcomes and the next area of responsibility.Manager

Probation period goals

  1. Learn the full testing cycle for a change.By day 90, independently complete one cycle: requirements, tests, defects, fix verification and summary.
  2. Prepare tests for critical customer journeys.By day 60, document and run all agreed critical scenarios in the assigned product area.
  3. Report defects with complete reproduction conditions.By day 60, the mentor reproduces three selected defects from reports without verbal clarification.
  4. Close one recurring testing gap.By day 90, implement one agreed improvement and demonstrate its use on the next change.

Career path

Junior Software Tester

Tests limited changes with a mentor and learns defect reporting and clarification.

To move up: Independently test a feature and explain the selected scenarios and risks.

QA Engineer

Owns testing for a product area, clarifies requirements and reports change readiness.

To move up: Plan tests across related features, investigate misses and support less experienced colleagues.

Senior QA Engineer

Leads testing of complex changes, improves approaches and selects automation opportunities.

To move up: Demonstrate test coordination, mentoring and agreement on priorities across teams.

QA Lead

Allocates work, develops testers and secures resources to manage quality risks.

To move up: Extend quality responsibility across products when the business needs it.

Questions for a 1:1 meeting

  1. Which critical customer journeys need more testing?
  2. Where do requirements leave you guessing about expected behaviour?
  3. Which of your defect reports are difficult for developers to reproduce?
  4. What prevents you from getting builds with fixes in time?
  5. Which risk in the last release should we have discussed earlier?
  6. Which repetitive tests take time without clear benefit?
  7. Which testing gap can we close with the next change?
  8. What support would help you test a more complex feature independently?

Mistakes in hiring and managing

  1. Judging testers by the number of defects found.
    Better: Assess risk coverage, report quality and useful information before release.
  2. Hiring an automation specialist when nobody reviews requirements or runs basic tests.
    Better: Define the manual testing workload and specific automation tasks first.
  3. Handing over changes for testing just before the promised customer deadline.
    Better: Involve testers in requirements and reserve time for fixes.
  4. Blaming the tester personally for every defect after release.
    Better: Review causes together, considering changes and agreed testing limitations.
  5. Using a live product with real payments for a hiring assessment.
    Better: Use a practice environment, test data and a two-hour limit.
HR in money

What a bad hire costs: QA Engineer

The same calculation as in PapaHR «HR in money»: the cost of hiring plus the salary for the months the new hire worked at half capacity.

One leaver
A year

In the first months a new hire delivers about half the result, so the company pays the other half of the salary for learning. In PapaHR the calculation uses your real leavers.

Questions and answers

What is the difference between a QA engineer and a software tester?

Job adverts often use these titles for the same role, so focus on the responsibilities. Testing checks product behaviour, while quality assurance also covers requirements and development process improvements. One person may handle both in a small team.

Does a QA engineer need coding skills?

For manual testing, scenario analysis, defect investigation and clear reporting matter most. Coding is needed when the role includes creating or maintaining automated tests. Assess interface testing and data reading separately from programming.

How do you assess a tester who finds few defects?

Check which risks were covered and how clearly results were reported. Few defects can indicate either a stable product or shallow testing. Compare results with the plan, change complexity and customer reports.

Who decides whether to release the product?

The tester reports test results, unresolved defects and limitations. The designated manager decides based on customer and business risk. Agree release-blocking criteria and the decision owner in advance.

How do you set QA engineer goals in a small team?

Start with critical scenarios, fix verification deadlines and defect report quality. Agree the plan, sampling rules and post-release observation window before the period starts. Assess release quality as a team; do not calculate a measure when data is unavailable.

Hire, onboard and review in one system

PapaHR is free for up to 25 employees: job profiles, openings, onboarding, goals, 1:1 meetings and reviews.

Open the profile in PapaHR I have an account

Similar roles