How I connected QA and BA into one person

Lucija Drobac 4 min read

Once upon a time, there was a 10-year-old kid, and her name was Lucija. She grew up in a small town in the south of Croatia. One day a school teacher asked every child in the classroom, "What do you want to be when you grow up?".  
The kids said things like, "an astronaut," "a doctor," etc. But the girl dreamed about being a professional athlete and winning gold medals. I am sure you are already guessing. That girl is me.

“I want to be the best sports player ever!“

Now, 20 years later, my mom showed me that old paper where I wrote my wish. Firstly, I was surprised how she is still keeping the paper, and secondly, how my priorities changed over the years. I remember that no one of those children answered, "I want to work in an IT company and be an IT expert!"

People are occasionally asking me, "What do you do?" I am always trying to make a joke saying, "I am a messenger between the client and developers, and I am finding a needle in the haystack." While working with brilliant and talented people for the last year and the several years before that, I've learned that my dream is to be an IT professional. I surely didn't make a mistake switching from sport to IT. I was working as a Travel Agent and Finance Expert.

My decision to be a Quality assurance and Business Analyst came unexpectedly. It was a situation that opened to me a sea of new possibilities and showed me the proper path in my career. And here I am now, working as a BA and S(Software)QA in the company with the best energy and the most friendly atmosphere that I've experienced.

How does the QA and BA career path come together?

In the past years, both in the former company and in Q agency, our IT department employed more business analyst positions. Some came from the internal companies, some came from the external companies ... and from which department did most people come? The S(Software) QA.

My transition into the BA and QA position started years before actually arriving here. The story has begun with specializing for analysts' approach, at first as a financial analyst, but then evolving to the BA position. From experience (both successes and failures), I learned the critical importance of several things:

  • Know the values of your company
  • Do more
  • Be kind
  • Move Fast
  • Search for opportunities to train on testing tools
  • Mentoring is important
  • Be Agile
  • Understand requirements

QA vs. BA

The goal of QA is to ensure that testable requirements are successfully implemented within the developed system. BA uses its problem-solving skills to define the correct, testable requirements for the business needs. Both are striving to solve real problems.

Some activities that overlap BA with QA are crucial, and these are some of the points how BA can learn from a QA person and opposite:

  • Model and document: QA person is thinking out of the box to cover all user stories so that none of the edge cases are missed in the application. BA writes user stories that are shared with all stakeholders.
  • Translate Business Need: QA person is responsible for testing the overall system and a key person in STLC. He can predict that changing one module can affect some other modules. BA is working in the same direction more professionally.
  • Requirement analysis: BA person is also responsible for all requirement analysis, a QA person is also responsible for requirement analysis to some extent.
  • Testing and validation: In the end, QA verify all requirements of the application. And a BA verifies all requirements from a user perspective.

Therefore, connecting the work of QA and BA seems reasonable.

From my perspective, there are few benefits from having a QA/BA working almost the same job in your team, and those are Communication and Happy developers :)

Even though there are plenty of similarities, you can still find some differences. Without a doubt, one of the significant differences is dependence on others.

To clarify, when I work as a QA, and if I document, test well, pay attention to details, and put in the extra time when necessary, success follows. On the contrary, as a BA, you depend on the team. When you have problems and the project is behind, it doesn't matter how many use cases you have written or updated or how many meetings you have been on.

We would rise or fall together, and this is what I like, that we are all ONE TEAM. As a former water polo player, I learned how important it is to be a team player. When your teammates don't have a good day, there's always someone out there who will give more and help the team. Thus, I have learned how to keep my head above the water in any situation.

The best thing if you are working as a QA and BA is that you understand both sides of the job. Meaning, if I want to criticize the QA on my team, I stop and think instead about the problems I could face in his situation. It works fine, putting yourself in the other's shoes. I understand what they need to do with QA experience to reach the definition of done, and I can be honestly thankful. Always say "Thank you."

Thanks to my BA and QA background, the best thing I have learned can be summoned in this sentence: "I can admit that I don't get it. I don't know how to do my job perfectly. So I ask."

Last but not least - Remember, your end goals are the same.
A successful project is when the requirements are implemented successfully in the software. At that moment, the team won the gold medal!

I won a gold medal!