• Skip to primary navigation
  • Skip to main content
  • Skip to primary sidebar
  • Skip to footer

Satisfice, Inc.

Software Testing for Serious People

Rapid Software Testing A Context-Driven Methodology
  • Home
  • About
    • Privacy Policy
  • Methodology
    • Exploratory Testing
    • Reasons to Repeat Tests
  • Consulting
  • Classes
    • James Bach’s Testing Challenge
    • Testimonials
    • RST Courses Offered
    • Testers and Automation: Avoiding the Traps
    • Rapid Software Testing Explored
    • Rapid Software Testing Applied
    • Rapid Software Testing Managed
    • Rapid Software Testing Coached
    • Rapid Software Testing Focused: Risk
    • Rapid Software Testing Focused: Strategy
  • Schedule
  • Blog
  • Contact
  • Resources
    • Downloads
    • Bibliography: Exploratory Process
    • Bibliography: Risk Analysis
    • Bibliography: Coaching
    • Bibliography: Usability
    • Bibliography: My Stuff From IEEE Computer and IEEE Software Magazines
    • Bibliography: The Sociology of Harry Collins

Tools Come at a Cost

Published: January 11, 2004 by James Bach 2 Comments

One of the experiences I share with a lot of people in this modern world is that I forget phone numbers. I never used to. The problem is that my mobile phone remembers them for me. So, phone numbers no longer stick in my own head. If I want to call a colleague, I first look for my phone. If I can’t find my phone, I don’t make the call.

Another way of looking at this is that my life has been simplified in some ways by my mobile phone, and in some ways it has been made more complicated. I would argue that it was simpler for me when I was forced to memorize phone numbers. It was simpler in that my use of many useful phone numbers was completely independent of external equipment.

Any tool that helps me, also costs something. Any tool, agent, or organization that abstracts away a detail may also takes away a resource that I might sometimes need, and may atrophy if not used on a regular basis.

Test Tools Come at a Cost– Even if They are Free
This weekend, I attended the 5th Austin Workshop on Test Automation. This is a group of “test automation” people who are sharing information about test tools– specifically, open source test tools. It’s wonderful. I’m learning a lot about free stuff that might help me.

But I notice a pattern that concerns me: an apparent assumption by some of my helpful tool developer friends that a tool of theirs that handles something for me (so that I don’t have to do it myself) is obviously better than not having that tool.

So, let’s consider what is offered when someone offers me a tool that solves a problem that crops up in the course of doing a task:

  • Some capability I may not already have.
  • Possibly a new set of abstractions that help me think better about my task.
  • Possibly a higher standard of “good enough” quality in my task that I can attain because of the new capability and abstractions.

But what is also offered is this:

  • Problems in that tool.
  • New problems due to how the tool changes my task.
  • New problems due to how the tool interacts with my technological or social environment.
  • One more thing to install on all the platforms I use.
  • The necessity of paying the operating costs of the tool to the extent I choose to use it.
  • The necessity investing time to learn the tool if I choose to use it (and to keep up with that learning).
  • The necessity of investing effort in using the tool (creating tool specific artifacts, for instance) that might not pay off as well as an alternative.
  • Having invested effort, the possibility of losing that investment when the tool becomes obsolete.
  • Avoidance of the learning and mastery of details that I might get by solving the problem myself.
  • A relationship with one more thing over which I have limited influence; and a potentially weaker relationship with something else that I know today.
  • Possible dependence on the owner of the tool to keep it current.
  • Possible legal entanglements from using the tool.
  • A sense of obligation to the provider of the tool.

I find it useful to explore tools. I want to learn enough to hold in my mind a useful index of possible solutions. And of course, I use many test tools, small and large. But I’m wary of claims that a new tool will make my life simpler. I appreciate a certain simplicity in the complexity of my world.

— James

Filed Under: Automation, Process Dynamics, Testing Culture

Reader Interactions

Comments

  1. Jonas Ahnstedt says

    14 January 2004 at 5:42 pm

    I’ve got one of those PDA’s a couple of yearsago. Now adays I cant remember a thing 🙂
    Im stuck with it!

    /great article it’s so true./

    Reply
  2. Sajeev Kesavan says

    31 March 2008 at 4:41 am

    Exactly true James, Infact tooling helps a lot, I see test automation to be used so that the engineer can focus on improving the testcases and not sit with the mundane tests repeatedly. This will increase coverage however he needs to execute the cycle manually atleast once. Thats Confidence !!!

    Simplicity mostly requires complexity within . Tools arent a replacement for intelligent brains that love to be hands on with a passion towards being hands on 🙂 and for them there is no overhead of the tool. when however we think about those , who are new or gets bored with hands on , it might be yes to take the burden of the overhead of the tooling.

    Tools come and needs to come, just like the cars olden years so easy to use but today more sophiscated , even tools I believe though sophiscated ,we need to take the burden of it , keeping in mind the fast technological pace and time to market shortened.

    Reply

Leave a Reply Cancel reply

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

Primary Sidebar

Search

Categories

  • About Me (17)
  • Agile Methodology (14)
  • AI and Testing (4)
  • Automation (20)
  • Bug Investigation and Reporting (9)
  • Buggy Products (24)
  • Certification (10)
  • Context-Driven Testing (44)
  • Critique (46)
  • Ethics (22)
  • Exploratory Testing (34)
  • FAQ (5)
  • For Newbies (25)
  • Heuristics (28)
  • Important! (20)
  • Language (35)
  • Management (20)
  • Metrics (3)
  • Process Dynamics (27)
  • Quality (8)
  • Rapid Software Testing Methodology (23)
  • Risk Analysis (13)
  • RST (5)
  • Scientific Method (3)
  • Skills (30)
  • Test Coverage (8)
  • Test Documentation (8)
  • Test Oracles (5)
  • Test Reporting (11)
  • Test Strategy (26)
  • Testability (4)
  • Testing Culture (96)
  • Testing vs. Checking (18)
  • Uncategorized (12)
  • Working with Non-Testers (7)

Blog Archives

Footer

  • About James Bach
  • Satisfice Blog
  • Bibliography: Bach on IEEE
  • Contact James
  • Consulting
  • Privacy Policy
  • RST Courses
  • RST Explored
  • RST Applied
  • RST Managed
  • RST Coached
  • RST Focused: Risk
  • RST Focused: Strategy
  • RST Methodology
  • Exploratory Testing
  • Testing Training
  • Resources
  • Bibliography: Exploratory
  • Bibliography: Risk Analysis
  • Bibliography: Coaching
  • Bibliography: Usability
  • Bibliography: The Sociology of Harry Collins
  • Schedule
  • Upcoming Public Classes
  • Upcoming Online Classes
  • Public Events
  • Tester MeetUps

Copyright © 2025 · News Pro on Genesis Framework · WordPress · Log in