GRTesters! April 24 - 12 Years of Agile: What have we learned? Matt Heusser gives a brief introduction of where the Agile Manifesto came from - and points out something really important - while everyone focuses on the Left-Right thing in the Manifesto itself, not much attention is paid to the Principles behind it. Matt's point - imagine 15 or 20 years ago, you run a software org - if you looked at those 6 principles, you'd freak - WHAT? Deliver working software every couple of weeks? That's CRAZY! And it probably was because at the time, "delivering software" meant burning disks and shipping them. Not working so well He then went into a brief history of Scrum - Then talked about what he describes as the "Accordian Effect" - where people are working in "sprints" but no one is really working on the same spring. Introduces the idea of Jon Bach's "Case Against Test Cases" - in short Lisa Crispin & Tip House - Testing XP Programming intorduced 2 really important ideas - Whole Team Testing. & Whole Team Quality - TDD This was remarkably revolutionary for many people - everyone is working together to make stuff work - its still a very hard concept to achieve. ATT - BDD & the 3 Amigos - (George Dinwiddy paper reference) An approach to making sure that people with a stake in the story are working together so everyone understands what is going on and what is going to be produced. The question is getting people to define their needs and expectations - and how they are going to be delivered and received - and how people can make this work! Which brings us to the question of "Test Philosophy" - What are we really REALLY going to test? The problem is, given the time we have, what does it make sense for us to test? The hard thing to deal with is the question of trade-offs. Of course we want as much to be tested as we possibly can. But - if we don't have everyone on the team helping, we probably won't get the kind of coverage that would be needed to "test everything." We go until someone says "OK, you're done - ship it." So, visualize the flow of the work - with colors - that is important in giving clear messages what is going on. We need to be as clear - and as simple - as we can so people can understand what we have. This brings us to Regression Testing - Does the stuff we did X days ago still work? But doing that is a challenge - Can automation tools do everything? Not really - But there are other options - Like UTest. Massive Simultaneous Exploratory testing - put it out, set up some test accounts - ping UTest on Friday - have them test over the weekend and review the results on Sunday evening. If the results look good, SHIP IT! If not - problem - hold it and fix it and fix it. There are other options - like - reduce the "work in progress." If the developer's can't put any more stories into QA - it keeps testing from being the bottleneck. So, you open the bottleneck by having developers help test to open the neck & let more stuff through - so they can return to coding. Questions - 1. How do you get develoeprs to join in with the "whole team" thing? Ans 1: Candy. Ans 2: Chocolate. More seriously, getting people to limit the number of items they can work on at one time can help with that. Matt suggests that the retrospective is an excellent time to consider the question of "How can we avoid this the next time?" 2. So, what about automate everything? In Scrum? Ans 1: don't More serious answer - sure there are ways that you can automate every possible condition. However, we need to remember that automation code is still - CODE. We need to consider why people want to move away from manual, person based testing to automated, machine based work. What is it that we expect to happen? What to do tomorrow? - take notes & publish them; - introduce 3 amigos meetings; - Introduce paired-development; ===================================================== NEXT MEETING - in May! Test Automation for the UI: This is one of those hot-topic issues - People LIKE the siren song of automation tools. Does it really work? All the time? Really?