I used to work in a scale-up where we automate as much as we can (regardless if unit, integration or e2e - manual is more of an exemption). All the deterministic tests are integrated with the CI/CD pipeline so the feedback is faster and there is no manual intervention involved. As a QA, I collaborate closely with the developers so we can prevent bugs together instead of raising bugs. With that “Devops” approach, we are able to release anytime we want (there are no weekly, monthly or long-planned scheduled releases).
I was poached by a bank with a monthly release cycle and the ask is for me to improve the process so we can release on a weekly basis.
They have a low automation coverage so that is one thing I am looking at for obvious reasons. They have the latest dev and CI/CD tech stacks but under-utilised. So this “tool” part can be addressed with a good strategy.
My challenge right now is the process and people. Process is following agile principles but very waterfall where everything is documented (its banks and stakeholders would always love everything audited) and so many checklist and gates that its feels very siloed between roles. There is too much focus on admin / process instead of being more collaborative. The unnecessary checks every step of the way is slowing down the release cycle in my opinion. On the other hand, the people aspect is where developers feel like QA should test it at the end (hence, quality of their work is more of an after-thought - hello, single point of failure at the tail end of the development cycle!). And if the QA would like to collaborate, the developer seem hesitant to spend time with QA and tells them off with “Just raise a bug and I will have a look at it”. There is obviously a culture shift required.
I’ve been sharing some materials and courses, started pair testing with devs, and asked them to do more unit testing, etc. I’m trying to be more inclusive and doing some QA sessions on the test scenarios.
I am trying to be more vocal but being new, I don’t want to be over-stepping and be very opinionated as I would like to build a good working relationship with the team and that’s by building their trust.
With that , what would be good starting point to tackle the “process and people” issue with a short term and long term plan?
Firstly, congrats on the new job and the challenge that lies ahead. In my opinion you’ve bumped into one of the biggest reasons why everybody should focus less on tooling and tech stacks, and more on people and processes if they want to make an impact.
I think you already touched on the core of the issue. It’s the people and the culture. And that’s very very hard. In my experience this is something that you first need to make as small as possible. You’re not going to change everyones mind overnight, so there is no point in trying that. What you should be looking for is a couple of like minded people that are actually open to change. Get them together, get them working together and try to form a team around them. They can be your transformation team. Secondly, you’re going to need some buy in from management. Since you were specifically broad on to change things up I think this part (which is the one of the hardest most of the time) is actually pretty much OK. Then it’s key to exclude the transformation team from the daily operations. They need to have their hands free to start experimenting and try new things. They’re not able to do that if they are still in this 50/50 split between the “old” way and the new way of working.
And then it’s a matter of see where things are going. This transformation team is basically the tip of the sword. They try things so others don’t have to, which should make it a lot safer. It’s important though to be very vocal about the learnings from this team and shared those as much as possible. Eventually this should help with moving things along.
I highly recommend reading the DevOps Handbook. It also touched on some of the challenges you’re facing and I believe it will be a great resource for you.
Thanks @hylke for the tips. I like this lean approach of getting small alliances who can help get the buy-in from a wider group.
I’ve already ordered the DevOps handbook. Looks interesting. 