4 ms·

Surprised that people are finding this unusual, in web/mobile anyways. In my experience most engineers do some level of QA themselves, particularly in start-ups

by Xyik 11y ago

Surprised that people are finding this unusual, in web/mobile anyways. In my experience most engineers do some level of QA themselves, particularly in start-ups < 1000 people. In what ways does an engineer being their own QA negatively impact the company?

rifung 11y ago
Yup me too. At AWS we didn't have test engineers either. Everyone was responsible for testing their own code. We didn't even have SREs, so everyone was also on call. This just meant that everyone made sure they were writing well tested code before it got released because you didn't want to be the guy who made yourself, or worse, your coworker have to fix something at 3am. Of course I can see how this could be bad too, like if developers really dislike writing tests. On the other hand, the people who write the code seem best equipped to understand how to set up automated testing most efficiently.
- serge2k 11y ago
  > This just meant that everyone made sure they were writing well tested code before it got released because you didn't want to be the guy who made yourself ha, yeah right. What it really means at Amazon is build your service then bail for a new team before you have to maintain it. Exaggeration, but somewhat true. I have a friend there now who has an oncall rotation that's split into day/night. nighttime oncall basically means you are working graveyard this week. Of course that is really because that team should have a proper support staff, it's a vital service. Amazon, to me, is the epitome of a company that combines dev/qa/support because it's cheap rather than because it's actually good.
  - rifung 11y ago
    Well, I should have said that the idea is people would write well tested code before it gets released. I can also attest it didn't necessarily work out that ideally in practice. On the other hand, I'll disagree that they combine dev/qa/support because they're cheap. This actually makes little sense to me because typically QA roles are paid less than traditional software developers. That being the case, it doesn't make sense to get rid of them and let your developers do that stuff if all you want to do is save money. What I heard was that they used to have support staff but changed it because it wasn't working out. I wasn't there so I don't know if that actually happened, but I can see how it's both harder and slower to have someone who doesn't know the code base fix bugs on the spot. Honestly I can see it both ways. I think there are a lot of benefits to having the developers write tests themselves. On the other hand, when a project gets big enough, I can see how it makes sense to have people only working on tools like automated test frameworks or build stuff.
    - serge2k 11y ago
      > I can see how it's both harder and slower to have someone who doesn't know the code base fix bugs on the spot. Except you don't do that, you fight operational fires and other such bullshit and things don't get fixed. Their broken oncall system is one of the reasons why I don't want to go back to Amazon.
falsedan 11y ago
Mostly that you're asking the developers to become experts in software testing and verification, in addition to their existing knowledge. If you have good mentoring & examples & guidelines, then everybody can learn and move along roughly the same path. That takes time and effort to set up, so in those small startups you're likely to see wildly divergent approaches to testing + the friction when people think they should standardize, or when they actually do need to, or when people switch teams.
- grillvogel 11y ago
  I've spent years as both a tester and a dev. most devs think they are awesome testers because their automated test verified that the happy path works.
grillvogel 11y ago
because the person who wrote the code is not the most objective person to review it or find problems with it. automation doesn't cover everything, you need baseline automation testing as well as more focused manual testing.

by Xyik 11y ago

rifung 11y ago

Yup me too. At AWS we didn't have test engineers either. Everyone was responsible for testing their own code. We didn't even have SREs, so everyone was also on call. This just meant that everyone made sure they were writing well tested code before it got released because you didn't want to be the guy who made yourself, or worse, your coworker have to fix something at 3am. Of course I can see how this could be bad too, like if developers really dislike writing tests. On the other hand, the people who write the code seem best equipped to understand how to set up automated testing most efficiently.

serge2k 11y ago
> This just meant that everyone made sure they were writing well tested code before it got released because you didn't want to be the guy who made yourself ha, yeah right. What it really means at Amazon is build your service then bail for a new team before you have to maintain it. Exaggeration, but somewhat true. I have a friend there now who has an oncall rotation that's split into day/night. nighttime oncall basically means you are working graveyard this week. Of course that is really because that team should have a proper support staff, it's a vital service. Amazon, to me, is the epitome of a company that combines dev/qa/support because it's cheap rather than because it's actually good.
- rifung 11y ago
  Well, I should have said that the idea is people would write well tested code before it gets released. I can also attest it didn't necessarily work out that ideally in practice. On the other hand, I'll disagree that they combine dev/qa/support because they're cheap. This actually makes little sense to me because typically QA roles are paid less than traditional software developers. That being the case, it doesn't make sense to get rid of them and let your developers do that stuff if all you want to do is save money. What I heard was that they used to have support staff but changed it because it wasn't working out. I wasn't there so I don't know if that actually happened, but I can see how it's both harder and slower to have someone who doesn't know the code base fix bugs on the spot. Honestly I can see it both ways. I think there are a lot of benefits to having the developers write tests themselves. On the other hand, when a project gets big enough, I can see how it makes sense to have people only working on tools like automated test frameworks or build stuff.
  - serge2k 11y ago
    > I can see how it's both harder and slower to have someone who doesn't know the code base fix bugs on the spot. Except you don't do that, you fight operational fires and other such bullshit and things don't get fixed. Their broken oncall system is one of the reasons why I don't want to go back to Amazon.

falsedan 11y ago

Mostly that you're asking the developers to become experts in software testing and verification, in addition to their existing knowledge. If you have good mentoring & examples & guidelines, then everybody can learn and move along roughly the same path. That takes time and effort to set up, so in those small startups you're likely to see wildly divergent approaches to testing + the friction when people think they should standardize, or when they actually do need to, or when people switch teams.

grillvogel 11y ago
I've spent years as both a tester and a dev. most devs think they are awesome testers because their automated test verified that the happy path works.

grillvogel 11y ago

because the person who wrote the code is not the most objective person to review it or find problems with it. automation doesn't cover everything, you need baseline automation testing as well as more focused manual testing.