Rants of a Madman – I don’t care if it’s automation, it’s still code!
What is it about working on quality assurance automation that causes some highly competent seasoned professionals to act like they’ve had a frontal lobotomy? Let me go through a random list of rants I’ve heard over the years from many a quality assurance engineer about the development team(s) they are working with:
- Where are the acceptance criteria on these stories?
- The Agile Manifesto doesn’t say “no documentation” it says “no comprehensive documentation”; all product owners and developers do today is to try to get out of writing anything down.
- Where is your version control?
- Where are your continuous builds?
- Do you even bother to paint labels on your code before a build?
- Would adding one line of comments to your “self-documenting” Java gibberish kill you?
- If you have a defect in your code why is it you cannot enter an incident in our defect tracking system vs. using your memory or post-it notes?
This is just a sampling. I’m sure if you are in QA you have a much longer and comprehensive list. So riddle me this then: Why is it when some of these same quality assurance professionals, who often think developers are a bunch of cowboys, lose their own marbles when they start working on their own automation efforts? I mean really–isn’t code just code regardless of the technology used? Here are some questions I’ve asked in the past of folks working on QA automation in which I’ve received either blank stares or the standard excuses dev tries to offer (yes, it’s the “our effort is too small for that” or “it would take more time than it would save”, blah, blah, blah):
- Is your automation code managed in to our standard version control system? When’s the last time you checked your automation scripts/code in?
- Is your automation code part of the same continuous build process as the dev code it’ll run up against?
- Does your automation code get painted with the same labels used for building development code? It would be nice to have test harnesses that are compatible with the builds they run up against, no?
- Do you have an install or deployment batch script or does Bob hand copy everything in to the right directories on the right machines?
- What is your burn down on automation work?
- Can you show me your outstanding defects and your own fix/found/closed rates?
- Where is your documentation?
- Do your automation scripts/code have any comments?
- What are your reusable components that can be leveraged across efforts vs. copy/pasting code over and over again?
- You spent how much time and money writing and debugging code vs. purchasing that $350 commercial off the shelf library which does far more than your code and is already QA-ed?
Oh, don’t get me wrong. The same thing happens to some developers when they start playing the QA automation roll. Remember the senior developer who kept preaching about the need to refactor x% of your code in each release? This is usually the same one who pines over the fact that everybody should strive to make all of their components reusable for that “someday” it may be leveraged again by another module. Is this the same developer who, when it is time to expand a test script to a new area, simply copies and pastes the code in a 10 page block, makes a couple of changes, does a “Save As…”, repeats that operation a few dozen times, and then calls it a day? If reusable objects and components are something every developer should strive for when designing and implementing their code, then what happened the second you touched a QA script? Did that best practice evaporate in the wind?
I like how Agile and its adoption is greatly influencing QA automation. Fading away are the days of the Dev and QA professional in terms of titled departments with silo-ed job descriptions. What is replacing these “unionized” titles and job descriptions are rolls that get played by the right talented individuals at the right time throughout the Agile process. As such our professionals are playing both engineering and quality assurance rolls even within the same iterations depending on the stories they pick up. This is leading to an increased awareness that software development is software development, code is indeed code, and best practice is best practice whether the deliverable or environment is production code or the automation harnesses that helps to validate it.
But that is a journey and not an event. We are not quite there yet. So, in the meantime, what best practices are you skipping because “the effort isn’t big enough” or “there isn’t enough time” or <fill in excuse here>? Now ask yourself: Is that in any way hypocritical given that you’ve beaten the tar out of developers for the same thing?
As a QA professional your job is to be smarter than your development counterparts. You have to think about all the places where development will make a mistake. You have to, based on the problem, know where to look for high risk defects that your developer wouldn’t think to explore. You need to share this with dev, in the form of acceptance criteria, before dev pumps code. You also have to lead by example when you do your own coding.
If you are going to ask developers to do something in the code they develop, perhaps you should do the same for your automation code. Just sayin’…