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?
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.
"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.
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.