5 ms·

> yet no one seems to agree with me that devs should not write their own tests. I'll die on this hill. The developer that wrote the code by definition cannot w

> yet no one seems to agree with me that devs should not write their own tests. I'll die on this hill. The developer that wrote the code by definition cannot write an appropriate test suite for it. It is entirely possible/probable that details missed in implementation will be missed entirely in test, as the developer missed them. < controversial take> Manual QA promotes bad habits and is not a great thing to introduce to an org. SDETs/QA Engineers/Developers whose role is explicitly to create tests for an org are worth their salary 10x. </ controversial take >

kqr 6y ago
> are worth their salary 10x. Are you saying it's a bad role to get into because it's underpaid? ;)
- EdwardDiego 6y ago
  Yes, sadly for some reason in most orgs, QA/QE whatever you're calling it, pays lower than dev work. Even though, IMO, they're worth far more.
  - hvidgaard 6y ago
    They are worth more in the same sense a salesman is worth more than the dev. Without the dev neither have anything to do, yet they all provide equally valuable work. Perhaps it's not a matter of value, but supply and demand.
  - NicoJuicy 6y ago
    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
petee 6y ago
Reminds me of a NASA failure report where they determined the reason the satellite failed immediately after launch was because they built their own circuit-test device to match their assumptions rather than reality. But it passed their test. Now it is spinning uncontrollably above us. Developers also risk the "I thought of that already so I don't need to test it thoroughly" pitfall, eventually leading to the usual "we didn't think it was possible fail like that"
- HPsquared 6y ago
  See also the Hubble telescope mirror - it perfectly "passed" the test using the sophisticated automated testing machine, which was set incorrectly.
EdwardDiego 6y ago
I'm with you on that hill. Good QA have a vastly different mindset to devs - and they're not prone to the unconscious tunnel vision you develop when writing code that assumes a particular approach. However, I have to say, depending on your product, some of the best damn QA I've worked with aren't writing integration tests, at most they're using SQL to get the DB into an appropriate state, and then they're doing the rest manually, but it's really about their mindset, manual is just the easiest approach for them. Manual encompassing "click on the thing" as well as "hit the endpoint with Postman". It's their mindset I value most. And some of the best pairing I've ever done is with a QA to write integration tests.
Jare 6y ago
> Manual QA promotes bad habits and is not a great thing to introduce to an org Interactive software, and very interactive software like games, absolutely requires good manual QA. There's a lot of interactive software out there.
josemanuel 6y ago
The way I see this is there’s 2 aspects to test. 1) Uncovering bugs. 2) finding future regressions. Having the developer writing the tests suits scenario 2) but it’s totally inappropriate for scenario 1).
bryanrasmussen 6y ago
>Manual QA promotes bad habits I could understand Manual QA does not scale, but why bad habits? What if the person doing Manual QA of an application also then writes tests afterwards based on what they have determined are the likely problems in the application - which is what I would do if I was going to write (ui) tests, test it by hand first.
- void_mint 6y ago
  > What if the person doing Manual QA of an application also then writes tests afterwards based on what they have determined are the likely problems in the application I wouldn't really call this manual QA then. I'm describing the thousands of orgs whose QA processes are limited to "These people will run these five thousand test cases by hand for every release", and/or "These people will be handed a ticket and manually click all the buttons before marking it done"
pydry 6y ago
>The developer that wrote the code by definition cannot write an appropriate test suite for it. It is entirely possible/probable that details missed in implementation will be missed entirely in test, as the developer missed them. The same is true of pretty much everybody - PMs and QA included. Everybody misses details and edge cases. It's better to write the test suite in a readable form and get everyone to take a look at it. Unit tests are almost entirely unsuitable for this purpose most of the time.
- croon 6y ago
  > The same is true of pretty much everybody - PMs and QA included. Everybody misses details and edge cases. No, the same isn't true of everybody. They would all have to miss the exact same details and edge cases, was the point. It's the same reason that you have sensor redundancy, you don't have the same sensor measure twice and trust it.
  - pydry 6y ago
    ?? That's exactly what I meant. With inputs from a diversity of people you can pick up the edge cases more easily. Separately everybody will miss some.
    - croon 6y ago
      Then you just repeated what your parent already said. Your comment read like dissent.
      - pydry 6y ago
        That is not what the parent said. They advocated specifically for developers not writing test cases. I do not.
        croon 6y ago
        They argued that separate people should look at a problem so as not to make the same mistake twice: > The developer that wrote the code by definition cannot write an appropriate test suite for it You said that issue could be applicable to everyone: > The same is true of pretty much everybody - PMs and QA included. Everybody misses details and edge cases. I pointed out that the issue can't be true of everybody, since everyone other than the original developer would generally avoid it. You then said I repeated what you said. Which is it?
marcus_holmes 6y ago
There should be both. Unit tests written by devs are not testing that the system does what it is supposed to do. They're testing that the code does what the programmer intended it to do. They have to be written by the programmer because they're coupled with the code. There's a separate testing process needed (as you say) that tests if the system does the thing it's supposed to do. The programmer cannot do this, precisely because it's basically testing their understanding of the requirements. I have my co-founders Q&A everything before rolling out to production. It's a pain, but it's saved us a few headaches where I was just following the golden path and missed some obvious problems.
- 01100011 6y ago
  Depends. If the 'unit' is big enough to have an interface spec then a different dev should write the test. If you're doing function level unit testing, a dev should write it. There's a grey area between those two extremes. My original post was intended to focus on system and api level testing but I wasn't clear on that.
  - marcus_holmes 6y ago
    I agree, there's a ton of grey areas in this whole field, especially around the borders between layers.
u02sgb 6y ago
I'd argue that while they can't "do" their own testing, developers should be writing Unit tests that prevent their code from being broken in future. They should also be writing tests that exercise their code so they find corner cases that were not obvious when coding. The problem is it's difficult to define what that is (and particularly to teach a junior Dev what to do).

kqr 6y ago

> are worth their salary 10x. Are you saying it's a bad role to get into because it's underpaid? ;)

EdwardDiego 6y ago
Yes, sadly for some reason in most orgs, QA/QE whatever you're calling it, pays lower than dev work. Even though, IMO, they're worth far more.
- hvidgaard 6y ago
  They are worth more in the same sense a salesman is worth more than the dev. Without the dev neither have anything to do, yet they all provide equally valuable work. Perhaps it's not a matter of value, but supply and demand.
- NicoJuicy 6y ago
  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

petee 6y ago

Reminds me of a NASA failure report where they determined the reason the satellite failed immediately after launch was because they built their own circuit-test device to match their assumptions rather than reality. But it passed their test. Now it is spinning uncontrollably above us. Developers also risk the "I thought of that already so I don't need to test it thoroughly" pitfall, eventually leading to the usual "we didn't think it was possible fail like that"

HPsquared 6y ago
See also the Hubble telescope mirror - it perfectly "passed" the test using the sophisticated automated testing machine, which was set incorrectly.

EdwardDiego 6y ago

I'm with you on that hill. Good QA have a vastly different mindset to devs - and they're not prone to the unconscious tunnel vision you develop when writing code that assumes a particular approach. However, I have to say, depending on your product, some of the best damn QA I've worked with aren't writing integration tests, at most they're using SQL to get the DB into an appropriate state, and then they're doing the rest manually, but it's really about their mindset, manual is just the easiest approach for them. Manual encompassing "click on the thing" as well as "hit the endpoint with Postman". It's their mindset I value most. And some of the best pairing I've ever done is with a QA to write integration tests.

Jare 6y ago

> Manual QA promotes bad habits and is not a great thing to introduce to an org Interactive software, and very interactive software like games, absolutely requires good manual QA. There's a lot of interactive software out there.

josemanuel 6y ago

The way I see this is there’s 2 aspects to test. 1) Uncovering bugs. 2) finding future regressions. Having the developer writing the tests suits scenario 2) but it’s totally inappropriate for scenario 1).

bryanrasmussen 6y ago

>Manual QA promotes bad habits I could understand Manual QA does not scale, but why bad habits? What if the person doing Manual QA of an application also then writes tests afterwards based on what they have determined are the likely problems in the application - which is what I would do if I was going to write (ui) tests, test it by hand first.

void_mint 6y ago
> What if the person doing Manual QA of an application also then writes tests afterwards based on what they have determined are the likely problems in the application I wouldn't really call this manual QA then. I'm describing the thousands of orgs whose QA processes are limited to "These people will run these five thousand test cases by hand for every release", and/or "These people will be handed a ticket and manually click all the buttons before marking it done"

pydry 6y ago

>The developer that wrote the code by definition cannot write an appropriate test suite for it. It is entirely possible/probable that details missed in implementation will be missed entirely in test, as the developer missed them. The same is true of pretty much everybody - PMs and QA included. Everybody misses details and edge cases. It's better to write the test suite in a readable form and get everyone to take a look at it. Unit tests are almost entirely unsuitable for this purpose most of the time.

croon 6y ago
> The same is true of pretty much everybody - PMs and QA included. Everybody misses details and edge cases. No, the same isn't true of everybody. They would all have to miss the exact same details and edge cases, was the point. It's the same reason that you have sensor redundancy, you don't have the same sensor measure twice and trust it.
- pydry 6y ago
  ?? That's exactly what I meant. With inputs from a diversity of people you can pick up the edge cases more easily. Separately everybody will miss some.
  - croon 6y ago
    Then you just repeated what your parent already said. Your comment read like dissent.
    - pydry 6y ago
      That is not what the parent said. They advocated specifically for developers not writing test cases. I do not.
      - croon 6y ago
        They argued that separate people should look at a problem so as not to make the same mistake twice: > The developer that wrote the code by definition cannot write an appropriate test suite for it You said that issue could be applicable to everyone: > The same is true of pretty much everybody - PMs and QA included. Everybody misses details and edge cases. I pointed out that the issue can't be true of everybody, since everyone other than the original developer would generally avoid it. You then said I repeated what you said. Which is it?

marcus_holmes 6y ago

There should be both. Unit tests written by devs are not testing that the system does what it is supposed to do. They're testing that the code does what the programmer intended it to do. They have to be written by the programmer because they're coupled with the code. There's a separate testing process needed (as you say) that tests if the system does the thing it's supposed to do. The programmer cannot do this, precisely because it's basically testing their understanding of the requirements. I have my co-founders Q&A everything before rolling out to production. It's a pain, but it's saved us a few headaches where I was just following the golden path and missed some obvious problems.

01100011 6y ago
Depends. If the 'unit' is big enough to have an interface spec then a different dev should write the test. If you're doing function level unit testing, a dev should write it. There's a grey area between those two extremes. My original post was intended to focus on system and api level testing but I wasn't clear on that.
- marcus_holmes 6y ago
  I agree, there's a ton of grey areas in this whole field, especially around the borders between layers.

u02sgb 6y ago

I'd argue that while they can't "do" their own testing, developers should be writing Unit tests that prevent their code from being broken in future. They should also be writing tests that exercise their code so they find corner cases that were not obvious when coding. The problem is it's difficult to define what that is (and particularly to teach a junior Dev what to do).