Coding the right thing: not just for developers
This tweet came across my feed recently and I emphatically agreed:
It occurs to me, however, that we as testers sometimes don’t see ourselves falling into the category of needing such advice. There’s the oft repeated “coding the right thing rather than coding the thing right”:
We throw together a script that walks through the application, that performs a particular use case, and we run it and we have this sense of security that if it passes, we are ensuring good code is going out the door.
But are we, as testers, doing due diligence with our code, the same way we expect the developers to? Are we doing design reviews to ensure we’re actually coding the right thing? Are we getting code reviews? Are we reviewing and refactoring our own code as the application code changes? Are we pair programming? From what I’ve seen, some of us are. Many are not.
We cannot advocate that “test code is as important as application code” if we don’t treat it as such. We can teach almost anyone how to write a script to automate use cases of an application. We should be teaching them how to think more – what will this code actually do? What does it accomplish? If it passes, what does it prove? Am I actually asserting anything, or am I just having it click buttons and fill in fields with no actual check in place? It is one thing to write a script to assist you in manual testing – perhaps to get you to a certain point so that you can get to the real testing quicker. It is another to write such a script and treat it as the test itself.
If you write test automation, I challenge you to reconsider what your code actually accomplishes, what a passing check means. Reconsider the design and architecture choices made. What did you mean to do? What did you miss?
I challenge you to treat your code as if it is application code. I challenge you to treat your code as you want the developers you work with to treat theirs. And remember that test automation is not testing (at least not until the machines take over) – you need a brain to test.
I’m Hilary Weaver-Robb, also known as g33klady on the Internets. I’m an SQA Architect in Detroit, I tweet a lot (@g33klady), and swear a lot, too.
From what I’ve learned so far…it is not until one becomes a mature automation engineer, that he/she stops being caught up in the implementation details of the automation, and actually focuses on using the automation to it’s greatest potential. Too often I see (and sometimes write myself!) scripts which are testing the underlying framework of an application. Is it really interesting to know that a button can be clicked? I would argue it’s more interesting to know that series of custom actions which the button invokes get run!