Are you only write tests? In my team, we also develop angular apps, but all testing from unit to E2E UI tests is done by our developers. Do you really see a need to have a separate QA?
At my location (one office of a larger organization), they try to maintain a 2:1 dev:QA ratio within teams. Devs write unit tests for their code and then QA writes the integration and E2E tests for the app as a whole.
In theory, this allows for devs to focus on deving and QAs to not be as tied to the code so they’re able to catch things better (going off of the spec rather than what the implementation does).
So, does it work in your opinion? I mean in terms of quality and also team responsibility? I would assume that it will end up in a situation where “they” write the bugs while “them” alway being to picky.
I’ve been on teams where it’s been siloed between dev and QA, and there has been a bit of infighting amongst those who find bugs and those who write code. It’s never been hostile just certainly a sense of otherness.
Most teams, though, if QA and dev are integrated then there’s no issue with that. Like, don’t have QA site bunched together away from dev, don’t have QA only lunches, etc. If everyone acts as a team, there’s no otherness.
Biggest issue I have with it is that I’m bored more often than not. Once I set up the initial framework, it’s a whole lot of waiting on dev to implement features for me to E2E test. 2:1 is good when a project is spinning up fast, but I think they need to revisit how many QAs are needed when a project is more in a sustaining pace. If the devs are working on infestructure or tech debt, I’ve got nothing to do.
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.
Are you only write tests? In my team, we also develop angular apps, but all testing from unit to E2E UI tests is done by our developers. Do you really see a need to have a separate QA?
At my location (one office of a larger organization), they try to maintain a 2:1 dev:QA ratio within teams. Devs write unit tests for their code and then QA writes the integration and E2E tests for the app as a whole.
In theory, this allows for devs to focus on deving and QAs to not be as tied to the code so they’re able to catch things better (going off of the spec rather than what the implementation does).
So, does it work in your opinion? I mean in terms of quality and also team responsibility? I would assume that it will end up in a situation where “they” write the bugs while “them” alway being to picky.
I’ve been on teams where it’s been siloed between dev and QA, and there has been a bit of infighting amongst those who find bugs and those who write code. It’s never been hostile just certainly a sense of otherness.
Most teams, though, if QA and dev are integrated then there’s no issue with that. Like, don’t have QA site bunched together away from dev, don’t have QA only lunches, etc. If everyone acts as a team, there’s no otherness.
Biggest issue I have with it is that I’m bored more often than not. Once I set up the initial framework, it’s a whole lot of waiting on dev to implement features for me to E2E test. 2:1 is good when a project is spinning up fast, but I think they need to revisit how many QAs are needed when a project is more in a sustaining pace. If the devs are working on infestructure or tech debt, I’ve got nothing to do.