In August, I was at the Agile 2013 conference in Nashville Tennessee along with ~1700 people. I attended talks, participated in open space sessions, Lean coffee sessions, and multiple hallway conversations and learned from all of them.
This year I didn’t give a talk but participated in the Stalwart stage which was one of my most interesting experiences at a conference. My topic was: Agile Testing – Bring your problems. I know it was broad, but I was interested to see what kinds of issues people at the conference were experiencing.
How it worked: There was a facilitator who collected questions from the audience (thank you very much to Jason Tice who filled in at the last minute). When he read a question, the ‘asker’ joined me on the nice comfy couch on the stage to give me more context about the question. We had 10 minutes to discuss that question and any issues around it – this was so that we didn’t spend the whole time on one question. I liked the session because it was about ‘real world’ problems – ones that everyday folks were facing on their teams.
By the end, I was wishing that I had someone record the questions and the discussions, but there was a saving grace. One of the participants (Sharon Robson @SMRobson) tweeted some of my responses during the session. I have included them here, which will give you a bit of an idea of how the session went and the kinds of issues that were brought up, along with a bit of explanation when I think it might be necessary. Also, I took a bit of liberty in the tweets by expanding some of the shortcuts – example: perf to performance to try to make it a bit more readable.
I do hope this provokes some conversations in your organization or leave a comment or send me an email if you have questions.
Tweet: Testers don’t need to be able to read code, but they do need to be able to understand their systems!
Tweet: To automate testing you really need to understand your system. Can you draw it?
Explanation: To be able to isolate and automate pieces of your system, using mocking or other techniques, you need to understand your system. I issue the challenge to testers, programmers, anyone on the delivery team “Can you draw your system? – even at a high level such as a context diagram:”
Tweet: key tester skill = curiosity which turns the team into a “learning” team
Tweet: guilds of agile testers in an org are very important. Discuss & build a common language beyond the team
Explanation: Lisa Crispin and I call these ‘communities of practice’ and encourage organizations to use this effective mechanism for sharing learnings and experience between project teams.
Tweet: be aware that automated test become “checking” rather than “finding” tests, but they can have high maintenance overhead
Tweet: automation by itself should not be a goal, but agile testing needs to have some automation
Tweet: continuous deployment changes testing. Has to happen earlier (preventative) rather than later (finding)
Tweet: Working software over comprehensive documentation does NOT mean NO documentation
Tweet: early engagement of the testers is about preventing defects before the code is written.
Tweet: Finding defects is after the code has been written. Manual scripted tests are not good at this stage, explore it
Tweet: early make non-functional tests as simple as possible & run them as soon as we can
Tweet: talking about sharing the info about performance testing with the entire team. Make it everyone’s focus
Tweet: load/performance testing can be more related to features than stories. The earlier the better but still at feature level
Tweet: Acceptance tests describe the intent of the story. Accept criteria can be constraints that may move at project level
Tweet: lack of knowledge of story intent leads to scope creep
Response by @Dan North: s//story/product/ and you have a working definition of scope creep
My response: Acceptance tests identify scope of a story helps keep that story “right…
Tweet: Just got on the stage with @janetgregoryca to share my blend of the auto pyramid & Brian Marick matrix. Great advice!
Tweet: talking about the relationship between the automated pyramid and tasks, stories and features. pic.twitter.com/5IvUUfoCs3
Explanation: See for Sharon’s blog post about the discussion.