Agile Testing: A Practical Guide for Testers and Agile Teams

Some teams prefer to write testing tasks directly on the development task cards. It’s a simple solution, because the task is obviously not “done” until the testing is finished. You’re trying to avoid a “mini-waterfall” approach where testing is done last, and the programmer feels she is done because she “sent the story to QA.” See what approach works best for your team.

If you’re using a third-party product as part of your solution, you might assume it has been tested, but that might be a poor assumption.

Remember that when people panic, they go back to their old habits, even though those habits didn’t work.

If you’re a tester, and you’re not invited to attend planning sessions, stand-ups, or design meetings, you might be in a situation where testers are viewed as somehow apart from the development team. If you are invited to these meetings but you’re not speaking up, then you’re probably creating a perception that you aren’t really part of the team. If business experts are writing stories and defining requirements all by themselves, you aren’t participating as a tester who’s a member of an agile team.

Automated testing is one key to the solution. One thing we know for sure: No agile team will succeed doing only manual testing. We need robust automation in order to deliver business value in a time frame that makes it valuable.

Some of us worked in software organizations where we, as testers and quality assurance staff, were asked to set quality standards. We believe this is backwards, because it’s up to the customer team to decide what level of quality they want to pay for.

An agile testing mind-set is one that is results-oriented, craftsman-like, collaborative, eager to learn, and passionate about delivering business value in a timely manner

Creativity, openness to ideas, willingness to take on any task or role, focus on the customer, and a constant view of the big picture are just some components of the agile testing mind-set

An agile tester doesn’t see herself as a quality police officer, protecting her customers from inadequate code. She’s ready to gather and share information, to work with the customer or product owner in order to help them express their requirements adequately so that they can get the features they need, and to provide feedback on project progress to everyone

Skills are important, but attitude counts more. Janet likes to say, “Without the attitude, the skill is nothing.”