Again, there's a limit to the network reliability this go around so I'm keeping the posts light on images the first go-around. I will be uploading pictures and such later to augment these posts, so consider that a heads up.
It's always fun to be able to see friends of mine at these events. Mike Lyles and I have talked about many things over the years and I'm excited to see how Mike has developed over the past few years and it's been great to see his book "The Drive Through Is Not Always Faster" get some traction as well. It's somewhat ironic that his book came out late 2019, and then when COVID hit, the philosophy had to change a little bit, as in many ways, the drive through was the only way to get anything ;).
Mike's talk is about the conversations that software testers just shouldn't still be having. Testers have a critical voice in the alignment of teams. We have to be at the table from the beginning. It's no longer sufficient to be waiting for the developers to drop code in your lap to start testing. We have a place to be starting with the design meetings. Our questions need to be asked early and often. We have the ability to help make a more testable product as well as a better quality product by actively provoking and making sure we have a clear understanding of what the product needs to have. One of the key things we need to consider is the fact that we are the ones that are meant to hold people accountable. That doesn't mean that we have to be perpetually adversarial. Fact is, most of the interactions we have are not personal or meant to be.
Mike points to the idea of Steven Covey's Fifth Habit of Highly Effective People, which is "seek first to understand, then to be understood". For that to work, we need to listen, and we need to listen attentively. More to the point, Mike encourages Empathetic Listening. This is listening with the intent to understand. Yet Mike is talking about the discussions we shouldn't be having, so what gives? The point Mike is talking about is the fact that we are having conversations in the wrong way and that we can do this better overall.
A part of this comes down to a "debating response" that is instilled in us. In part, this is not a desire to be understood or to seek understanding, it's us trying to be right regardless of the other participants' feelings or experiences. To get out of that, it helps us to be able to be empathetic in our conversations. Some examples of conversations that we can have a lot better are:
- why did QA miss this bug?
- anybody can do testing
- it works on my machine
- we don't have enough time/budget to test effectively
- we can test this in production
- we need 100% automation
Depending on your experiences, this list may seem challenging or no big deal. The difference is in how we deal with and talk about it. The point is, that these conversations aren't going anywhere but there's a good chance that these conversations can be had a lot better and a lot more effectively when we as empathetic listeners both try to understand what is needed/required without getting defensive or shutting down. By actively communicating the realities and the opportunities, we can be truthful and effective with those we work with.