Dreaming Of A Business Analyst Career: A Personal Journey From QA To BA

As a six-year-old kindergartener, my school teacher asked every child in the classroom, "What do you want to be when you grow up?"

She took the answers and made a little book for us to take home for our parents. The kids said things like, "an astronaut," "a doctor," "a teacher." I wanted to be like my dad so I answered, "I want to be an operations vice president."

I pulled out that old book the other day and read through all of the answers. You just won't believe what I found.

Not one of those children answered, "I want to be a Business Analyst!"

We BA's are occasionally asked, "What do you do?" I try to make a joke out of this innocent question by replying, "Well, what would YOU do with English and writing degrees? I'm a Business Analyst of course." People don’t laugh.

It's not because they don't want to make fun of an English major, it's because they don't have a clue what a Business Analyst does. You can't laugh at a joke if you don't get the punch line.

It's true though, isn't it? Growing up to be a Business Analyst is not a dream that you've envisioned since childhood.

However, since working with bright and talented computer folks for a decade or so, I've learned that it is a dream for many professionals to find their way into a career as a BA. My decision came when I spent several years working in software testing. That position in Software QA eventually migrated into a career as a BA.

Why the QA to BA career path works.

Over the last several years, our IT department has gradually budgeted to create more and more Business Analyst positions. Two new hires came from external companies. The other five were internal transfers . . . and which department did most of those come from?

That's right: Software QA.

Is that typical in other companies? What reasons might make it a likely career path?

My personal transition into the BA position started years before actually arriving. It began with choosing a way to approach the Quality Analyst position. From experience (both successes and failures) I learned the critical importance of these five things:

1. Know your company offerings. . . just the way you know the layout of your own bedroom in the dark. I was fortunate to have worked in three different departments, including software testing, all the while absorbing and refining an understanding of our specific products, systems, processes and services. That's great transferrable knowledge.

2. Develop a strong rapport with stakeholders . . . You know, I found that the more I listened, the more I learned (Did Yogi Berra say that?). I tried to listen and learn on each project I was involved with, and each project gave me an opportunity to work with many of our stakeholders.

3. Search for opportunities to train on testing tools. . . after you become proficient. When coworkers would ask for help we would set things up together, creating positive relationships with different QA team members, upon whom we would later depend.

4. Pursue personal training opportunities . . . on almost every aspect of software testing. Initially, I didn't even know how to write SQL queries - so I needed help. Being able to ask and accept help, then understand and execute are foundational BA skills.

5. Be Agile . . . Participate in sprint planning meetings and help define user stories. Become a sought after resource for successful projects. Engaged, "agile" team members found more success in meeting deadlines, budgets and scope requirements

Okay, so those are a few examples from my work experience, which proved preparatory for a transition into a Business Analyst career. But I left one off of the list. Why? Because, as I spoke with others who have followed a similar career path, they too, listed this next element as their big reason for the change. So what is it?

The underpinning for considering a transition to Business Analysis from software QA is: you deeply understand REQUIREMENTS. Savvy Business Analysts know that they need to define SMART requirements, and they know how to do it! SMART, in this context, stands for Specific, Measurable, Achievable, Relevant and Testable.

The goal for QA is to ensure that testable requirements are successfully implemented within the developed system. Business Analysts use their problem solving skills to define the correct, testable requirements for the business needs.

Both are striving to achieve robust systems that solve real problems while working from different angles with respect to the requirements. A move, therefore, from QA to BA seems reasonable.

There are plenty of similarities, now what about the differences?

For some QA's, BA is not their cup of tea. I became concerned shortly after my transition because of the immediate awareness of a major divergence.

Initially, I took the job because of the similarities previously discussed.

But I became self-doubting because of this difference: dependence on others.

In software testing, it was all about individual competence and commitment. If I documented well, tested well, paid attention to detail, put in the extra time when necessary; success followed. Much of the accomplishment for QA depends on the individual.

But as a Business Analyst, one quickly learns that if a project was behind, it didn't matter how late you stayed on a Friday or how many use cases you wrote to try and further define what we were already working on. If we fell behind in development or testing, accelerated performance was now dependent on the team. We would rise or fall together - not rise alone on the results of a single person.

How does it feel to go to work every day and depend on the performance of others for your success? Could I be happy and thrive under this new paradigm?

Developing rapport with team members.

An adjustment in my relationships with others was necessary, after reading Dr. Steven R. Covey's book, 7 Habits of Highly Effective People, the principle of "seek first to understand, then to be understood" was reinforced.

It's a habit that helps you become a better listener, a difficult skill to be sure. But I've added a phrase to that quote. My version reads as such: seek first to understand, then to show that you understand, then to be understood.

Perhaps this might help me with my new definition of success.

Take a minute with me and remember when we were kids again. I wanted to be a vice president of operations at my dad's company. You wanted to be an astronaut. Okay. We're sitting in class and the teacher is explaining an assignment, but it isn't clear to you what is expected. Do you raise your hand and ask her to explain again? Or do you worry that Johnny, sitting next to you, might tease you and call you "stupid" for having to ask for help?

My childhood classmates teased the kids who raised their hands and said, "I don't get it."

As an adult, I still hesitate before raising my hand in a meeting to say, "I,m not following."

But, I'm learning to get over it as I seek to show that I understand.

It's important, as a Business Analyst, to show that you understand key items:

• Requirements,

• Business rules,

• Functionality,

• Commitments,

• Goals.

And do you know what happens with my relationships with my coworkers when I ask questions, repeat what they've taught me and show them that I understand? They appreciate it. It feels good to be understood. And then, they want to work a little extra to get the project done so they can help me out.

QAs and BAs stepping on toes.

The first week in my new job, I was learning about the application for the project I would be working on and wanted to read the test cases. I opened the web-based application that I had used to document test cases for my projects and went looking for my new application. It wasn't there

Immediately, I wanted to go and tell the QA on my team he was doing it wrong. I wanted to ask him, "Why aren't the test cases in here? Why don't you do things like I do?"

But I sat on my hands for a few minutes. After that urge faded, I instead opened up the help files and read through that documentation to learn the new application. It worked fine.

What's the point of sitting on your hands as a new BA? It's no longer your place to tell the QA how to do their job.

I learned that there are other approaches to successful software testing besides my particular approach and a different approach was what worked best for my new project team member.

I had to watch out for stepping on his toes. I didn't expect him to tell me how to write up use cases and he wouldn’t have appreciated me leaning over his shoulder telling him how I used to test software.

It is important, instead, to follow a best practice: show the QA department that you appreciate their work. With past experience as QA, you know what they’ve had to do to reach the definition of done and you can tell them thank you and mean it. It's a good practice.

Say thank you.

How I switched from QA to BA.

The story of my journey to become a Business Analyst really started when I was in college and ran out of money. I spent the next semester working full time and taking one class to keep my status as an enrolled student. Initially, it was incredibly frustrating to have to put the brakes on my education. I was anxious to finish my degree and enter the real world. But being forced into that semester of work was one of the best real-world preparations I could have asked for during my college years.

Not only did it give me the money needed to go back the next semester, but it also gave me contacts. I didn’t realize that during that semester, I would start networking with professionals. To me, it was just a coworker who had more experience than I, but during the lunch hour, we were simply friends enjoying a bite to eat.

Several years later, as I finally did finish my English degree, I began my job search. As I submitted resumes to plenty of companies on Monster.com, I also called up two of my old coworkers.

Through one, I started a job with a small company where I had a chance to help with their website development.

But within a few months, the other former coworker sent me information for another job with a bigger company (more money and more benefits) that, thanks to even the few month’s experience with the small company's website, I looked like a good candidate for the position.

And that's how I got my foot in the door at my current company.

I tried to take advantage of every opportunity given to me. I networked with shareholders, supervisors, and coworkers, accepted every project they gave me and often looked for opportunities on the big, scary projects. Bigger risks, bigger rewards, you know.

I also wanted to make use of the tuition reimbursement and took that tiring test, the GRE, and got myself into a master's program at a nearby university for a technical writing degree. At the time, I didn’t have my sights set on the Business Analyst position, but looking back, I can make a simple list of the experiences that set me up for my current career:

• I developed positive working relationships with both IT and business personnel

• I worked on a number of different software development projects

• A number of those projects came with big risks that I learned to manage and overcome

• I learned how to resolve problems ensconced within production software

• I had hands-on experience with many of our software applications

• I could write technically

• From multi-million dollar to several thousand dollar projects, I'd been involved from start to finish

• With each new software project, I learned new processes

• I was gregarious and engaging by nature

• I confess being a little obsessed and driven

Okay, now that I've made my personal list, I feel like I’ve just had an interview with you and I'm trying to convince you to hire me. Did it work? What type of experiences would you put on your list that makes you the ideal BA? What does it look like I need to work on?

Best Practices Learned Along the Way

Thanks to my QA background, there are several best practices I have learned to focus on as a BA.

First off, I can admit that I don't get it. I don't know how to do my job perfectly. But I have a lot of resources in my coworkers. So I ask. It's a simple act, but if done right, it can help you get rid of your own stumbling blocks. Nobody likes to admit that they don't know something so it can be daunting to ask. But take heart by reading Samuel Butler's confession in Note-Books: "I was nearly forty before I felt how stupid it was to pretend to know things that I did not know and I still often catch myself doing so." Asking for help does three things for you. First, the obvious, it gets you the help you need. Second, it helps you realize that you have a social network that supports you-as Benjamin Franklin said, "If you want to make a friend, let someone do you a favor." And last, you boost other people's happiness by giving them an opportunity to do you some service.

The second practice I've learned is, don’t forget the QA department. At our company, I've heard the Software QA supervisor voicing her frustrations that the development teams do not inform QA early enough in the process. Having come from that team, I try to get QA input from the start. It only makes sense. They have requirements expertise so why not get them involved when you're starting out with the requirements? Every project needs QA from the beginning to help the teams start on the same page and feel like a team. This gives QA enough time to set up the testing environment and configuration.

The third practice: remember your end goals are the same. A successful project is defined the same by both QAs and BAs. When the requirements are implemented successfully by the system, a gold star for everyone on the team!

Last, I've learned that it's not for everyone. I was nervous that it might not be for me because I was unsure that I would be able to depend on others. Successful BAs have certain personality traits that successful QAs may not necessarily have. Examples include effective oral presentation skills, ability to be social and engaging, and strong diplomacy and negotiating skills. If those are part of your natural work persona, business analyst careers are right up your alley. Bring on the competition.

Author: Lauren Elkins is the only IT Business Systems Analyst at ARUP Laboratories with a titanium toe. She previously worked for ARUP as a Software QA Analyst where she learned about what a BA does and that she wanted to become one. Today, she continues to learn BA skills and gets a kick out of the personalities of the Programmers that she works with as they build laboratory-specific software.

Article image © Arcady - Fotolia.com