“Whether your company is working in waterfall or agile, your testers will have the same basic skill-set and knowledge, the real difference is in their way of working.”

Those testers who are used to working in an organisation that delivers projects in waterfall will be used to receiving a set of requirements early in the project and building their test cases around these before receiving an operational system to test.

In agile, testers are expected to be contributing to the fleshing out of requirements and then testing these without formal requirements documentation. They should also be comfortable testing code that is constantly changing in near real time and happy to operate as part of an agile team.  That agile team continuously produces value, at a sustainable pace and is able to quickly adapt to the business’ changing requirements.

When transitioning from waterfall to an agile approach, it is vital to address the following seven testing pitfalls, which, if not addressed can derail the entire transformation:

Table of Content

• 1. Not integrating testers into dev teams
• 2. Waiting for sprintly builds
• 3. No input into requirements
• 4. Manual regression testing
• 5. Maintaining a traditional testing mindset
• 6. Not keeping up with the Joneses
• 7. Forgetting the bigger picture

1. Testers are not integrated into development teams

Traditionally, the test team sat outside of the development team and were independent. In agile they must be integrated into the teams.

Are testers not being invited to meetings between developers and business users to discuss stories, or more subtly, are they being invited only to be told they cannot contribute to the discussion?

One of the biggest risks here is that the tester doesn’t know whats going on; changes are made to the story and the tester is unsure how to test them resulting in rework and animosity. When the tester misses out on story conversations there can be a tendency to simply test the developer’s build without thinking about the requirements.