4 ms·
> Either they don't sufficiently understand the problem scope, they're overworked, or they're just lazy and don't bother running through enough of their own qu
by ericb 17y ago
> Either they don't sufficiently understand the problem scope, they're overworked, or they're just lazy and don't bother running through enough of their own quality controls before releasing changes.
The number of possible system states in larger systems can be enormous. I feel like to have this opinion, perhaps you have worked mainly on smaller systems? In larger systems, there can be so many possibilities that it would take several times longer to test than to code, and without reading spec docs, it is very difficult to tell what correct even is. For example, a student loan system I worked on fit this bill. The glib answer would be to say it was so complex because of poor programming, but that's not true. The legal reality it was modeling was complex and so the software could not be less complex than the underlying system's rules. I have worked on several such systems in different industries.
Now, you could argue that all programmers should become programming/QA people, but that would be self-defeating as programmer time is generally more expensive per-hour than QA time. Further, the type of person who is good at running through 400 steps of detail-oriented rote testing is not always the same person that you would like doing high-level design. Specialization makes life more efficient. Even if they did happen to be the same person, if they enjoyed one task more, why wouldn't they go to a job where they could focus on that type of task?
- run4yourlives 17y agoI feel like to have this opinion, perhaps you have worked mainly on smaller systems? No, I've got a good mix, and I agree with you that this is a product of large systems more than simple web apps and the like. The complexity of large systems being required is what's the problem though; not that I have an immediate solution. That and too many programmers that simply aren't able to do anything but program.
- derefr 17y agoYou can't say that complexity itself is the problem, because the whole of programming is encoding complex processes so as to simplify them from a human perspective. Without complexity, it's not testing that would go away, it's programming. You've basically said something like "the problem with space shuttles is that they have to aim their thrust precisely in order to achieve lift"—that's not the problem with space shuttles, that's the idea of space shuttles.
- run4yourlives 17y agoThe problem is that everybody likes to think their problem is as complex as a space shuttle. The reality is that in 99% of cases, it isn't. In have of those you are 100% correct - the problem isn't even a programming one.
- nostrademons 17y agoFWIW, I work on Google Search, possibly the largest software system on the planet, and Google is famous for being tester-light and automation-heavy. We rely much more on code reviews and on having good engineers who aren't rushed than on testers. The reason is just as you state: beyond a certain point, the number of states in the system becomes so great that you simply can't test them all. Replacing developers with testers doesn't change that. So you're better off understanding what you're doing than trying to avoid all the possible ways that you could go wrong.
- ericb 17y agoAutomation heavy is a good thing in my book. I think whether the developer writes it is often a function of what you're testing. For example, WinRunner has its own learning curve, and so seems to be left to QA more often. Whereas Selenium seems to have a smaller curve. Generally though, I like the idea of someone else proofreading my work, because for the same reason that I forgot to account for a set of inputs, I will tend to forget to test with those inputs.