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

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.

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

  • C# Advent Calendar 2019 – Refactoring RestSharp Sample Tests to Make Them More Maintainable
  • Being Prescribed Something I’m Allergic To aka Software Doesn’t Work
  • Choosing the Winner for the Pro Ministry of Testing Dojo Membership!
  • Ministry of Testing Dojo Membership – #PayItForward
  • Looking back on 2018, looking forward to 2019

Categories

  • Career and Leadership
  • Coding Stuff
  • Conferences and UG Meetings
  • Gluten Free
  • HTTP Status Coops
  • Personal Stuff
  • Professional Stuff
  • REST API Testing
  • Testing
  • Uncategorized

Upcoming Events

There are no upcoming events at this time.

© 2018 g33klady.com / Hilary Weaver-Robb. All rights reserved.