To Develop, Or Not Develop

Over my career, I’ve had a number of folks, at different companies, ask why I am not a developer. I thought I would take the time to explain a few reasons why testing, and being a tester, is something I’m passionate about.

If your first thought about this is “she can’t write code, therefore…” well, you’re mostly wrong there. I can write code. Basic stuff, really. I can find my way around HTML5 and CSS3 just fine. I can also write scripts in Ruby, and I’ve learned a thing or two about JavaScript and Java.

I’m not proficient enough to be considered a developer, I will give you that. I don’t find it particularly interesting to sit down and write out lines and lines of code, in whatever flavor you pick, to solve for a set of criteria chosen by someone for a developer to produce.

What I do find interesting are the unexpected results which computers seem to endlessly provide from combinations of things. Whether it’s new code introduced to existing code, or compatibility between the app and whatever combination of devices, OS’s, and other applications, working with the known-unknowns is a little more interesting to me than creating a module that loops through data from an API and displays it in a specified sort order.

I will make one exception. I dig SQL. Or rather, I dig database things. All flavors of that pretty much give me a kind of scary thrill. “Scary” because there’s a ton of data there, and I always wonder what companies are doing with that data and the implications of what all that data means. The “thrill” part comes from playing with those same data sets to get information about systems and users which can inform my testing. Data can inform me about browsers that are used most frequently. I can work on narrowing down defects based on error messages recorded. I can see common data patterns which can be translated into workflows, which I can make informed decisions about risks to the application. Data can be a very powerful tool for a tester. If you aren’t pairing up with a DBA or playing with databases and understanding how the data structure for your application works, you are missing a vital part of the information you need to have as a tester.

A lot of you could be thinking at this point, she’s protesting too much. You might be right. I might be a developer and I need to get over it. This could be my “I Am Not Spock”* moment. I’ve been doing testing for a while now and when I’m approached with the idea or the feedback that I should become a full-fledged developer, I usually reply with something quippish, or thanks but no. I’ve actively rebelled at the idea that I’m a developer of any kind. I like testing. I’m passionate about the community and what we do in the software development life cycle and what that means for the things we test. I like the distinction between what I see as a vital part of the software development life cycle and the act of developing software.

What I’m slowly realizing is, as things evolve for testing and software development, it’s possible that I am or will be considered a developer, or a full- fledged engineer of code. Whether that’s testing it or writing it, who knows. I think many testers struggle with this duality. I know I do all the time, but pick an identity that works for me.

Many people move into development because that’s where they were heading in the first place. I’ve always had an eye towards how to make things better, and solve an issue satisfactorily. This works for development, but you also need a creative component with that. I think I have both, but my problem solving skill set is pushed a lot more when I have to deal with more than the code in front of me. When I have to actively think around the code itself, that’s when the fun begins for me. I often think about other applications the app might be interacting with, and how the customer will use it. I think how different customers will use the same app. I look at the application from the front all the way to the back and then to the front again. I follow the data. I follow the calls. I see what happens, but with an idea of what to expect. That’s testing.

As testing evolves, I find myself pairing with developers and learning more about application code. Developers are testing their code more. I’ve finally reached a point and time in my career where I have to start asking better questions than: “Did you test it before you committed it?” I can ask things about scenarios and ideas that they might not have thought of initially, or need to think about for the next iteration. We can come up with tests together. Either one of us could code the automation which will test the code later. The line is blurring. I might eventually have to succumb to the idea that “I Am Spock”** or rather “I am a developer” whether I want to be or not.

I, by my very nature and upbringing, am a problem solver, a fixer. I am extremely good at seeing a problem, identifying it, and then actively looking or testing solutions for that problem.

I feel at times, writing code limits me to one answer: the code. I have met too many people that think they can code their way out of a problem rather than look at all of the options first.

I appreciate that people can literally “code their way out of a wet paper bag,” but I want to solve the problem of why the bag got so wet to begin with. I want to know why it was there, who originally had the bag, and if the materials it was made out of contributed to the problem. This is how I think.

A problem is a point in time. A perspective. A reality in a given moment waiting for a solution. What happens a lot, with companies, with a lot of architects and developers, is the jump to a solution using the latest and greatest flavor of a tool or a language. They tend to assume it will solve the problem, or innovate on it, in a way that will be forward thinking. They aren’t completely wrong, but they aren’t completely right either.

Using the new tool or the latest version of JavaScript could actually solve the problem. It could bring that needed solution to the table. I don’t doubt that, sometimes, code and tools can solve a lot of problems. Usually though, it only solves the problem of “right now.”

That “right now” problem, once fixed, is no longer addressed. The problem, which could be a symptom of a much greater issue, goes away until something else brings it back to the surface. If that happens often enough, and people continue to use these little patches of code or tools to keep things floating along. Then the day comes that someone suddenly realizes you are all working in a leaky, patched boat. The fixes add up to a bigger problem, creating a whole new problem you can’t patch any longer called massive technical debt.

Software systems tend to only survive six to ten years. Sometimes it’s less than three years if there is a new, hot app which disrupts an industry and takes it away from your general business model. To continue to survive, the answer to problems can’t only involve a code fix.

Another analogy you could use instead of the leaky boat example could be the spinning plate metaphor. Keeping so many plates going without issue is pretty impossible without a lot of planning, patience, and timing.

What people see are the spinning plates. One of them falls, people react. What a lot of people don’t know is that as many elements as possible are addressed before the whole act starts. The performer makes sure the plates are all the same type, the same weight, balanced, maybe even specially made for the purpose. They pick the most perfect stands on which to balance the plates. They have the air handlers for the stage shut off during the time the act will happen. They space the stands evenly apart to not cause a collision between them and the spinning plates. I’m sure there are other things, but I think you get the general idea.

If you are a tester, you are the performer setting up the act, maybe even spinning the plates later, but for the most part, you make sure every detail from the tilt of the stage, to the surface area of the plates are addressed. These problems are solved by experimentation, observation, planning, communication, choreography, and maybe even a good dose of social engineering.

It’s not just the plate act, or the boat, or the wet paper bag; it’s the fact that testers are asked to look at an ecosystem of interactions. They range from an actual functional piece of the code, to how it interacts with databases, third party systems, external applications like browsers, mobile devices, and even people. That’s the fascination for me.

If something happens, I want to help decide if code will actually fix the problem, or determine if it is more systemic, external, or human related. It could be a little bit of everything. There are other solutions besides writing code when you ask, “Will just writing code fix the problem?” Here are some examples of other things which might happen instead of only fixing the code which aid in mitigating risks:

A tester could be doing some or all of those just for one problem. It’s what happens when you look for risks both internal and external to the problem itself.

Another example of looking at the bigger picture and using a risk assessment style of testing is being able to arrive at another solution for the problem. That solution could be anything from notifying and training the customer about the product, to correcting a programmer's perception about how the customers use the product, which then changes how they code a feature or fix it. That interaction is as much part of the solution as writing the code.

The crossroad of development and testing seems to be automated tests. It’s an interesting conundrum for a tester that doesn’t want to be a developer, but wants to use code and tools to automate things to get to more and varied kinds of testing.

I love automation. I am also a big fan of automation test code being treated like development code, as if it was going to production and a customer was going to see it in all its glory. The reality is, it’s pretty much throw-away code. Code that makes it easier to do my job. Code that helps me understand the bits and pieces faster. Code that could be tossed like yesterday’s trash and then start up brand new because it isn’t out there for customers to see.

I also like using tools that make automation bits easier to do. If GhostLab can help me manage and automate a mobile test, I’ll use it. If Selenium IDE lets me record a script and play it back so I see exactly what interactions are happening and I can use it to create my own automated checks, I’ll use it to do just that. If SauceLabs lets me check images and compatibility faster, I’m absolutely going to use that tool to get quick snaps of the application I can scan with my eyeballs and spot issues.

Learn what tools and automation frameworks are out there. I’ve learned that if I place the value of my career on how much automation I’ve learned, or what language I can write code in, then I’m undervaluing myself greatly. Knowing what could work versus knowing what is available and can be used, learned, and adapted to meet the project goals, should be the point of any automation framework.

Picking the right framework or tools to do the job is important. Don’t stay with a tool or framework if you don’t have to. Don’t get rid of it on a whim either. Justify changes to your testing tech stack like you would justify the need to fix a defect. Once you make a decision, don’t sit on the change, waiting will make it worse. It can become a different leaky boat with patches, just like the production app, if you aren’t vigilant about what’s necessary to test the application.

Don’t get hung up, as a tester, on learning a specific language. My career is full of different languages, and the bits and pieces I picked up over the years. I still don’t consider myself a developer because of that. I don’t think anyone should. I also don’t let a language hold me back from learning a methodology or a process.

Learn the basics: Learn about loops. Learn about scripted versus compiled code. Learn about do/whiles. Learn about case statements. Learn about page objects. Learn about global variables. Learn about the different layers of an application and how to get to them. Learn about classes. Learn and keep learning, but don’t feel obligated to be as much of an expert as the developer sitting across from you.

Do learn the vocabulary they use. Learn what they are working with and pair with a developer on problems whenever possible. Knowing and understanding what pieces of the application are doing can help a lot with defects.

I’ve been able to narrow issues down to a line of code, or a query. I’ve also been able to fix simple HTML/CSS issues because I knew where to look. Why make a developer fix a spelling mistake when I can do it just as easily? I’ll do it myself and save the developer the five minutes to fix it and the need for me to write a defect.

I have never felt obligated to learn code, but I make it a point to understand what I’m working with and how it works from top to bottom. I’m not afraid to get into the guts of something. I’m also not afraid to ask for help when I need it.

Maybe developer folk like their jobs a lot. The weight of the world seems to be on their shoulders. The very orderly process to which they need to adhere to in order to produce working code is amazing to me. The other thing that amazes me is that they are able to use the same solutions over and over again to resolve a problem. Once you figure out that you need a loop, then you write a loop. There are particulars in there with that, but essentially, it’s a loop. A loop is pretty much a loop no matter how complex it is or what syntax you are using.

From my perspective, writing a loop 500 times for the rest of my career in various applications doesn’t seem like a lot of fun. I know I’m oversimplifying it some here, but that’s my observation.

Testing, for me, is a constant changing kaleidoscope of amazing things that happen which I get to figure out and then learn from those issues and pass that knowledge along to other folks. How could writing similar code over and over again be interesting; I have no idea. It probably says a lot about my patience and personality. I might change later. I might learn how to meditate for more than five minutes at a go. Things can change, and I love change.

I tend to not look at applications, or parts of applications, in isolation. I look at applications as part of an ecosystem of the company. Problems with the application can almost always be related back to a decision made by a human at some point in time during the development process.

If you are a developer, you generally only look at the piece you are working on like the windows, the entryways, the frame, the materials, or the flooring. It all comes together to build a house.

Testers look at all those same things, and then figure out what block the house is on, what roads and routes people will use to get to the house, how many people can fit in the house, how close it is to it’s neighbor’s house, whether or not they can mimic a design they saw down the street and let the interior designer know about it.

Testers, the good ones, make it their life goal to build up the neighborhood they are working in by making sure their house is the best they can possibly make it, along with the developers, business analysts, scrum masters, and designers. We offer opinions, we aid decisions, we guide actions based on known risks. We do testing too.

Boring is pretty hard to come by as a tester. If you are bored with testing, you might wanna be a developer instead, not because I think developers can’t test things, the exact opposite is the truth in most cases. It’s because no one should have the burden of working on something they think is boring.

Melissa Eaden has a decade of working with companies in the tech industry. She began her tech career as an internal customer service agent in Topeka, Kansas, then relocated to Austin, Texas where she later transitioned into a tester role. Melissa’s previous career in mass media continues to lend itself to her current career endeavors. She enjoys working for ThoughtWorks, in Dallas, Texas. In addition to that, she’s a Content Editor and Staff Writer for Ministry of Testing, supporting their community mission for software testers globally.