A test automation study group, and a round of collecting things people feel like studying. Easy problems, complicated problems. Something for us all, something to do just between two people. I bring out one thing I'd like us to do: review a fix to test automation script that we're now sharing between my team and another. All I knew of it was that there was a test that was failing too much, and there had been a Jira issue of it. A pull request was waiting. My internal lazy kicked in.
With the study group, we reviewed the pull request and just as we were about to accept it together one of the developers beat us to it. My main goals were fulfilled: the fix would improve the state of both of our automation information radiators (less red) and I never had to go through the Jira, the pull request and the code alone by myself being uncertain of the intent of the changes. Well, to be honest, I wouldn't have done that. I have an automation specialist in my team.
There was one more thing that came out of that study circle though. Reviewing the fix it became clear that the fix was a workaround. The test automation did magic to get around a product that did not behave in the way the script needed. I suggested we'd go for the developers to get a change into the product. It was clear that my suggestion was atypical, even if not unheard of. For me, it seems like a good idea to optimize overall development so that we could trust the feedback and not run circles around with creating workarounds, when in collaboration with the developers we could have a product change that makes things more straightforward. A nice discussion emerged.
Coming out of that study group, I summed my lesson up in a tweet. Susanne Sporys put in into a picture.
Sometimes we stop ourselves from asking because we think we know the answer. And yet, we often don't. Us telling ourselves something is possible comes from past experiences. The past is supposed to be past, and future is full of options.
