Hacker News Reader

Comment by Google234 | Hacker News Reader

I believe that engineers should be responsible for testing the code they write themselves.

Engineers SHOULD be responsible for testing code they write themselves.

Which has absolutely nothing to do with the need for QAs to test as well.

At the very least there is a completely different psychology required in testing, where the goal is to break things, but when you are the person who has created that thing there is sub conscious resistance to breaking things too much.

> when you are the person who has created that thing there is sub conscious resistance to breaking things too much.

Definitely this. I'm primarily a developer, but while I can do a good job of QA on someone else's code, I find it almost impossible to do a thorough job on my own.

For me I think the reason I can't do a thorough job on my own code is down to a combination of two reasons:

1) Testing my own code is boring. I keep thinking about what it should do and then taking shortcuts where I don't test every possible circumstance because I believe I can infer what will happen in one case from another.

2) Testing my own code is time I'm not spending working on the next bit of code in my queue. At a certain point I start feeling like I should just be working on the next thing

For me, I think it's partially that I have too many preconceptions about how the code will be used. I still have the implementation in mind when I'm testing. Whereas good QA will be naive and test things that the dev might not have thought of.

That only works for extremely simple projects with very small teams working on "hobby projects". For anything serious you need an independent and professional QA team which essentially does nothing else than trying to break the product all day in and out.

Programmers should be required to do enough local testing to not break the build of course, but the same person who wrote the code can't also thoroughly test it, because they'll inevitably only test the "happy path", even if they don't intend to.

There comes a point though when theres too much QA that seriously hampers development and progress because they turn the smallest change into a year long shitfest of "hold on we are testing!". Microsoft for awhile got a bit heavy on QA, unforunately they also went full retard the other direction.

I wonder how Google, MAFT, and Amazon do anything more than hobby projects!?

How do you imagine that scales for an operating system the size of Windows ? Every time you check in code you check against each of the 2000 printers released in the last 20 years ?

Maybe they should be, but the record shows that Microsoft engineers aren't doing as good of a job testing their own stuff as Microsoft engineers in test were doing.

Is the cost savings worth it? For Microsoft, I don't know. It depends on how much brand damage they make with this. Apple has its own desktop OS value destruction process, and Google is killing off Cloud Print for its desktop OS, and replacing it with hope and dreams (hope and dreams only available if your chrome device still gets updates, but the windows cloud print server is already gone from windows chrome)

They should but then big projects also need an additional testing team. Especially for something like Windows, there are too many possible variations for a non-dedicated person to test all of them.

I try to be thorough, but at some point I have to write code other than test code. For systems with a lot of emergent complexity, it's possible I've covered 9 of the 10 paths, good or bad, and missed one bad one.

They are and they do, and this is what you get if your testing and QA plan is limited to that.

Reply on news.ycombinator.com