Avoiding Common Pitfalls for New Agile Testers

Janet Gregory, an agile testing coach and process consultant, discusses the dangerous behaviors and traps that new agile testers fall into and explains what agile testers should actually do.

1. Waiting for the next version

In agile development testing must be continuous; waiting until the final stage to test is ineffective. Testers should regularly obtain builds from the version owner, plan a basic test framework, and test as soon as possible, preferably on developers' machines to provide rapid feedback.

2. Not truly joining the team

If testers are not invited to planning meetings, are reluctant to speak, or do not understand business requirements written by customers, problems arise. Agile testers must emphasize the importance of a "complete team," sit with developers, attend all relevant meetings, and encourage the team to try new ideas within a few iteration cycles.

3. Clinging to a "quality control" mindset

Quality is a shared responsibility of the whole team, not just the testers. Without a collective commitment, developers may treat testers merely as a safety net, communicating only through bug‑tracking systems, which prevents true team cohesion. Testers need to be proactive, build good relationships with developers, and demonstrate their professional value so the entire team owns product quality.

4. Insisting on manual testing only

Relying solely on manual tests cannot keep up with development speed. Lack of automation leads to more bugs, delayed responses to new requirements, and missed regressions. Testers risk falling into routine and missing learning opportunities.

5. Ignoring the big picture

Developers must maintain a holistic view and not be distracted by isolated concerns. Without a global perspective, business requirements cannot be linked, units cannot be integrated, and workflow becomes fragmented, causing decisions made during coding to misalign with overall goals. Gregory recommends conducting acceptance testing early, using business‑facing tests, considering system impact, employing realistic test data, and thoroughly researching requirements before coding.