Does the Agile Testing Process Work? - A #BAST Lean Beer Summary (1/5)

On Thursday, December 10, 2015, the Bay Area Software Testers Meetup Group got together and held its quarterly Lean Beer event. Lean Beer is the "evening equivalent" of Lean Coffee, where individuals come together and discuss topics of interest in a loose format. Topics are proposed, the participants vote on the topic that most interest them, and the topics are ranked based on the votes they receive.

Each topic gets a set time to be discussed and at the end of the time, a vote is made to see if the discussion should be continued. if majority votes to continue, more time is added to the clock and the discussion continues. If the votes indicate energy has been depleted for that topic, we close it off and move on to the next one.

We covered five topics at our most recent event, and based on the feedback, and as a point of reference for the members of the BAST Meetup that couldn't attend, these are summaries of what was discussed.

The top vote recipient, and therefore the first topic we discussed, was the "Agile Testing Process", or more to the point, "is there such a thing"? For several of the attendees, it seemed that the Agile Development process worked, but that testing was still treated as an after the fact activity. Isn't the point of Agile software development supposed to be that information about the product is discovered quickly, feedback received, and the ability to deliver software faster is primarily to make better quality software available?

Included in these questions is also the changes that many have witnessed at their respective companies as to not just how software development has changed, but how software testing at those companies has changed as well. For some companies, there is not a dedicated test team any longer, at least not one with a separate reporting structure. The idea of a separate test team and test manager has given way to having an integrated team of programmers and testers working together as much as possible, or to having test be an activity rather than a separate role.

Regardless of the team structure, testing is meant to happen, but how that testing is performed or who does it is open to debate. For those of us who work as testers in our given organizations, our efforts are often spread among various initiatives. Some of us focus most of our efforts on exploration, some of us are primarily working on automation. Some of us have the ability to get into the story writing process early, via the Three Amigos approach, and can apply our testing efforts early on during the requirements stage. Here, we are able to provoke requirements and provide thoughtful analysis and add value by helping see what aspects we need to consider up front before development even starts.

One of the comments that most of us agreed with is that having a dedicated (as in, involved) product owner made a considerable difference. Unit tests and Test Driven Development can be a big help towards designing a product that meets the requirements set forth by the stories. Having a system in place that allows for the software to be built and deployed in a timely manner can be a tremendous help to the process. Automation is important here, but more so to eliminating busywork and pushing things around than actually providing core testing. There is still a need for meaningful testing and applying testing skills to these stories, and part of that involvement is having the discipline to focus on just those stories that can be done in a particular sprint.