3 ms·
> Fire manual QA team and hire people to write automated integration tests. From experience, this leads to coders coding-to-the-tests. It compiles, it passes,
by dingaling 10y ago
> Fire manual QA team and hire people to write automated integration tests.
From experience, this leads to coders coding-to-the-tests. It compiles, it passes, ship it. Does it doing the right thing under stress? Who knows.
Manual QA staff, proper QA staff, do crazy non-linear things that stresses code like customers do. I'll bet they would have caught that bug in the other front-page story about the animal feeders failing without an Internet connection; I had a tester who pulled-out the cat5 on many occasions.
I think I've said it before: automated tests are the entry test to the QA process, not the exit diploma.
- brianwawok 10y agoSo you talk a lot about stress testing. There is 0 reason developers can't code stress testing and add as a step in the release cycle. You know why this never happens? Performance is never a requirement, almost always an afterthought. How many specs list required throughput or 99.99 percentile latency? No one cares about perf until it's bad. So if we fix that, put in the spec... We can automate perf testing and perf monitoring. Sure have a perf team code this. But I don't need a QA guy to run a perf test for me.
- stestagg 10y agoIt's not that, so much as manual testers will /notice/ that code is slow, and ask questions about it, whereas automated tests will run the script no matter what (unless someone thought about it in advance) Likewise, you /can/ code an automated test to simulate sudden network loss, but a human will just randomly decide to try it, without someone pre-programming him