[Shenglong]

Question:

When you're doing QA on a product, do you worry about border cases? I found quite a few bugs related to time syncing and inadequate safeguards in a project I worked on - but they were difficult to reproduce without a macro.

I'm still not sure whether people were happy or angry with me, for reporting all those bugs.

[wnight]

The good devs would be happy because those rare bugs you found could take them months (literally) to track down from user reports.

One company I worked at had both buffer overflow and timing problems and didn't dedicate the time to fixing either properly so easily half the bugs we found were the same giant ones (and thus always ignored even if crash-level). This slowed us incredibly as you can imagine. The timing bugs could cause really anything and the buffer overflows prevented us from stuffing commands properly which kept us from ever reliably reproducing the timing bugs.

Eventually one of the lead devs fought through the backlog and implemented scripting into the product itself and we were able to get a much better handle on things through more intensive and repeatable testing.

These days I expect the developer has written specs for their code at the unit level. How else do they know what they claim to be delivering? So the job of QA (or, as I'd prefer - just another developer playing QA) focuses more on testing the stuff the weird stuff, edge cases, etc.

Automate everything. Writing a system to parse screenshots to decide if your windows drew properly is cheaper, and sooner than you think, than manual testing. Especially if you count the cost of bugs you miss through inattention.