Can working in QA for a while make someone a better developer/engineer?
I was just wondering what type of skills gained in QA would help someone become a better software engineer/developer (if any)? I was talking to a fellow intern, and he told me that some of his professors suggested he start out in qa first after graduating. The way he described it, it seemed like his professors suggested that would help him gain a solid foundation to become a better software engineer/developer in the future. Was wondering what everyone's inputs are
Professors make this suggestion. I suspect many of them don't actually know what a QA career entails since most of the professors I know are a bit divorced from the world of business. For more information, I'd suggest reading this very similar question (Fundamental Requirements For an Entry Level QA Engineer) and my response to it. Some specific skills that test folk often have where programmers often don't: Implicit requirement discovery. Most programmers tend to be more analytical and literal-minded. This isn't a flaw - it's necessary to build good software. Testers are more inclined to look at a requirement and build out to the associated unwritten requirements that are implied by the explicit requirement (such as: if you're not going to permit certain values to be used by an application, you also want to prevent them being saved in the first place). Equivalence grouping. This doesn't usually even register for a lot of programmers - they're generally looking to make the software work according to their understanding of the user requirements/specifications/user stories. Testers are more likely to look at classes of possible input and then test the software to see what happens with different types of valid and invalid data. "Negative" testing. Testing to see whether the software behaves in a reasonable manner when given bad data, when it receives unexpected input, and so forth are things that testers typically do once they've satisfied themselves that it handles the expected kind of data. I don't actually consider this kind of testing negative - it's just another set of equivalence classes. Programmer tests tend to be much more focused towards the expected behavior. Case prioritization. In any non-trivial software, the number of possible tests (and therefore scenarios or paths through the application) quickly becomes unmanageable due to the joys of combinatorial math. Testers learn to prioritize and group these so they can cover as many likely paths as possible in the time they have available to them. Programmers tend to be more inclined to stick to one path and - because they rarely have the broad perspective that testers get - may not be aware of other paths. User impersonation. Also known as Telepathy 101 - testers are often in the position of Speaker to Geeks (or Speaker to Normal Humans) - they translate between the way programmers tend to communicate and the way end users tend to communicate (this should not be confused with Speaker to Management, which involves a different language altogether). Programmers tend to value control over simplicity (in the USA, programmers are more likely to prefer to drive cars with stick shift than cars with automatic transmission, for instance), to place a lower priority on user interface ("it works. It can be prettied up later" - if I had a dollar for every time I've heard a variation on this I'd have a lot more money than I do now), and so on. It goes with the kind of mindset that's capable of programming. Testers have to translate between that mindset and the mindset of the people who will be using the software. This isn't anything like an exclusive list, but all these skills will help a developer build software that's more likely to be accepted and liked by users - which is the ultimate test of quality for most of us (caveat: software that's used in situations where problems can kill people has a different set of requirements - but it's not what most developers and testers are working with).