I assume you mean QA Analyst, as opposed to QA Engineer. To me the main difference is that QA Analysts don't write code, where QA Engineers do write code. If you enjoy writing code, you should try for a QA Engineering position.<p>I was a Quality Assurance Analyst at a large financial services company for a few years. I can't say how different a gaming or analytics company would be, but I think most large software companies will be similar. Personally, I'd stay away from QA positions at large companies, as I found I was trapped in a specialized testing area that limited my ability to learn new skills.<p>QA's need good analytical skills, to know where to look for bugs, and judgement to know how severe a defect is. Good communication skills, particularly writing skills are critical. By writing skills I mean the ability to write clear descriptions for developers, and clear steps for them to reproduce issues. I ask specific questions in interviews to find out if a candidate for a QA position can clearly explain a 5 step process.<p>QA's typically write short descriptions of their test strategy for the code they're testing and discuss the plan with the developer who wrote the code and other QA's. It's better when these docs are clear and understandable. Non-agile teams usually require QA's to write documents listing all of the tests they plan to run, even if they never check that you actually run them. Agile teams usually eliminate this kind of busy work.<p>As a QA I spent a lot of time explaining the app and functionality to the rest of the company, including managers, directors and VP's.<p>QA's need good soft skills, they need to learn about other parts of the business to understand the customer the company's trying to reach. Often the design given to developers is missing requirements, a good QA can find those requirements early and save the team time reworking code later. Often QA's need to coordinate testing with other QA teams, integration points are where software always breaks!<p>QA Analysts on my team spend the majority of their time either running manual tests, or using software that permits them to automate my company's application. We have a team of automation engineers, Quality Engineers officially, who write and maintain tools and testing frameworks that allow non-engineers to create automated tests. Our automation team wrote a scripting language for Selenium WebDriver to permit easier automation of browser controls.<p>Since my company's application is a web app, many of the tools they use allow viewing and tweaking web requests. Here's some tools the QA's use daily:<p><i>HTTP Analyzers and Javascript consoles</i><p>* Chrome and Safari Developer Tools<p>* IE HTTP Analyzer<p>* Firebug<p><i>Monitoring Software</i><p>* Computer Associates APM (Server Monitoring)<p>* Splunk (Log Monitoring)<p><i>Test Case Management</i><p>* SilkCentral (I hated this app, slow and inflexible)<p>* Microsoft Excel (for writing tests)<p><i>Agile Management/Bug Tracking</i><p>* Rally or Jira<p>The QA's on my team who could manipulate the Linux command
line, create simple Bash scripts managed deployments to QA and Performance environments, and tested some of the application's backend components.<p>I took programming classes at night, and as quickly as I could I found a QA Engineering position at the same company. Since I had little programming experience, my experience as a QA Analyst was key to getting a QA Engineer position. A QA Engineer with a solid understanding of what and where to test is very valuable to any company.<p>If you don't want to code, Quality Analysts often move to Program Management, or become Scrum Masters or people managers.<p>You didn't say if you're applying for a Quality Analyst position. If you are, Good luck!:)<p>edit: cleaned up formatting