Skip to main content

Tester in Development

After I shared this on Twitter a little while ago:

I got to thinking about the 'Developer in Test' pattern which has gained in popularity over the last 15 years of my testing career (but probably existed way before that), so here is my expansion on the point. 

Who in their organisation has one (or many) of these?
  • Technical Tester
  • Developer in Test
  • Software Engineers in Test
  • Software Development Engineers in Test
  • Software Engineers in Test Levels One, Two and Three

* Note 1 - As a sub pattern, it seems that the job title for this pattern has got longer over time, although I am being a little naughty with data. However, a would it be the first time a (sometimes) badly defined job got a lengthy title to give it some credence?
** Note 2 - I have never heard of a Programmer in Test. Let me know if anyone has seen/lived this. It may have the benefit of at least describing the primary activity of the job, although maybe testing should be that primary activity.
*** Note 3 - I would very much like to be known as a 'Tester in Development' from now on. Which would be a ludicrous title right? Suggesting that I am some kind of foreign body, rather than part of how good stuff is built? Although, read in a learning context, we are all testers in development.

I get the feeling there will be a few nods out there. 

I guess we could argue about a few of these titles. However, for me, testing is a technical profession, as technical skills are acquired via learning and practice, specific to that profession or the task at hand. Hell, most people who have a profession have theoretically at least acquired specific technical skills, rendering them technical, with what proficiency is a different debate. Testing, I don't see it as an exception. But, you know, testers need to more technical...

I digress.

Patterns within Patterns 

If you do have one of the specific titles above in your organisation, there may be one or more of the following patterns swirling around in that larger pattern:

Not hiring developers who value testing...

Wrestling with your developers about delivering testable chunks of functionality? Thrown over the wall at the last minute? No unit testing? 500 errors when you load the new site (I'll let you decide if I mean http errors)? Unfortunately, developers who do not value testing are still very much part of the software development world. And if you don't determine their propensity to value testing at hiring time, your life will get very interesting in the next few months. So lets just hire a Developer in Test to bridge the expanding gap, rather than those who view testing as a key part of building things.

Developers don't have time to create tools for testing...

Suppose you get the first bit right and you hire a bunch of developers that value testing. You, as a tester, identify a system which you need to be able to control and observe closely to discover information about risk, maybe even save a bit of time down the way, a little early discovery. But no one has time for that. Sounds like a great idea, but we need to be the first to bust open the Iron Triangle of cost, time and scope to deliver this thing. Let's get a Software Engineer in Test to do it. This might get the job done but it also might point to a deeper sustainable pace problem.

Testers playing to weaker skills over strengths...

Programmers are, for the most part, really good at programming and they practice lots. Testers, while a great many can program, are probably less effective at it, they practice less. While I'm not saying testers shouldn't program, but the power of a joint approach to say, building a check automation framework or a tool to observe the health of a system, creates an opportunity to play to strengths on all sides. I can program, but the developers I work with are better at it than me. I encourage them to do it, and work with them to make meaningful checks and information diviners. Or we can compartmentalise that work into a Technical Tester, reduce the level of engagement and probably subtly miss the point from a programming and testing point of view.

Tool aware but technologically unaware testers...

A developer once said to me:
"Ash, now the testers have got hold of {insert popular service layer testing tool here}, it's like having a rail gun full of XML indiscriminately firing the wrong thing at the wrong endpoints."
Well, I'm all for a bit of randomness in testing, it certainly tipped out a boatload of error handling goodies. However, it points to a wider phenomenon. Testers becoming tool aware but lacking technological awareness. As in, I have a means of invoking this RESTful service but I don't understand the structure of it, its strengths and weaknesses, where I need to probe. So, this type of problem might be farmed to a Software Developer in Test Level 3. At the expense of the learning required by others, which just might help them on the journey of becoming technologically aware.

Local Optimisations

Technical Tester, SDiT, SDEiT Level X. Call it what you want, it's still one of my favourite local optimisations in testing, the system may need to fill that role, but we do so by giving someone a job. Based on the patterns above, we may be missing the bigger picture.


  1. What motivates you that drives but you need to have motivation for sure and I must say one of the great pieces I have read.

  2. Though the quote sounds funny but the fact is that testers are considered to be the same as you described. They are considered masters of everything but still their job is not as appreciated as developers job is. Many companies don't even feel the importance of having testers in their company.


Post a Comment

Popular posts from this blog

Testers Guide to Myths of Unit Testing

One area that testers might be able to enhance their contributions to software development teams is how we perceive and contribute to unit testing. I believe testers busting their own illusions about this aspect of building something good would bring us much closer to developers, and help us realise what other layers of testing can cover most effectively.

Also, I want to do a talk about it, so I figured I would test the premise, see if potential audiences were into it. I put this on Twitter:
Working on a talk about what testers might believe about unit #testing & how we interact with developers creating unit tests. Any challenges/additions for my list below? — Ash Winter (@northern_tester) December 19, 201730 replies with ideas tends to indicate that people might be into it. 
The ListI thought, as my final blog of 2017, I would provide a super useful list of the myths and legends we as testers might believe about unit testing:
That developer…

Why do Testers become Scrum Masters?

It was late and I was stuck on a train, so I pondered on the question of why do testers often (in my experience) become Scrum Masters. Its a very dear question to me, as its been a big part of my career journey In fact, I've been there and back again. Tester to supposed-to-be-testing-but-being-a-Scrum-Master to Scrum Master, back to Tester and very happy thank you.

I encapsulated my reasoning in the following:
Long train delay, decided to think about a thing. :) Why do testers (in my world anyway) often become Scrum Masters? — Ash Winter (@northern_tester) February 13, 2018The tweet got a lot of traction, and generated a couple of interesting threads which made me think.
Great list. Personally I think that as a scrum master I can add even more towards the goal of quality. — Christian Kram (@chr_kram) February 13, 2018 Perhaps part of the reason for the transition is a growing appreciation of where quality has its roots? If testing i…

Wheel of Testing Part 3 - Applications

I've only had to quit two jobs to finally find the time to finish this blog series. Winning at life. If you need reminders (like I did) check out Part 1 and Part 2 before reading on...

After the first two blogs regarding the Wheel of Testing, I was delighted to receive a few requests for the wheel itself, which got me thinking about applications of it, beyond what its original intent was, which I've explored in detail in part 1 of this series of intermittent blogs. Most models need a little air time to show their value, in software development we crank out models all the time, but I'm not sure how many get used. I am inspired by models such as the "Heuristic Test Strategy Model" by James Marcus Bach, as I have used it and seen the benefits it has brought for my clients, particularly the ability to ask questions. So, I wanted to create a model which has a number of use cases, both real and imagined:

Helping to unlocking a career in testing which may be stuck

It is no…