Testers and developers – blurring the line

I’m a tester who used to be a developer. I find my developer skills to be very useful in my job as a tester.

Knowing how to build software goes beyond just knowing how to code up a script. If a tester can understand how software fits together, then that tester will have a greater understanding of how to find points of failure. Not only that, but understanding how something went wrong can lead the tester to discover even greater risks to the system. If the tester’s understanding of the system stops at the GUIlevel, then their exploratory testing path stops there too.

Understanding how different system components interact, and being able to program these components opens up possibilities for new kinds of tests. Very focused and powerful tests can be imagined and implemented this way.

Being able to communicate with developers at the same level as them is also extremely beneficial. It not only makes it easier for both parties to understand each other, but it fosters a mutual respect. Building software isn’t easy, and knowing what’s involved gives testers a greater appreciation for the developer’s job. Developers respect testers who have taken the time to understand what they have built and how they have built it.

Working with software means that having programming skills gives the tester greater power over that software. Much of testing is about comparing system states. Being able to query a database and directly call methods from code can give the tester greater control over the state of the system.

Even just having basic programming skills can be a big plus. Generating custom test data programmatically can be a huge time saver. Being able to modify an automated record and playback script to speed up a task can also save time.

And then there is automation.

Being able to write code is not enough to be able to write good automated tests. Writing a good automated test suite is not a trivial exercise. Even seasoned developers can find it difficult if they don’t know how to approach it. Writing automated tests is a skill that needs study devoted to it on top of learning to code.

My advice to manual testers: consider devoting some time learning how to build software. If coding doesn’t appeal to you, then at least consider studying software architecture and design, which will help your understanding of how software components fit together and interact. These are skills that will be very useful to you. There is a great deal of work involved in learning these, but is worthwhile.

5 thoughts on “Testers and developers – blurring the line

  1. I agree that programming skills are useful. I think they are essential if you are on a team by yourself and need to do everything. I also agree with your conclusion.

    But still, let’s keep in mind that the kind of people who enjoy programming often lack patience with the experience of interacting with a machine through its normal interface. We don’t test with our hands when we test “manually”, we test with our brains. Yet programmers tend to apply their brains on a different level and miss bugs that are only too obvious to the undertrained eye.

    A good test team needs variety.

  2. Hi James, I agree with your observation that the kind of people who enjoy programming often lack patience with the experience of interacting with a machine through its normal interface. But I worry that an extrapolation of this can be used as a reason for manual testers to not learn programming skills. I have heard the excuse before that learning how the system works will somehow taint the tester’s view of the system and limit their thinking, so they won’t be able to find bugs as easily. The mindset you mention applies to *the kinds* of people who tend to enjoy programming – it is part of how they think. Learning programming will not automatically turn a person into that kind of thinker. I feel it’s important to make that distinction.

  3. In my personal experience. All the developers look the tester like enemy. Yeah, absolutely I accept the developing the software is not a easy job. But, when we point out the bugs means they are not ready to accept it and they thing purposefully we pin point the bugs like that. I am telling this my personal experience.

Comments are closed.