I work with a cozy 11 person DevOps team. I say DevOps, because we are running the development and operations of a fairly reasonable sized (in the millions) user base for a particular windows application product. We do ok, and I really like working on this, with these specific people.
These specific people are all individuals, 6 developers and 5 testers. That is at least the high level categorization. Yesterday was a particularly interesting day and I tweeted about it.
Watching the ratio, thinking it is telling about the work we do in the categories of "dev" and "test" makes little sense. But watching the ratio as how many people hold the space for quality ("what do we really mean by done") and how many people hold the space for smart solutions ("how do we change things for the better") makes a lot more sense.
The testers implement features. The developers implement tests and explore. And this all is very natural. Everyone pitches in within what they can do now, stretching their abilities a little.
I think of the two main roles we hire for as centers from which we operate. When named a tester, you naturally navigate towards caring for quality, feedback and systems to give that feedback. Your home perspective is one of skepticism, wanting to believe that things could be broken. When named a developer, you naturally navigate towards adding functionality and internal quality to enable future work, and delivering changes to users to change their experience with the product. Your home perspective is one of believing in possibilities, seeing how things could work. When there is space for both perspectives in collaboration, better software tends to emerge.
I have been the solo tester with 15 developers around me, and holding space for quality feels different there than it does here. Here I am not alone. And a lot of times I find the best quality advocates are those I would block as developers.
I still call them testers and developers, because they still are testers and developers. But they are not binary. The testers are a little bit more testers than developers. The developers are a little bit more developers than testers.
Seeking for both helps in hiring. It helps in creating a sense of purpose these people fulfill within the team while allowing the stretch. In the end of the day we need both perspectives and having people who feel ‘home’ in different roles help keep the perspectives strong.
There is no good word to move both into in a way that doesn’t send the message we give up on testers. There are people who want to be testers. Being a tester is great. Yet when seeking this one word, our gravitation is towards making us all developers.
I'm a big believer in job crafting - the idea that no matter what job you hold, you do little (or bigger) things to make it the job you want. The job that looks and feels like you. If you were hired for a purpose, crafting into a place where you forget what you came to do isn't what we seek. Understanding your purpose and value you are hired to deliver is important. But letting that stop you from growing, doing things smart or different would not be right.
So if a tester developers features, they can still be a tester. If they don't test anymore, they should probably not be testers. Promise of a service that isn't there is just dishonest.
These specific people are all individuals, 6 developers and 5 testers. That is at least the high level categorization. Yesterday was a particularly interesting day and I tweeted about it.
On this day when two of my team’s testers were implementing features and one of my team’s developers was manually testing for great results, I think back to ‘what’s the dev/tester ratio’.— Maaret Pyhäjärvi (@maaretp) October 3, 2019
Watching the ratio, thinking it is telling about the work we do in the categories of "dev" and "test" makes little sense. But watching the ratio as how many people hold the space for quality ("what do we really mean by done") and how many people hold the space for smart solutions ("how do we change things for the better") makes a lot more sense.
The testers implement features. The developers implement tests and explore. And this all is very natural. Everyone pitches in within what they can do now, stretching their abilities a little.
I think of the two main roles we hire for as centers from which we operate. When named a tester, you naturally navigate towards caring for quality, feedback and systems to give that feedback. Your home perspective is one of skepticism, wanting to believe that things could be broken. When named a developer, you naturally navigate towards adding functionality and internal quality to enable future work, and delivering changes to users to change their experience with the product. Your home perspective is one of believing in possibilities, seeing how things could work. When there is space for both perspectives in collaboration, better software tends to emerge.
I have been the solo tester with 15 developers around me, and holding space for quality feels different there than it does here. Here I am not alone. And a lot of times I find the best quality advocates are those I would block as developers.
I still call them testers and developers, because they still are testers and developers. But they are not binary. The testers are a little bit more testers than developers. The developers are a little bit more developers than testers.
Seeking for both helps in hiring. It helps in creating a sense of purpose these people fulfill within the team while allowing the stretch. In the end of the day we need both perspectives and having people who feel ‘home’ in different roles help keep the perspectives strong.
There is no good word to move both into in a way that doesn’t send the message we give up on testers. There are people who want to be testers. Being a tester is great. Yet when seeking this one word, our gravitation is towards making us all developers.
I'm a big believer in job crafting - the idea that no matter what job you hold, you do little (or bigger) things to make it the job you want. The job that looks and feels like you. If you were hired for a purpose, crafting into a place where you forget what you came to do isn't what we seek. Understanding your purpose and value you are hired to deliver is important. But letting that stop you from growing, doing things smart or different would not be right.
So if a tester developers features, they can still be a tester. If they don't test anymore, they should probably not be testers. Promise of a service that isn't there is just dishonest.
