<blockquote>
  <p>"You build it, you run it"</p>
</blockquote>

<p>This quote aim at giving emphase on the break between silo teams, one the principle of devops is to avoid silo achieving one task.<br>
While the idea here focus on the build and run phases, the important idea is to bring a whole team together, from architecture to exploitation <strong>roles</strong>. A "Devops Team" would be made of all roles taking part in the software life-cycle, including tester role, with no-one in the team handling a single role. </p>

<p>The main change for a tester would be to learn to voice his/her opinions and feedback on the plan phase in an agile team and probably to take part in some operational tasks.</p>

<p>But all in all, there's no exact rule, what someone previously in a silo would do in a "Devops team" depends on what he/she is more interested in and comfortable to do. That's one of the challenge of a newly created team, spot the best abilities of everyone to share the load on the most efficient way.</p>

CC BY-SA 3.0
2017-06-27T11:56:44.110Z
may I ask whether you have had a certain DevOps team topology as suggested here [1] or all of them?
http://web.devopstopologies.com/
Ta Mu
CC BY-SA 3.0
2017-06-27T12:14:43.970Z
Not all of them, but we have more or less advanced product teams, A bunch are in type 1, we don't have really type 2 (too much products for a a too little Ops team at first), I think we have a team in Anti-type C also. Thanks for the link, it's a very interesting read..
Tensibai
CC BY-SA 3.0
2017-06-27T15:46:15.290Z
you are welcome; before there is a spread of this content - you know how fast it can happen - is there a chance to formulate a question to validate these topologies via this community without getting towards an opiniated thingy (e.g. maybe there is wording to tune, or add another type missing). Sth like "what is missing in these DevOps topologies?"...
Ta Mu
CC BY-SA 3.0
2017-06-28T08:08:39.670Z
I'm afraid that asking for opinions on something which is already an opinion won't bring anything valuable.
Tensibai
CC BY-SA 3.0
2017-06-27T11:39:51.487Z
2017-06-27T11:39:51.487Z
Tensibai
<p>I'm a senior engineer, in that capacity I make hires.</p>

<p>At this point in the devops progression, I'd find it difficult to hire a Test who could not easily transition to a Infrastructure Engineer role (what others might call Devops role)</p>

<p>I would not expect a tester for instance to know the intricacies of JVM multithreading or be very opinionated in python class design. I would expect them to be able to understand the source that they may write stub code or generate synthetic data.</p>

<p>I would expect a modern tester to know the basic arsenal of devops within my team. That would include: the provisioning of bare metal servers using our CM tools, the deployment of code via various artifacts or containers. </p>

<p>I would further require them to have some capacity as a Data Engineer in the sense of knowing how the data moves through a system. Thinking about where the single points of failures are and how to simulate failures, throttling etc.</p>

<p>I would never hire a tester to perform module level testing, which I would define as the interaction of a handful of classes (say 1-20) behind a network barrier. </p>

<p>tl;dr I would hire testers to setup environments, simulate (or replay) data through that environment and to cause chaos in the environment.</p>

CC BY-SA 3.0
2017-06-28T00:58:12.560Z
2017-06-28T00:58:12.560Z
bearrito
<p>IMHO that depends on what the role of the tester was before such transformation. BTW, I believe my answer applies to the DevOps transformation in general, not only to the <code>You build it, you run it</code> paradigm.</p>

<p>If the role was a drone job - mindlessly executing tests - it's bound to go away, automation will eat such jobs. </p>

<p>If the role included writing the test plans and specifications they could continue to do that or even morph into writing the corresponding automation scripts, side-by-side with the developers. Or standalone - in some environments it is mandatory to use a completely separate methodology/infrastructure/personnel for testing than the one(s) used for development. In many organisations testers are software engineers, just as developers.</p>

<p>If the role was executing intentionally unreliable/surprise tests, specifically requiring human traits (emotion, subjectivity, inspiration, reflexes, intuition, etc) to complement automated testing - that also won't change.</p>

CC BY-SA 3.0
2017-06-27T15:15:42.660Z
thanks Dan - I would like to read more about surprise tests, did not know there are such in software engineering field
Ta Mu
CC BY-SA 3.0
2017-06-27T15:24:23.343Z
@J.Doe I recently heard about the concept, before I discarded such testing as unreliable, thus unusable. Yet I was only looking at it as regression-detecting testing. But I gave it more thought and I believe there are areas where such testing could be really useful for development - for games or other heavy UX apps, for example.
Dan Cornilescu
CC BY-SA 3.0
2017-06-27T14:50:47.547Z
2017-06-27T14:50:47.547Z
Dan Cornilescu
<p>If the new paradigm is "You build it, you run it" (Werner Voegels, Amazon CTO) which obviously puts much more responsibility - and pressure - on software engineers, what does this change introduce to the task of the test team?</p>

<culture><testing>
What is the future role of tester?
Ta Mu
# What is the future role of tester?

(Asked by: username_0 on 2017-06-27)

If the new paradigm is "You build it, you run it" (Werner Voegels, Amazon CTO) which obviously puts much more responsibility - and pressure - on software engineers, what does this change introduce to the task of the test team?

**Tags:** culture, testing


---

## 3 answers

### Answer by username_3 on 2017-06-27. Score: 10 | Accepted answer

IMHO that depends on what the role of the tester was before such transformation. BTW, I believe my answer applies to the DevOps transformation in general, not only to the `You build it, you run it` paradigm.

If the role was a drone job - mindlessly executing tests - it's bound to go away, automation will eat such jobs.

If the role included writing the test plans and specifications they could continue to do that or even morph into writing the corresponding automation scripts, side-by-side with the developers. Or standalone - in some environments it is mandatory to use a completely separate methodology/infrastructure/personnel for testing than the one(s) used for development. In many organisations testers are software engineers, just as developers.

If the role was executing intentionally unreliable/surprise tests, specifically requiring human traits (emotion, subjectivity, inspiration, reflexes, intuition, etc) to complement automated testing - that also won't change.

> **Comments:**
> **username_0**: thanks Dan - I would like to read more about surprise tests, did not know there are such in software engineering field  
> **username_3**: @J.Doe I recently heard about the concept, before I discarded such testing as unreliable, thus unusable. Yet I was only looking at it as regression-detecting testing. But I gave it more thought and I believe there are areas where such testing could be really useful for development - for games or other heavy UX apps, for example.  

---

### Answer by username_1 on 2017-06-27. Score: 4

> "You build it, you run it"

This quote aim at giving emphase on the break between silo teams, one the principle of devops is to avoid silo achieving one task.  
While the idea here focus on the build and run phases, the important idea is to bring a whole team together, from architecture to exploitation **roles**. A "Devops Team" would be made of all roles taking part in the software life-cycle, including tester role, with no-one in the team handling a single role.

The main change for a tester would be to learn to voice his/her opinions and feedback on the plan phase in an agile team and probably to take part in some operational tasks.

But all in all, there's no exact rule, what someone previously in a silo would do in a "Devops team" depends on what he/she is more interested in and comfortable to do. That's one of the challenge of a newly created team, spot the best abilities of everyone to share the load on the most efficient way.

> **Comments:**
> **username_0**: may I ask whether you have had a certain DevOps team topology as suggested here [1] or all of them? http://web.devopstopologies.com/  
> **username_1**: Not all of them, but we have more or less advanced product teams, A bunch are in type 1, we don't have really type 2 (too much products for a a too little Ops team at first), I think we have a team in Anti-type C also. Thanks for the link, it's a very interesting read..  
> **username_0**: you are welcome; before there is a spread of this content - you know how fast it can happen - is there a chance to formulate a question to validate these topologies via this community without getting towards an opiniated thingy (e.g. maybe there is wording to tune, or add another type missing). Sth like "what is missing in these DevOps topologies?"...  
> **username_1**: I'm afraid that asking for opinions on something which is already an opinion won't bring anything valuable.  

---

### Answer by username_2 on 2017-06-28. Score: 3

I'm a senior engineer, in that capacity I make hires.

At this point in the devops progression, I'd find it difficult to hire a Test who could not easily transition to a Infrastructure Engineer role (what others might call Devops role)

I would not expect a tester for instance to know the intricacies of JVM multithreading or be very opinionated in python class design. I would expect them to be able to understand the source that they may write stub code or generate synthetic data.

I would expect a modern tester to know the basic arsenal of devops within my team. That would include: the provisioning of bare metal servers using our CM tools, the deployment of code via various artifacts or containers.

I would further require them to have some capacity as a Data Engineer in the sense of knowing how the data moves through a system. Thinking about where the single points of failures are and how to simulate failures, throttling etc.

I would never hire a tester to perform module level testing, which I would define as the interaction of a handful of classes (say 1-20) behind a network barrier.

tl;dr I would hire testers to setup environments, simulate (or replay) data through that environment and to cause chaos in the environment.


---

