Situation: So, we are now doing daily stand ups and did the first retrospecive after a long time. Each team member was asked to put out their Sads âšī¸ and Glads đ for the past sprint. But because it was the first time in a long time, we came up with a really long list from since the beginning. But the most Sad that I think needs to be addressed first was:
The QA team feels their role is neglected
Currently, we have three teams, i.e. devs, qa, implementors. QA team is supposed to be the bridge for the devs and implementors. QA files the feature requests and bugs found by them and implemetors. Devs deliver the updated version then QA performs tests and, if pass, releases to the implementors. What currently happens is that because of strict deadline, implementors are forced to use untested versions. I know. I know, sorry. But also, when the user discovers a bug, which is expected, the QA team takes the blame from the Project Manager. đ¤ĸ
What's the solution?
It's obvious that our process flow needs to be reconstructed. So I'm thinking of taking the QA team as the internal QA with the devs which will comprise the whole R&D team. Devs and QA are to work closely together to deliver the software. QA are to perform integration and funtional testing before devs can merge their changes to master repository (we are using git, btw). But. But. But I am thinking, as a dev, what a setback! Now, I need code review and QA approval to complete my pull request. I know I said 'work closely together', but still. Maintaining a develop branch also looks like an option. But I think that's just putting the load somewhere else on someone else. I know there should be something we can do about this. Maybe a new process flow? Maybe just restricting the implementors to access the builds? Help. đ
Top comments (4)
Who are implementors?
They're in charge of communicating with the client. Performing requirements gathering, deployment and support.
I see. So there are a couple of options which in my opinion can improve the situation:
Option # 1 (promotes the status quo). It seems that the release planning does not account for QA. You need to change how you plan things so that it includes QA. For example, you need to ship the version X in 3 weeks. It can mean, for example, two weeks of development and one week of QA. If the development requires extra time, you need to reduce the number of features which ship in the version. It's crucial to define what it means that a version is ready for QA and how you handle bugs. For example, QA can say that the release does not happen if there are bugs. And this should be acceptable by your organization/management.
Option # 2 (changes the status quo). You make QA team the part of the development team. What it means: there is no such thing anymore as developers develop and the QA checks. So the entire team is responsible for the quality. Some team members (former QA) focus on the tasks to ensure quality more than other team members. Such tasks can include: setting up a mandatory code review process, making sure automated tests are adequate, making sure documentation is proper and so on.
And, in general, blaming culture is quite dangerous for your organization. I think the project managers should reflect on their management style.
Hi, thanks! We discussed these with the team and we decided to resetablish the previous process flow (option #1 promote the status quo) which strengthens the role of the QA team between the dev and implems. With this, we are hoping to improve quality and define everyone's role in the company. Your suggestions greatly helped in coming into the decision. Thank you for sharing your time and knowledge. đ
As for the blaming culture, you're right, things need to change or it will be very hard for the team to learn and move on. We are now working on how to relay it effectively to the PM. đ