On Testing

What follows is my personal journey as a tester over the past year. Some of the success, hurt and frustration I’ve had is presented in a hopefully constructive manner. The wording on this is less conversational, yet I’m hoping with those who read it it does start a conversation in some way and also reminds testers that we have value and an obligation to those who want to learn about testing.

I always feel fortunate to be a part of companies who are producing software and I couldn’t imagine doing anything else. I am working with interesting, intelligent people and tackling problems that solve problems for other people. We are solving these problems using computers and code that create solutions that weren’t available to the majority of people twenty years ago. When I reflect on it, I’m amazed at the opportunities I am being offered.

The changes in the industry have been gigantic within the past few years, you can see them like tidal leviathans on the horizon. The learning and technical tools I have had access to are a result of those movements: Applications available from GitHub, public infrastructure from Amazon Web Services, a library of knowledge from experts and knowledge repositories easily accessible through Google searches. Last year I read twenty-two books for my career, ranging from test automation to Continuous Integration to C# and I have many more waiting to be read. The vast access to jumpstart skills sparks a fire I want to tend to and steadily grow until I can light fires for others and start them on their journey into the uncertainty of solving complex technical problems.

What does this have to do with testing software? The above prose could be for almost anyone who releases software. This is the point, the basis of what I want for testers. I want them to be equals alongside the artists and engineers, dancing around the fire with their teammates, sharing in the same danger and excitement.

People who work with testers want it too. As we shift to more frequent and adaptive releases and our projects involve more disciplines, testing raises in its importance. The activity of testing is not valuable, otherwise we would take more time for more elaborate and time-consuming tests. It is because of our skill and the value of what testers do when they apply them. For contrast, if the code developers wrote was the most valuable thing they could do, they would focus on producing more lines of code. Testing skills are discrete and valuable to a team, and it’s a full-on weeping shame that testers don’t appreciate or exercise them enough. Do you see the look of wonder on Aragorn’s face as he accepts Andúril and ultimately his responsibilities in the oncoming conflict? We should value ourselves and our role as much. Testers do not assure quality, yet we can apply tools like empirical thinking experiments, exploratory testing and general system thinking to help determine the solution’s qualities and readiness as part of a greater whole. Who doesn’t want mindful articulate thinking applied to their work as software development leans more towards business opportunities and less towards technical requirements? There is great concern and risk in releasing software on the Internet for a company. Companies want to invest money to have a more successful acceptance from those paying for it and those using it.

Aragorn holding Anduril
Aragon accepting Andúril  is a metaphor of what our acceptance
of our responsibilities 
as testers to our teams should be.

Developers who refuse to test are becoming scarcer as testing becomes a whole-team activity and the same is true for testers who refuse to code. Testing and coding are not exclusive skills and they can be learned and applied by the same person. Two applications of testing I have started to learn within the past year, unit tests and integration tests, still employ many of what I think of as the valuable thinking skills I’ve already mentioned. When we treat testing as a specialization instead of our role we can disrupt the pattern of segregation and share our testing skills to create a healthier team.

The companies, the methods, the tools, even the positions we’re hired for are always changing and until that itself changes, refusal to change and work as part of a team and adapt to the changes interferes with the quality of the software and the value it provides to its customers.

Edit: Replaced some words for general correctness.


Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: