Skip to content
g33klady
  • Home
  • Blog
  • Talks
  • HTTP Status Coops
g33klady

Coding the right thing: not just for developers

May 31, 2015 by Hilary

This tweet came across my feed recently and I emphatically agreed:

coding_thinktweet

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”:

codingrightthing_tweet

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.

resized_philosoraptor-meme-generator-if-testers-test-to-assure-quality-then-who-assures-the-quality-of-the-tester-15551b

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.

Hilary
Hilary

I’m Hilary Weaver-Robb, also known as g33klady on the Internets. I’m a Senior Quality Engineer working remotely near Detroit, I tweet a lot (@g33klady), and swear a lot, too.

Post navigation

Previous Post:

Should All Testers Be Automators? The Argument I’m Tired Of, But I Argue Anyway

Next Post:

CodeMash 2016

One comment

  1. Maciej Konkolowicz (@mkonkolowicz) says:
    May 31, 2015 at 10:25 am

    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!

    Reply

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

Recent Posts

  • 2022 Year In Review and 2023 Goals
  • Diversifying Heuristics with Social Media part 2
  • Diversifying Heuristics with Social Media
  • A Birthday Surprise That Didn’t Go To Plan (but was Still Incredible!)
  • 2020 and 2021 Years in Review, and Looking Forward to 2022

Categories

  • Career and Leadership
  • Coding Stuff
  • Conferences and UG Meetings
  • Gluten Free
  • HTTP Status Coops
  • Personal Stuff
  • Professional Stuff
  • REST API Testing
  • Testing
  • Uncategorized
© 2018 g33klady.com / Hilary Weaver-Robb. All rights reserved.