Luckily they had lizards in stock.

Yeah, that's a huge success. Sure beats my spaghetti

You must have been lying close attention to see how they were triggered though.

Bug reports can be tough if you can’t repeat them. I’m glad you got some bonding time with littlie though, especially if you were on the clock.

To be fair, the team at the time was all business majors. (Is "Computer Information Systems" what they call that degree most places or just at my alma mater?) I think I was the only computer science major there.

They'd done a surprisingly admirable job of cobbling together a working e-commerce, loss prevention, customer sercvice portal, orderfulfillment, and CMS suite. And their schooling was in, like, finance, MS Office, and maybe one semester on actual programming.

None of them had ever learned how to count in binary. Let alone been exposed to 2's compliment. And there were no QA engineers.

Oh, there was the sysadmin. He had a temper and was a cowboy. If you asked him to do something, it'd be fuckin' done, man. But you did not want to know how he made sausage. The boss asked him to set up a way for us to do code reviews and he installed Atlassian Fisheye/Crucible on a laptop under his desk. We used that for years. And a lot of the business logic of the customer-facing e-commerce site lived in the rewrite rules in the Apache config that only he had access to and no one else could decipher if they did have access.

Those were good times. Good times.

That sounds strange. I cannot comment on your particular case without seeing the test artifacts.

Generally speaking, there is nothing wrong with tests that ensure bad input doesn't break the system, as this can easily lead to incorrect system states, damage to the environment, loss of data, money, reputation, and even lives - although most systems are not critical enough to threaten lives.

You wouldn't need QAs if you only needed to validate that the product meets the requirements. In a typical company, many people are involved in that process. This includes the developer who wrote the code, the developer who reviewed it, and the people who conduct acceptance testing, among others. If your developers produce code that doesn't meet the requirements, you're in trouble.

I'm not saying that QA shouldn't validate whether the system meets the requirements, but you don't want them to do just that.

Doesn't sound too weird to me. In my experience, devs always focus too much on positive / correct inputs, as they want things to work. Which is why you need testers that will catch all the weird crazy ways people can break things. Testers shouldn't even see the code of it can't handle nominal cases.

The problem is that testers are competent, often intelligent individuals. Users, not so much.

He was exactly the kind of guy who doesn't get hired any more because companies "know better".

And stuff gets crappier every year somehow.

A or B lol

look at product testing Andy over here

Orders a

Random alphanumeric.