I am Tester, I am Developer

One of the biggest challenges I typically face when joining a development team is understanding the silo between programmers & testers (& other team members).

I approach this challenge by referring to both roles with the generic term of “Developer”, whilst using “Programmer” & “Tester” to differentiate between the roles when required.

I use the term “Developer” as we are both helping to develop software. I believe I got the analogy of eating from Michael Bolton - you can’t keep stuffing food in your mouth (programming) without swallowing (testing). 

This post builds on that idea to share how I use the fire triangle as a metaphor for activities & roles that play a part in software development.

TL;DR

Software development is comprised of analysis, build & test. If you take one of these elements away, you decrease the chances of developing software which solves the problem.

Context

For those of you who subscribe to the DevOps model, this post is focusing on the left-hand loop of the double Möbius strip. If you’re being successful with DevOps, I’m thinking you’re not experiencing the behaviours I’m discussing here & this post may not be relevant for you 🙂

“Developers develop & Testers test” is a mantra that is gradually being broken down, but that behaviour still holds true to some degree for many organisations.

Great strides have been taken & discussed around what team member can do what testing (i.e. who can test for what risk). I’ll not be covering those ideas in this post again - if you want to know more about those ideas, please don’t hesitate to reach out to me & I’ll happily point you in the right direction/s.

This post also does not cover the project management iron triangle.

This post is about the first steps I take when encountering a team that has strong boundaries between problem definition & problem solving.

Why are Testers Developers?

I’m not one for job titles. Different roles can help out with different aspects of different activities.

I refer to myself & other development team members as “Developers” due to the fact that we are all helping to develop software.

Software development is comprised of the activities analyse, build & test. All team members should play a part in each of these activities to facilitate shared understanding of the problem.

This shared understanding helps the team determine when they have developed software which solves the problem.

Obviously, there are other team members who are not Developers who can help with each of the activities (e.g. PO, SOx controller, FS Compliance…) Arguably they should be included under the development umbrella, but that is a conversation for another day (as it muddies the purpose of this model for now - remember, all models are wrong, some are useful).

The model I use to help others understand why we’re all developers is the “Dev Triangle” (catchy, eh?) based on the ideas behind the fire triangle. 

For those who are unaware, the fire triangle suggests that if you take 1 of the 3 elements away, you no longer have fire.

Examples include using water to remove the heat, fire blanket to remove the oxygen or making a smaller fire before the larger fire (escape fire) to remove the fuel (e.g. the Mann Gulch Fire)

Dev Triangle model

Here’s the model, in all it’s PPT diagram magnificence:

If you buy into the idea that software development is made up of
analysis, build & test, then hopefully you can also buy into the idea of removing one of these elements means that you no longer have (good) software development:

• Remove Analysis - what’s the problem? how will we know when we’re done?
• Remove Build - we don’t have a solution…
• Remove Test - how do we know if we’ve solved the problem? Have we created or discovered more problems?

Also with this “Dev Triangle”, you can how the different activities can merge with / overlap one another. AKA pairing.

With this model, the titles are less important as each team member can help out with each activity.

• Is a tester testing when acting as a rubber duck to help the programmer out of a pickle?
• Is the business analyst doing analysis when running a business scenario through a build in the test environment?
• Is the programmer programming when asking questions in a 3 amigos session?

What do you think? Can you buy into this model?