Hi, i am aiming to switch from QA to BA.. after about four years of Quality assurance experience. I have studied a bit about analysis before, also i have worked with the various ERD tools in projects.. just need to know whats the basic mindset difference between a QA person and a BA, and how does one go about education ownself about BA role... comments will be much appreciated.
Good books would include: Seven Steps to Mastering Business Analysis and Software Requirements, 2nd Ed by Wiegers. Online training ranges from Inquestra to www.businessanalystbootcamp.com to http://www.VillanovaU.com (?)
Hi Jaffar,
At the high-level the QA analyst tends to focus on ensuring that the requirements or specifications have been implemented correctly by the system and this does not require a lot of problem solving.
The Business Analyst needs to "get under the skin" of the business, understand the requirements, questions the requirements, and work with the business to identify the real requirements as well as apply problem solving skills in order to design a solution which fulfills the requirements.
There are a number of companies offering training courses for the Business Analysts both at entry level as well as more in depth. Since you have no prior BA experience, I would highly recommend that you take some formal training. Check out our Training Course Directory.
Sincerely,
- Adrian
You've gotten some great advice already, so I'll just add my thoughts. Adrian is right, the BA role is much more focused on dissecting the business. But they are also responsible for handing off implementable requirements to the technical team. As a QA engineer you are in a great position to learn about business analysis. Hopefully you are able to participate in requirements reviews, often conducted by a business analyst or someone filling that role in your company. If so, this is a time to become a critical consumer of requirements. Try to understand the hows and whys of the requirements you are seeing. Also learn what makes a good technical spec vs. a poor one. Put yourself in the BAs shoes and evaluate what you are seeing.
If there are BAs within your company, you might consider doing informational interviews with them, sharing your career goals and learning more about the role. This will help you find opportunities within your company to get more involved in the requirements process or to understand how the requirements process works at your organization.
I also made the switch from QA to BA. In my experience the biggest mindset difference was the sense of what "done" means. In QA, "done" is usually fairly well defined. Something is done when it meets all the requirements (or the subset of those the team decides is good enough for release). As a BA, "done" is much less clear. Your role is about taking an idea or a concept in a very ambiguous state and creating a crystal clear definition of what "done" means for the project and then helping align all the various participants around this idea. Being able to handle ambiguity, negotiation, and facilitate communication is very important. As a QA engineer, you might do something similar when you find a bug that may or may not be desired functionality and you need to initiate a discovery process about the requirements.
Good luck in your transition to a BA career.
Best,
Laura
Hi:
Quality Analyst: The major thing that needs to be done is to determine the essential functions/processes accomplished within the scope of the system under consideration and - especially - how they interrelate. The analyst then, using such understanding, develops essential (i.e., technology independent) fucntional test cases. Then, suppliments the essential test cases with implementation specific test cases.
BA: The marjor thing that needs to be done is to determine the essential functions/processess accomplished within the scope of the system under consideration and - especially - how they interrelate. The analyst then, using such understaning, develops essential (i.e., technology indepentdent) functional requirements. Then, supplimnts the essential functional requirements with implementation specific requirements.
Notice: The main thing to be done is the same.
Tony
brought to you by enabling practitioners & organizations to achieve their goals using: