Do Tools Matter?

Do Tools Matter?

Life is different.

I’ve moved from the world of desktop software into the world of web software.  I was working on a team with thousands of integration tests – now I’m on a team that has very few. I was one of the experts on the team – now I’m asking all the newbie questions.  Things have changed a lot. In a new environment there are many new things to learn and it raises a question: is being a good tester about the tools you use, or not?


Being a good tester is not about the tools

I’ve noticed that I was able to very quickly get up to speed on the product and how it worked.  I was able to file several bugs in my first week.  I was able to feel comfortable talking about the different areas of the product. I was able to understand much of what the team was talking about very quickly.

How so?

I have been a tester for almost 10 years. My experience might be in a different world, but there are still many things that are common to software testing regardless of the type of application you are testing.  Software for example. And programmers.  You see, both desktop and web developers are humans. Desktop and web developers also both use this thing called code to help them accomplish things. Programmers and programming languages share things in common with each other that go beyond the boundaries of the kind of application you are building. The ways in which we create and interact with data structures and control flows are constrained by the way coding languages work.  The way that we create and maintain code are constrained by the ways that humans think and work.

I was actually surprised at how much of my skill and experience as a tester was easily transferable to an entirely new domain.  There are many things about being a good tester that go far beyond the tool set being used and the type of application being used.  There is a real sense in which being a good tester is not about the tools you use.

Being a good tester is about the tools

But that isn’t the full story. In the last couple of weeks I have not only been learning a new application, I have also been learning many new tools.  Some of them are internal tools that help make things easier for me.  Some of them are very well known tools that I didn’t need to use before.  Developer tools in Chrome for example. Or JMeter and Webdriver and Postman and the list goes on. As I get a better understanding of the application I get the urge to dig deeper and learn more and for that I turn to tools. Could I quickly get up to speed and contribute without learning new tools? Yes! Am I content with staying there?  No! I want to be a testing Batman. A skilled testers can be effective independent of the tools used, but a skilled tester will use tools to get even better.

I’m re-building my toolbelt now.  I’m like an electrician who has moved from doing residential work to commercial buildings. The underlying skill of knowing and understanding how electricity and wiring works stays the same, but there are some things that need to be done differently.  If the electrician refuses to learn and use new tools, she will be less effective than she could be, no matter how skilled of an electrician she is.

I still use the same underlying skills, but there are some new tools that I need to help me get more effective at my job. What tools do you use? Do you have any recommendations for a tester new to web apps? What tools should I add to my toolbelt?



We shall not cease from exploration
And the end of all our exploring
Will be to arrive where we started
And know the place for the first time.

I’ve been learning a new product and so I have been in exploration mode. I’ve spent the last week poking around and learning many new things about the product. Making maps of it to get a better understand. Trying things out in different ways. Setting up little experiments. Asking questions. Even on occasion reading some documentation.

The team I am a part of is responsible for one particular area of the product, and so I have kept circling back to that area. Every time I come back I find that during my wanderings in other parts of the product I have learned something new. I’ve gained insights that give some new light on the area of interest.  At first glance it seems like this part of the product is pretty simple, but the more I learn and understand how the pieces fit together, the more I see that simplicity is hard to do. It takes a lot of work to make something look and feel simple. There is a lot of hidden complexity. As I understand that complexity better, I get better at understanding the risks.  I get better at seeing where the problems might be and chasing down odd behaviors.

It can be easy to think that you know something, but it is only as you continue to return to it time after time that you really begin to understand it.  Sometimes testers can feel like they are spinning in circles, returning to the same area over and over, but every time you come back to something you are different.  You’ve learned new things and had new experiences. There are biases you have (and you would do well to learn and understand them), but it is still a new you. Use the things you’ve learned. Make the old familiar areas of the product come alive by bringing in your new perspective. Perhaps T.S. Eliot was right. It is only when we return to something that we will be able to know  it for the first time.


New Job!

New Job!

This isn’t the usual kind of post on this blog, but I want to take a couple of minutes to talk about changes in my life. I started my testing career at Ansys right out of university and it has been a good 9.5 years.  I have learned a lot a grown in many ways, but the time has finally come to try something new.  I started today at D2L. It is a totally different area and will present many new challenges for me as I work with a different technology stack and in a very different area. I’m looking forward to learning and growing in many ways and I’m sure I will continue to share thoughts and experiences as I learn new things and try to work though new learning challenges.



Liar Liar

Liar Liar

Have you ever been lied to?

I don’t mean those little white lies that smooth social interactions – “You don’t mind if I do this?”  “No, not at all” – I’m talking about a full blown lie.  You ask your son to take out the garbage and he tells you did it already.  The next morning, after the garbage truck has left, you find out he never did it.  Or you call customer service and they promise to take care of it as soon as you hang up, but you have to call back two days later because nothing has happened.  What happens when you are lied to? You lose trust in that person or organization.

Much of the way we work as a society is build on trust. There are places in the world where stores have armed men with guns by the door to deter theft.  Why? lack of trust.  In the West we have many blessings and one of them is trust. I can call a dump truck and ask them to bring by a load of sand and they will do it and send me an invoice.  Why?  They trust that I will pay them. Without that trust the transaction would become much more painful. I would somehow need to get them money ahead of time, but would I really want to if I couldn’t trust they would deliver once they had the money? Transactions become much more difficult in a society with low trust.

Trust in Software Development

In the software development industry we primarily view trust as a financial proposition. “If my customer doesn’t trust my credit processing system they won’t click on buy and I won’t make money.”  However, trust is a bigger problem than that. It is a societal problem. In a world with low trust we have high cost. Everything get expensive when there isn’t trust in place.

How do we contribute to  lack of trust in software development? Well, how about when our customer’s data gets hacked?  Does that build trust?  What about when users come to our site and it won’t load?  Does that build trust?  What about when your ‘click here’ icon doesn’t do anything? Does that build trust?

Let me drive the point home in a way that might hurt.

If you are ok with software that breaks trust, you are not working for the social good.


But I think it’s true. We hear a lot of talk about social entrepreneurship and the importance of social initiatives in corporations.  I want to challenge software development teams – and in particular those who think about testing problems – to think about the social responsibilities they hold. The ethics of testing are clear in some domains like medical applications, but what about if you are writing an iPhone app?  Do you have ethical considerations then?   My argument is that if you are ok with releasing a buggy app that breaks the implicit and explicit promises you are giving your customers you are contributing to a societal problem. Teaching people to expect to be lied to is not a good thing. Don’t have any part in it.  Release good quality software.


It’s ok to make mistakes. We will sometime break people’s trust despite our best intentions.  Don’t beat yourself up over missing things. The point of this post is that it should be despite our best intentions.  We ought be shooting for high quality, trust building applications. Saying that it’s ok to ship with bugs in our product, shouldn’t just be a financial decision.  We need to be thinking about other things like the ethics of it as well.