Agile2013

This is the story of how I let go of being the lone tester and became the testing teacher and coach for my team. I have always thought of myself as an agile tester. However, over the past couple of years, I have transformed from a pseudo-agile tester to a true agile tester. To improve collaboration with the rest of my product delivery team, I have been gradually increasing the visibility of testing activities through exploratory test charter management, defect backlog organization, and paired exploratory testing with both testers and non-testers. The feedback loops have shortened and the abbreviated time between activities necessitated adjusting how I provide information.

Now that the audience for my testing comprises a mix of disciplines and the work environment has shifted from a heavier process to transparent, quick information access, I have been experimenting with different ways to execute testing and to represent the outcomes of that testing activity so that the information consumers understand it in ways that best suit each of their perspectives.

We will examine distinct agile team member personas and their implications for presenting and maintaining testing information as well as the inherent tensions between their distinct and various needs. I will trace my learning curve of adjusting to their needs through the various experiments I have completed in this context, though these lessons extend beyond a purely cross-functional agile product development team.

Attendees will come away with a fresh perspective on viewing their product team members and focus on the value testing artifacts provide to a software development team as well as answers to these questions

- What value can testing bring to an agile software product team?
- How can we focus on outcomes over output, both as an agile software product team and as tester contributors?
- How do you keep the work sustainable?
- How do we maintain effective communication?
- What does it mean to test in agile environments?