Of late our organisations’s systems have been under too many configuration changes, that may sometimes require some code change (e.g. just a database table update to change some configurations). The team has decided that such operations should form a part of BAU for Operations teams and since they need to be tested and verified, the Operations teams should ideally be testing such changes.
However, the testing guidelines need to be followed which makes the test team equally responsible for what’s been tested for such changes.
I have been asked to come up with some process around it where test team can oversee and provide a framework to the Operations team.
What would you suggest the considerations should be while formalising a process for this? Also, is there any formal “name” for this kind of testing?
First post - yeah! this is a thing, and a thing I have been working with a lot, the last years: Infrastructure testing. I have some previous talks on the topic, I can send you links to if needed.
I would recommend to leave the execution and detailing of the testing of infrastructure to the Ops team. They probably already have certificates, training and knowhow. Skills you the test team would have a hard time building. Similarly to when you have end users do UAT
Work to enable the Ops team - recognise they are on a journey to learn/incorporate testing and an activity. They will never be testers, but they can learn a lot about testing. On the other hand they probably already know all the buggy areas, pitfalls and what’ifs.
Jesper pretty much nails it. The skills of a software tester do cover process tricks that your OPS team can learn from you, but it’s most often not your responsibility to do that test work at all. It’s not going to be in your core domain competency as a tester and because unlike the “manufacturing”, that we all do here, there is almost no iterative process. But does not mean you cannot swap tactics, over a cuppa tea/coffee.
Thanks for sharing your thoughts
Even I see such test executions as not test team’s responsibility but I am also learning with them while overseeing their testing and helping them where I can. What they have learned from me so far is the different scenarios to be catered for (of course they will not think like testers do )
Apart from this collaboration, would you suggest any “processes” as such that can be laid out formally for those who are new to this type of testing (Infrastructure testing and other testing done by Ops is fairly new in our organisation) and to ensure some uniformity across the board?
Wrt. process/formality: Build towards the same formality you have for the test team and rest of the org. So this could be in the form of a plan (test plan, test charter, jira thing), some list of tests (in a test tool or mindmap) and some form of test result / report.
Perhaps the Ops staff have some smart tools or exports that can automate parts of these activities?
Perhaps for me, the biggest part of the being a tester lesson has been, that it’s a journey.
Day one will not see you land with a test plan filled with test cases, so starting from a really small base is good. Sounds to me like a short sit down discussion with the Product Owner (PO) is in order, to work out if the PO sees the same operational and deployment risks that you are seeing.
I think it’s wonderful when the tester gets themselves out of the test lab, and asks the hard questions “in the light of day” so-to-speak.
