Always keen to share @sah .
Since I was a coder for a long time, things like toolchain and deployment are not really scary for me. I have always thought that this entire “quality” job description is really not only about verifying that the software we ship is good, but also that the way we create it and ship it is good also.
A bit like testing hammers in a hammer factory is not about checking that the handle does not break, but also that the wood it was made from, was consistently dried and compressed first so that it does not fall apart later. There are lots of things you cannot test on the shipping day. So, yes I believe that testers should know how all the parts get collected up, compiled and all, before we get to start the system testing. And by definition, have also found that I get involved in helping to deploy to live, but I don’t get deeply involved in the OPS infrastructure. Production OPS is a weird place, and the dev-ops term bandied about makes it sound as if you can just switch from one to the other, that’s simply not true. It’s about scale. I really hope we kill off the term dev-ops, they are not a one single thing, what most of us do is really all “pipeline”.
OPS is like the electricity company, they keep the lights on and the fuses replaced, DEV are like the gas-generators and wind farms. Even nuclear plants is OPS, they are the 20-year plan people, and are relatively more boring.
I, see “generalist” testers as being people who can walk into all of these places and help make improvements though. A thing I consistently noticed when you are doing a release for example, is that if you find a defect, you have to be able to properly decide if it’s a showstopper, and how long it will take to rebuild. For example if a large batch of “small” defect fixes you might need as a result for a fresh release candidate will be able to be built and tested individually or as one big batch. So having good visibility of the health of the toolchains and build pipeline stability is key to how you release. And visibility of process and people and resources. If build stability is flakey, or slow, doing a fresh rebuild for a small fix can sometimes cause you more pain for example. Developers will always drift towards expertise in an area of not just the tech stack, but also the area of the pipeline or SDLC that give them the most reward. Testers in smaller companies do not get to choose, we need to be over the whole thing.
Release, is another topic altogether relying more on communication (which I rubbish at,) but also on planning detail level. I’ll have to find a person who has written a good blog about release.