4 ms·
As someone who's been working in the industry about 20 years now, I agree with some of the points. I don't agree with the attitude toward testing. I worked at
by allenu 5y ago
As someone who's been working in the industry about 20 years now, I agree with some of the points. I don't agree with the attitude toward testing.
I worked at Microsoft for about 12 years and when I joined I was an SDET (sort of a dev who does testing). I honestly found it strange that there was a separate role to test code that was written. It just seemed so wasteful. There were strict "QA testers" as well, but they worked with the finished product as opposed to writing code that tested other code.
When I finally switched to the dev role at the company, I would routinely see other devs writing code and throwing it over the fence to be tested. Testers would find an issue and then throw it back. Many of these bugs were such obvious things that could go wrong to me that it was clear the developer didn't take 5 minutes to try scenarios other than the happy path.
I do think you can go too far with TDD and unit tests and that often they are more trouble than they're worth to set up and do prevent you from moving more quickly. Often, you don't know your problem space well enough to start planning your tests. However, it's a very old school attitude to think that you can just rely on QA to do testing for you. It may have worked in the past, but only products took longer to release and there was a smaller audience for what you did.
- GeorgeTirebiter 5y agoI revered my testers in those days. When they found a problem, I had to ask myself: "How did I miss this?". I'd identify how that happened, and made a note as to how to eliminate that class of error in the future. It is a mistake, I claim, to not have professional FW/SW testers anymore. I fail to see how having a parallel set of professional testers adds delay to product release -- except insofar that the testers find bugs that end users will subsequently never see - and that's the point!
- scotty79 5y agoMe too. That was pretty much the only condition when I was looking for a job. Who does the testing? If the answer was "developer", or "everyone" I knew that they don't have a person who's responsibility is testing and that was very bad sign because I knew second pair of eyes responsible for looking at your output is worth their weight in gold. Being a great tester requires very different set of skills than being great developer.
- hinkley 5y agoThe over-under on good testers versus bad ones is at least a factor of three wider than good versus bad developers. I think a lot of backlash on QA is based on worst case scenarios. At a company that didn’t have remote workers, we let one QA person work remotely because she was that good at her job. She was finding more bugs than the next two people combined, and we had three people we considered to be “good”.
- jaywalk 5y agoAs a developer, your job is to develop the software. Yes, you should be testing the code you write as much as reasonably possible. But since you wrote the code and have been working with the code very intimately, it's so easy to develop blind spots that might be obvious to a someone else but you just don't see because you hadn't considered it. That is why it's so valuable to have dedicated QA testers.
- vagrantJin 5y agoThis is the truth. A developer is too close to the fire. I don't know how many times I've missed some simple thing, even in HTML that someone else spots in a few seconds.