Can working in QA for a while make someone a better developer/engineer?

Question

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

Answer 1

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).

Answer 2

To put it simply the overall answer depends on what you are looking to gain.

By working in QA you will likely learn the common (and not so common) mistakes that developers make. This will hopefully make you a better developer.

However, the question becomes, what makes your professor think that you would do well in a QA role and not just have a tarnish on your resume?

QA requires a different skill set than development, one that requires you to look at the project as a whole and not just in small sections. While focusing on your functionality in development is acceptable, focusing solely on a singular section in QA would be catastrophic to say the least. Also, it requires the communication and interdepartmental skills that Developers tend to lack in. (I can go on here but I don't feel the need)

Also, who's to say that you, like myself, don't end up just loving QA and realize that you can make just as much of a living in QA while having a less stressful more fun position?

Answer 3

As the world is going more and more towards Agile (Scrum) software development methodologies the need for cross-functional team members will grow. So having basic testing skills (at-least knowledge of best practices) is a great plus in my book for any team member.

Modern teams thrive on the use of test automation, which often is more development than testing. Thinking about what to test and how to automate it will make you a better developer, since you will learn how to build applications that are testable, which sometimes is a real afterthought.

I think this question gives more insight in the different perspective of a developer vs a tester: How does a tester's perspective towards software differ from a developer's?

Answer 4

Yes moving from QA to DEV will help in following ways

• I worked on a large enterprise product as a QA. In 2 years i was very much comfortable with the DB tables / data flows / functional knowledge. Setting up / Testing the system for several releases the product centric information was helpful to assist product managers, debug production issues. It was a vendor centric approach. After every release the Devs were changed. QA had the breadth of knowledge of the system
• I had requested for a role change. It was not possible due to several reasons (no open position, breadth of skills required). After few months one of the Dev's quit. It provided better opportunity as they had someone functionally strong plus met individual aspirations
• This resulted in a lot of learning technically. Being a QA, functional knowledge is critical. For a DEV able to quickly prototype, identify technical options for solution implementation. 50% you know the product, technically you will have a learning curve when you move to DEV.
• Moving to a DEV role for a new product is much more challenging as it requires both DEV & Product learning. Working across DEV, Test, Support functions you would understand the skills / daily challenges. This is much better than hearing about it. Cross skills is very useful as you move in your career. It would help you correlate the issues / look from different perspective. Overall it would add value / influence your decision from different perspective

Answer 5

Yes, if you work as QA, You can learn how to think like a user, learn or read user's mind, get an insight on what types of common mistakes devs make while building a software and also learn about common expectations that team/QA expects from developers.

Being a QA, the resource are tend to work in more directions, that to interact with software, the product or project team, with client etc, and by participating in this, QA are the ones that contribute alot to project's success and learn more.