Paul and I have been running into each other at conferences now for the better part of a decade. In addition to both being testing nerds, we are both metal nerds, too. Some of our best conversations have been half tech and half, "So, what do you think of the new Fates Warning album?" or whatever ;).
For today, Paul is talking about the fact that test automation code is legit and literal code. It's software development and deserves the same level of attention and scrutiny as production code. Thus, it makes sense to do code inspection on test automation code. When we are on a testing team or we have multiple testers to work with, we can have test team members work with us to inspect the code. Often, I have not had that luxury as I've either been the only tester on a project or I've been the only tester at a company. Thus, who inspects our code? Too often, nobody does, we are left to our own devices and we hope for the best. We shouldn't and Paul agrees with this.
The benefit of having code inspection is that we can have someone else help us see past our blind spots. Think of it the way that we read our writing. The danger is not that we can't proofread effectively. We certainly can. The real danger is our brain bridges over our mistakes and interprets what we mean so that we can literally skip over blatant mistakes. Later, when we see them, we think "how could I have missed that?" Well, it's easy, because you read it and your brain was a little too helpful. By the way, there is a cool technique if you ever find yourself having to do it yourself... read it out loud as if you were delivering a speech. Mannerism, speech patterns, inflections, etc. Why? It takes you enough out of the space that when you try to speak out a misspelled word or clunky grammar, you hear it out loud and your slower thinking brain will detect, "Hang on, here's an issue".
There are a number of tools that can be used to allow you to do both static analysis and dynamic analysis but what I find really helpful is to just hand over my tools to another developer or tester and say, "Hey, can you run through this for me"? The benefit here is that they can look at what I am running and what I am doing and they can see if my rationale makes sense.
I have had numerous occasions where a developer has run my tool and come back and said, "Hey, I walked through this and while I get what you are doing, you're going the long way around". Then often they have either helped me do it more efficiently or they realize, "Oh, hey, I could probably help you with that" and then that code inspection actually encourages a testability tweak in our code that I can then take advantage.
We have a tools repository that our development manager and one of our principal engineers handle merge requests for and I am encouraged to make sure that the code that I write for automation is in sync with our master branch, as much as possible. Thus I make frequent pull requests and those two have a direct opportunity to inspect what I am doing with the code. Encourage these interactions and if your code isn't in a proper repo, fix that.
As Paul said at the end of the talk and many times during the talk, automation is code, treat it like it is. I concur :)!!!
No comments:
Post a Comment