Early Morning Pub Chats - Live from Agile#TD

Day three. Lots of conferring, lots of fun, way too little sleep (LOL!).

It’s always a challenge going to these events because my body fights the local time. It’s frustrating to realize that it’s two AM local while your body still thinks it’s 5 pm at home, and regardless of what your body thinks time is, 6 a.m. local time will arrive and it doesn’t matter what your time back home is, you have to get up and go.

This is the third Lean Coffee of the conference, and will sadly be the last. I enjoy thee gatherings because we have a totally impromptu discussion on topics I might not have considered asking about, but I learn new things each time.

Target Coverage and How to Get There:

What do we do when we have a long term team that seems to work everything out of their heads? The challenge is when we are trying to get a baseline understanding of the coverage that is being applied. How much testing is actually being done? Do we know? can we figure that out? How do we implement an approach that lets us see what is being covered? There are a variety of Code Coverage tools out there, but that helps if the people doing the primary testing and the code optimization are the same people.

However, in the case of the person presenting their dilemma, those are not the same teams. They are automating acceptance tests as they are creating them, but their legacy system doesn’t have much in this regard. the trick is that coverage is often hard to quantify. If the idea is statement coverage, that’s easier to get a handle on since unit tests can give you statement coverage, but test coverage is a bit more nebulous, since there are so many potential permutations. Using an API testing approach can help to fill in the blanks here. Buy setting up tests that utilize the service layer, many of the business rules can be automated or exercised through the API rather than trying to use the UI for this. visualizing coverage (drawing diagrams of the workflows) can help to make the visibility of areas to test more clear.

Coaching Developers to Test Earlier:

With the idea that Agile encourages testing being an activity rather than a role, many developers are getting into the role of doing testing as well as writing code.

Kim mentioned that there has been a challenge in her organization with trying to help the developers get into the habit of testing. From my own experience, there needs to be buy in from the programmers to ensure that testing is happening with the programmers. There's a benefit to asking the programmers to share their unit tests with you, the tester. By asking about the unit tests, and saying that we need to see what is happening so we understand better what is being covered, it sends a clear message.

Also, in our organization, no story is considered done if there are no unit tests or integration tests written by the programmers, so that helps make sure that unit and integration testing are done. For many programmers, they consider that "enough", but there's a lot more we can encourage them to do to test as well as having us do explorations and cover other areas. It's really helpful to communicate that we are trying to not be a bottleneck, so having the group work together to cover testing needs and to spread out the testing effort among the whole team helps encourage that philosophy. Some programmers will be resistant, but if the cultural expectation is that everyone tests, then we can get everyone else involved easier.

Distributed  Testing and Team Integrity:

A challenge with teams that are distributed is that many people fall through the cracks and the sense of team unity disintegrates. When testing gets spread among a number of groups, and people are assigned to different groups for differing periods, there's a struggle to get everyone to share what they are doing, specifically domain knowledge. The idea of sharing ideas and developing a "community of practice" can help here.

Having a rotating book club, or getting the testers together to say "what are you all working on, and would you be willing to give a quick summary of something you are learning?" Lean Coffee is actually a great mechanism for this. It can be a challenge to have teams that report to different managers, so it may be helpful to get the managers on board with the community of practice concept. The key is that there needs to be  real knowledge exchange, not just another status meeting to have to sit through.

What's New in Agile Testing?:

The area of DevOps and Continuous Delivery is an interesting avenue that is becoming more prominent. Containerization is a hot topic, and the tools discussion are able to become a runaway train very quickly. there's always something new and shiny to get involved with, but the principles of testing in an Agile context are still pretty consistent. The real newness is the experiences that people are bringing to it. Agile itself is not exactly "new". It's fifteen years old now, which in technical terms is fairly ancient. For each organization, though Agile may be brand new to them, and there's lots of opportunities to go in and have a broad range of experiences. Tools come and go, and what's the new hotness one year may be old hat the next, but each organization gets the ability to try those things as they mature and determine what matters to them.

Sad to realize I won't be doing this tomorrow morning, but fun to realize I have lots to ponder and consider when I get back together with my team. Thanks for following along, day three proper is about to get underway.