Dear fellow IT colleagues, I have thought many times about what interesting facts I would like to share with you from my professional experience and gladly, the answer was right in my face: depicting some stories about my life as a business analyst perhaps would offer you a priceless insight and support in your present-day work.
As all of you can imagine, professional support is always taken into consideration all across the industry. Just by simply searching it on different engines (e.g. Google), the term "business analyst" emphasizes the fact that professionals in this field are in high demand. A multitude of jobs are currently offered by many companies for business analysts, those who act as a liaison between IT and their clients" business needs. We, as business analysts, are trained to understand how technology can serve business goals.
Moreover, we, as business analysts, are in high demand both in public and private sectors. Along with these needs, come the following questions:
I have always been asked how someone could turn from a quality assurance to a business analyst role. Therefore, by reading this article, I hope you will gain an insight about this approach and of course you can ask me or other senior business analysts inside your company.
In the beginnings of my career, I started to work as a developer and tester. Afterwards, I was offered the chance of an interesting transition into business analysis. My first thought which comes into discussion is a hallway discussion. A senior business analyst on the team approached me one day and mentioned a new position was opening in the department. I was advised to apply.
As a normal reaction to a possible change, I thought: " ok, this chance sounds like an interesting turnover, it might be a good moment for a change". After giving some days of deep thought about whether or not moving into business analysis was really a good career move for me, I acted on my colleague"s advice and applied to this position. As an immediate consequence, I found myself moving from one team to another.
Of course, on real grounds, the transition process into business analysis did not begin just simply by changing teams and domains. I am sure that all of us had been unknowingly approaching their QA role as an aspiring business analyst.
In what follows, I would like to depict what I now consider to be the fundamental activities that helped me demonstrate I was ready to be a business analyst.
At a high - level the QA guy 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.
Working as a business analyst means that someone needs to get under the skin of the business, understand the requirements, question 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 fulfils the requirements.
From my side, as a QA specialist (engineer) someone has the possibility to be in a favourable position to find out more about the field of business analysis. Hopefully, you are able to participate in requirement reviews which are usually conducted by business analysts or someone filling this role inside your company. If so, this is a time to become a critical punter of requirements. In addition to the above mentioned facts, try to understand the hows and whys of the specifications you are seeing and learn what makes a good technical requirement versus a poor one. Simply put yourself in the business analyst"s boots and evaluate what you are observing.
By taking into account the fact which tells me that there are for sure business analysis fellows within your company, you should take into consideration the chance of performing knowledge interviews with them, illustrating your career targets and finding out more about this role. Discussions like these would increase your chance of being more
involved in the requirements process or gaining information about how it functions in your organization.
Jumping from quality assurance to business analysis does not sound impossible. In my opinion the major belief metamorphosis was the sense of what completed tasks mean. In quality assurance, things are considered accomplished when they meet all the requirements (or at least the subset of those the team decides are good enough for release.) In business analysis, completed is much less clear. As a business analyst, you have to take care about an idea or concept in an equivocal state and then to induce a sparkling definition of what "accomplished" means for the software project. As a next step, as a business analyst, your job is to bring into line all the stakeholders around this idea. Being able to handle vagueness, cooperation, and facilitate communication is of uppermost significance. From a QA perspective, you might proceed in analogous manner when a defect is found that may or may not be desired functionality and you need to initiate a detection process about the requirements.
Can everyone act as a business analyst? Actually, there is no hard and fast canon. Business analysis specialists lean towards to coming from an educational background in economics or transition into the role based on a technical agreed path that gave them satisfactory domain knowledge to specialize in an area of the business. At some point in evolution, a business analyst might develop sufficient experience to handover those abilities to diverse operational extents or project types.
Do not forget, as a business analyst it is very important to understand key items & actions:
Good luck in your transition to a business analysis career!
P.S. Next article: Testing & Business Analysis
by Ovidiu Mățan
by Dan Suciu
by Ovidiu Mățan
by Sorina Mone
by Ovidiu Mățan
