Skip to main content

Author: Kimberly Yoss

Become a Better BA: Study History

As a business analyst or someone aspiring to be a business analyst, do you seek out better understanding in your daily life as well as at work—exploring the angles and the what-ifs?

I think many business analysts have a mindset to explore and uncover truths that others might not.

Let me share a recent related experience.

 

During a trip to France several months ago, I crowded into the museums amid the other tourists. Despite the bustling, I re-connected with the beauty, the feeling of inspiration, and the magnificent presence of the best works of art in the Musee d’Orsay, the Claude Monet House in Giverny, and the Dali Museum.

I noticed something was different this time.

Moving mindlessly with the flow of the other tourists from one piece to another felt flat and meaningless. Most tourists approached each piece with a camera first, skimming the surface with a click and a view, posting to social media, and then turning attention to the next piece.

I wedged myself in to get closer as I listened to the audio guide. Skimming was not what I was here for this time. I was hungry for the history of each piece: the background of the artist and the details of the time and place in which the piece was created. Give me history, context, and the human perspective.

 

Learning and embracing history has quite a few benefits for building on context, scope, and possibilities.

  • It fosters knowledge and deeper understanding, contributing to a broader perspective.
  • It exposes multiple details associated with an event, which helps improve understanding.
  • It establishes connections between events (even seemingly unrelated events).
  • When expressed like a story with characters and settings, it improves comprehension and retention.
  • It can provide a base for drawing conclusions and, therefore, applying learning.

That trip to France has ended. The journey to apply the art of historical understanding to the challenge of business analysis is ongoing.

As CBAPs, we look to BABOK for guidance in our work. We use it to provide the pillars of understanding needed to do what we do in the best possible way.

Wouldn’t it be cool if we could tap into a fresh methodology that has the power to augment the resources in BABOK?

…and in walks history. You thought you wouldn’t need it after college, probably even after high school, right? Let’s explore this.

To study history effectively, one needs to engage in most of the following tasks:

  1. Take a chronological account of events and tie them together with other events.
  2. Be able to distinguish what events lead to other events to establish cause and effect.
  3. Be able to make connections between seemingly disconnected pieces of information.
  4. Keep track of the players and how they affect the events.
  5. Identify and extract the key information.
  6. Gather related information to fill in the blanks to build a more complete picture.
  7. Apply critical thinking to assess your own understanding.
  8. Be able to apply and project your own understanding based on the facts.
  9. Do not be afraid of research or large quantities of information.

 

An effective business analyst needs to be able to:

  • take in a tonne of seemingly disparate information.
  • research and uncover additional information.
  • Talk to many different people.
  • synthesise all the information.
  • put it into context (many times we have to build an entirely new context from all the information!)
  • …and then be able to express it in a way that multiple groups of people will understand it and be able to draw conclusions from it.

We look to BABOK for guidelines on how to approach this process.

If you study history, you are honing skills that BABOK teaches. In effect, you have another tool to become a better analyst.

History is usually presented as a set of sometimes-chronological facts that you need to piece together and tie to other facts. From this, you can determine cause and effect to get a bigger picture of how different events are related (represented by #1 and #2 stated above).

 

Advertisement

 

Think about the BABOK task “Conduct Elicitation.” The purpose of this task is “to draw out, explore, and identify information relevant to the change.” The task has three types: collaborative, research, and experiments, all of which rely on gathering and organising usable information and facts.

The BABOK task “Analyse Current State” contributes in a similar way. This task’s purpose is “to understand the reasons why an enterprise needs to change some aspect of how it operates and what would be directly or indirectly affected by the change.” The inputs to this task are elicitation results, and they include elements of external influencers, organisational structure, and culture to support the analysis.

Another parallel I find interesting is between #7 and #8 above and the BABOK tasks “Analyse Potential Value” and “Recommend Solution and Recommend Actions to Increase Solution Value.” You must be able to absorb and synthesise the information and come up with your own understanding, so you can use that understanding to build context and perspective for future understanding. In the two BABOK tasks, the purpose is to “estimate the value” of multiple options (or courses of action, in the case of the “Recommend Solution” and “Recommend Actions to Increase Solution Value” tasks) and determine which best meets the requirements of the enterprise based on the information available.

 

Finally, I find a parallel between gaining a deep understanding of the players in history and the need to know our stakeholders in business analysis (represented by #4 above). A deep understanding of the stakeholders is so important in business analysis that it is a core concept in the Business Analysis Core Concept Model, integral to every knowledge area in the BABOK. You cannot completely understand your project and cannot design a solid solution if you don’t have a strong handle on who the stakeholders are, how they are connected, and what they need.

Same in history. You understand the Impressionist era much less if you don’t know that Monet, Renoir, and other painters during that time period actually worked and played together.

For the passionate and effective business analyst—as well as for any history buffs reading this—I think it comes down to being curious, being structured, and doing your research.

The Dilemma of Test Scripts

Mention software testing to 10 people in IT and you will get several different responses.

“That’s what QA is for.”

“Unit testing covers what we need.”

“What do we need to test for? The application works fine!”

“We’re Agile. We don’t need to test.”

“The client’s not banging down my door – so all is good.”

“No, we can’t release to UAT yet. I’m only halfway through writing the test scripts.”

“I don’t have time to test.”

“I don’t know how to test this. I’ll need some guidelines.”

“That’s not in the budget.”

If you work as a BA in an IT department, you have likely heard all of these retorts – sometimes even from those who should know better.

 

It is also a trigger that can lead down a deep rabbit hole of shortcuts and excuses, with the ultimate result being sloppy code, error-prone software, and possibly tons of rework post-release. Not only impacting you and your team, but also potentially leaving your company with very unhappy customers.

Software testing has several variations, all meant to ensure that the customer is happy in the end and that fewer issues, or bugs come back to haunt the product development team. Unit testing and smoke-testing are two of the most common types of testing. Unit testing is ordinarily done by the engineer as a part of coding and is meant to test the individual functions of the various components of the specific software. Smoke-testing is done after the release of the code into production. It serves as a means to make sure that nothing has been broken by the new code. Another critical form of testing is called regression testing, which focuses on how the new code works with the existing code. Regression testing requires additional planning and visibility of enhancements between releases.

At a bare minimum, unit testing and smoke-testing are essential. They are cheap and easy and require a minimal amount of effort.

 

The real testing, however, comes in the form of functional tests and acceptance tests. This is how you connect the code that is created by the engineers with the business needs of the customers and the real-life use of the application.

Functional tests validate that the newly designed process aligns with the requirements that were provided to the development team. Functional testing is best performed by either the business analyst or the QA analyst. A distinct benefit is gained here when functional tests are designed and completed by someone who is familiar with both the application and the enhancement requirements. Here is a tip: well written requirements and an experienced QA analyst are your best friend for stellar results!

Acceptance tests (also known as User Acceptance Testing or UAT) validate that the finished product aligns with the needs of the business user. This type of testing allows the end user to touch-and-feel the new process to make sure that it will correctly address the defined business need. An end user is also looking to make sure that the workflow is not made worse. At the end of the day, the user still has a job to do!

 

Advertisement

 

A well-designed set of test scripts is the most efficient way to track results, and to facilitate tracing the functionality back to the requirements. A plethora of applications exist that do this for you! Many of these applications can also run the test scripts in an automated fashion, which works great for regression testing. If I have access to an experienced QA analyst, I leave the decision up to that person. I simply provide rock-solid requirements and expectations and make myself available for questions.

That said, I am a big advocate of DIY.

If I am running functional tests myself, I create test scripts the old-fashioned way: Excel spreadsheets. The perception is that this takes too much time. Yes. It can be tedious. However, if you consider that good test scripts can also be used for system and user documentation – a bonus for start-ups – it is an essential task, regardless of the effort. They can be maintained and re-used.

Put your user hat on and give it a try!

 

Begin with a few basic columns:

Who is the user? What role is the user filling while performing this task?

What is being tested? Describe the function in simple terms.

What are the exact steps to get the desired result?

What is supposed to happen when the steps are completed?

What actually happened when the steps were completed? Ideally, you would want this to be the same as what was supposed to happen. Many times, it is not.

Did the test Pass or Fail?

 

Add more context for tracking and tracing back to the requirements, like test IDs for each test and date tracking to facilitate repeat testing.  Add a column for additional comments so that the person who is running through the tests can add additional observations about what was experienced during the test.

 

 

In short, product quality drives customer satisfaction. Complete and consistent testing and retesting is one of the best ways to drive customer satisfaction with new products and product enhancements. It’s well worth your time and effort.

Happy testing!