3 ms·

I don't agree. You can't finish a project without developers and you can finish it without testers. I've seen a tester changing requirements on the go, delayi

I don't agree. You can't finish a project without developers and you can finish it without testers. I've seen a tester changing requirements on the go, delaying features for things that aren't even the case. Those change requests then cause bugs, because... Dev. The most important thing for a dev is domain knowledge and letting them care about the product. Usually, when the original Dev leaves ( monolith), it's enough to call the project abandoned, but maintained. Leaving the devs wanting to spend a minimal amount of work with it. And that's going to trigger sloppyness.

EdwardDiego 6y ago
> You can't finish a project without developers and you can finish it without testers. ...for a given value of finished. My value of finished involves "no significant bugs that cost thousands of dollars of revenue per day". And in the past, QA has repeatedly caught such bugs, despite ample testing by the devs. It really comes down to the mindset, and the approach - a QA approaches testing code differently to a dev who wrote the code. > I've seen a tester changing requirements on the go, delaying features for things that aren't even the case. In a well-functioning team, requirements should be explicit, understandable, achievable, realistic, and _agreed upon_ from the get-go. Once agreed, devs and testers work to those requirements. If, during the development cycle, it's realised that a requirement is lacking, or indeed, entirely absent, then it should definitely be discussed between devs and QA, at the very least, and _agreed upon_ - noting that sometimes, it might be a reasonably significant change in requirements that the business needs to be involved also in reaching that agreement. It may change delivery time, or delivered capacity etc. The ideal, from my POV, is having testers fully involved in the planning discussion / backlog grooming whatever you call it, where your team ensures that the requirements from business are specific, realistic, achievable, and useful. And then, hopefully, given the entire team's domain knowledge, that is, domain knowledge from developers AND QA, because they will have a metric shit ton also, and I find it curious you only ascribed that to devs... ... then, hopefully you can determine which requirements are missing, get the business to agree, and then make those part of the agreed upon work also. You'll note that I'm not speaking on dev vs. QA, rather on process and team structure. The issues you faced are not issues inherent to QA. The issues you faced are due to process and team structure.
void_mint 6y ago
I'll bite. > without testers. A "tester" is far far far away from a legitimate QA person. > I've seen a tester changing requirements on the go, delaying features for things that aren't even the case. Hiring bad employees doesn't invalidate any role. It invalidates A.) Your hiring process for that role, and B.) That employee

EdwardDiego 6y ago

> You can't finish a project without developers and you can finish it without testers. ...for a given value of finished. My value of finished involves "no significant bugs that cost thousands of dollars of revenue per day". And in the past, QA has repeatedly caught such bugs, despite ample testing by the devs. It really comes down to the mindset, and the approach - a QA approaches testing code differently to a dev who wrote the code. > I've seen a tester changing requirements on the go, delaying features for things that aren't even the case. In a well-functioning team, requirements should be explicit, understandable, achievable, realistic, and _agreed upon_ from the get-go. Once agreed, devs and testers work to those requirements. If, during the development cycle, it's realised that a requirement is lacking, or indeed, entirely absent, then it should definitely be discussed between devs and QA, at the very least, and _agreed upon_ - noting that sometimes, it might be a reasonably significant change in requirements that the business needs to be involved also in reaching that agreement. It may change delivery time, or delivered capacity etc. The ideal, from my POV, is having testers fully involved in the planning discussion / backlog grooming whatever you call it, where your team ensures that the requirements from business are specific, realistic, achievable, and useful. And then, hopefully, given the entire team's domain knowledge, that is, domain knowledge from developers AND QA, because they will have a metric shit ton also, and I find it curious you only ascribed that to devs... ... then, hopefully you can determine which requirements are missing, get the business to agree, and then make those part of the agreed upon work also. You'll note that I'm not speaking on dev vs. QA, rather on process and team structure. The issues you faced are not issues inherent to QA. The issues you faced are due to process and team structure.

void_mint 6y ago

I'll bite. > without testers. A "tester" is far far far away from a legitimate QA person. > I've seen a tester changing requirements on the go, delaying features for things that aren't even the case. Hiring bad employees doesn't invalidate any role. It invalidates A.) Your hiring process for that role, and B.) That employee