About me: software developer who is into JavaScript and NodeJS and constantly working on one or another side project and/or open source. I have a blog at https://alex-rudenko.com
About me: software developer who is into JavaScript and NodeJS and constantly working on one or another side project and/or open source. I have a blog at https://alex-rudenko.com
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. 😔
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
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. 😔