Manual Testing (IT)QA Specialist (Scrum Team)

How to organize manual testing when working in a Scrum team: what is important to consider and how to integrate into the iterative process?

Pass interviews with Hintsage AI assistant

Answer.

Over time, manual testing has adapted to agile methodologies such as Scrum. Initially, testers worked "at the end of the sprint", testing the final output of all work. This often led to last-minute rushes and insufficient testing (issue).

The main problem is the lack of time for testing, frequent changes in requirements, and tasks that do not reach testers during the sprint. Testers find themselves under pressure, which decreases quality (problem).

The solution is to integrate testers into the team from the very beginning of the sprint: participate in meetings, plan test cases as new tasks arise, hold daily stand-ups and retrospectives together, and promote transparency in the status of test artifacts (solution).

Key features:

  • Continuous involvement of QA at all stages of the sprint
  • Regular updates and planning of test cases ‘on-the-fly’
  • Collaboration with developers on defining the readiness of tasks for testing

Trick Questions.

Can testing start only after all sprint tasks are completed?

No, the tester should be involved from the first days of the sprint and test unfinished functionality whenever possible.

Should all bugs be fixed in the current sprint?

Not necessarily, critical bugs should be fixed — non-critical can be moved to the external backlog and fixed in the next sprint.

Is manual testing required when automation is available in Scrum?

Yes, manual testing is critically important for verifying new features and non-formalized requirements, as well as for exploratory testing.

Common mistakes and anti-patterns

  • Late involvement of testing
  • Lack of documentation for new features at the start stage
  • Ignoring team communication and meetings

Real-life example

Negative case

The tester did not participate in planning and did not have access to new task stories until the end of the sprint. As a result, tests were written in a hurry, and some bugs were postponed to subsequent sprints.

Pros:

  • Fewer meetings for the tester

Cons:

  • Errors in production, customer dissatisfaction, low coverage

Positive case

The tester joined the team from the first days of the sprint, participated in meetings, saw emerging tasks in advance, and planned tests in parallel with development.

Pros:

  • Early error detection, transparency, fewer critical bugs at the release stage

Cons:

  • Requires time investment in meetings and communication