Live Blog - Extra! Extra! Automation Declared Software


(Michael) #1

We are back! Lunch was excellent (thank you Testbash event team, Y’all rock!).

Paul Grizzaffi is making a bold statement. Well maybe not that bold for those of us that do it, but it certainly needs to be said more often. Automation is Code! Regardless of how we create it, there is code driving it and structuring it. Why then do we treat it as an also-ran? I think in many ways we treat the various scripts, sequences and helper files we all use as though they are just stuff we use. We treat it as something we don’t plan or create a structure for its use.

Paul has been on The Testing Show a few times so I’m familiar with Paul’s advocacy for this topic. I think in some organizations, testers come to programming because there is a need for automation. I cannot count how many testers I have met who have literally started their programming journey specifically because they needed to automate testing. If they are lucky, maybe they have a team that is willing to help them learn about their core language and help them make their testing framework in the same language as their development and production code. Often, however, the testers are sort of left to their own devices. They cobble something together and then the test team has to maintain and manage it. They might have it in source control (or not). They might have a structure that is similar to the methods used in development (or not), they may be able to leverage the unit testing options and frameworks that the development team uses (or not). If you think I’m spelling out a recipe for disaster (or at least sub-optimal results with the way that automation is written or maintained) you are not alone.

One of the areas that automation differs from production code is that the stakeholders aren’t particularly interested in the test infrastructure itself. They care about the results of those tests. Are we green? Can we compile and deploy the build? Do we have a “clean” run? That’s what matters to most people about test automation.

Often, automation is done by a specialist on the team for a handful of specialists. This has historically been the case in organizations I’ve worked with. The biggest reason for this is expediency. It takes a lot less time for a specialist to put together the automation tests. That’s all well and good but what happens when that specialist is no longer there?

One area that can be helpful is to develop some consistency, some coding standards, and guidelines that are well known and that are well communicated. In some cases, the choice of language and underlying infrastructure will help define that for you. Some languages are more specific about this, or there is an ecosystem that already exists and that can be leveraged (which in turn helps to enforce standards).

One of the biggest differences with automation code and production code is the potential for maintenance. Some test scripts will have a shelf life. They will be useful for a time, but the longer they are in use, either they will be more difficult to maintain with code changes or the test as written is no longer valid or relevant. It may sound like blasphemy but I believe (as Paul does) that there is a season for certain test scripts. A time for them to live and a time for them to be excised from the library.

Test Automation should be documented, either inside of the code itself or as a separate architecture document(s). Personally, I like to write my test automation code to be as readable as humanly possible. That means using self-explanatory variables and descriptive context in the code itself. I believe in self-documenting code but also feel that adding comments to clarify what’s happening is worth it in the long run. Essentially, I would rather read and work with 100 lines of well structured and easy to understand code than work with twenty lines of clever and tight but obscure code.

One of the things I recently did and found great value in doing was putting together a workshop on developing a framework with a variety of components and talking about the rationale of why. By presenting that workshop to my team I was able to help them understand what we had in place, what we could improve upon (hint: a lot) and where we could expand it (hint: a lot there as well). I uploaded the slides for the workshop to our shared drive space so that everyone could see it in context. That’s helped considerably in helping the members of my team understand what we have and how to work with it. Though Paul’s not mentioning it specifically, I think that it would be very helpful to create actual presentations that describe not just the whats but also the whys of what is being implemented.

Consider this whole summary my way of saying a hearty “Amen” and “Hallelujah!” to pretty much everything Paul is saying :).