COMMENTS
Article is well written though I may not fully agree with the author. Here is why (in response to the authors argments)
1. Quality Assurance is a Separate Role - to put is simply, I see no reason why a capable person cannot take on multiple roles. Quality assurance is not a complete paradigm shift....
2. Quality Assurance is its Own Profession- maybe ...maybe not.... there are numerous s/w professionals performing both analysis and QA (for that matter development and project management). Although I agree the larger and complex the systems are, it is better to separate this as its own profession
3. Bias Inherent in Performing Both Roles: The argument given by the author "The BA can become so intimate with the requirements that they may not realize when certain assumptions are undocumented" can be solved by having peer reviews by fellow SAs (or Dev or QA) . It doesnt necessarily take a QA person to point out deficiencies in a systems analysts' specifications, it can be done by other people too.
4. Lost Opportunity to Have Another Set of Eyes in the Process: Agreed, but an SA can perform the QA testing for another group hence he/she is the other pair of eye and vice versa.
5.Get a Tester : A tester who simply executes test cases still needs someone to think things thru and develop the test cases.
So overall, re-iterating myself, while it is good to have separate people perform separate functions in the s/w development process, I see no reason why roles cannot be interchanged or overlapped.
Hi rajanh,
Thanks for your comments, I appreciate the feedback. With respect to your comments:
I agree that an individual can play multiple roles within a project, and often has to on small projects. My issue is that many organizations seem to assume that a Business Analyst is also a de-facto QA person, when this is not the default case. While QA may not be outside of the realm of BAs with a technical background, for other fully qualified Business Analysts with little to no technical training this could be a great stretch, but has nothing to do with their BA skills. If an organization needs a person with both BA and QA skills then the title of the job description should say such.
I agree that if the BA who performed requirements gathering and writes test cases for the same project the bias can be mitigated by having outside reviews and the like, but I would wager that the reason the BA is performing double duty is because there is an insufficient skill set within the project/organization to support having another person work on the testing aspect. Perhaps developers from other projects could assist with this review process, but realistically if they have this type of time available I'd ask them to write the test cases in the first place (after all, a developer role is even closer to a QA role in many respects).
Perhaps my language is incorrect - when I mean execute the test case I mean go through the steps that have been indicated in a fully fleshed out test case verbatim. I often have clients perform this task prior to UAT so they can become familiat with the system and at the same time have feedback. You shouldn't need any special expertise in order to do this step, if the test case is written correctly and the environment is set up properly.
Thanks again for your comment!
I have ranted/written on this topic elsewhere, and I am with larimar on this topic. However,some new thoughts have come to mind today...
-Most projects enhance current systems, only a few create brand new systems.
-Testers don't test requirements, they test systems to see if the systems have been enhanced properly to meet the requirements. This does require some knowledge of the systems
-Many projects define requirements that affect multiple systems, which may not be clear until design is done; different testers will do the testing based on system knowledge. A BA without system knowledge would be much less effective than a tester with systems knowledge.
So, the testing role in most companies is associated with the systems they test, not the business area or requirements. I know because I have worked as a BA with good testers, who knew what strategy and test plan/cases would be need based on receiving requirements that affected the systems they test. There was no way I could match that knowledge/expertise just because I had developed the requirements.
My last and consistent point is that if you are doing more than one job, you should get more that one salary...
My simple observation is - If a peron is qualified then why shouldnt they do it ?
And I totally agree, if they are doing more than one job then they shud get more than one salary.....
"If a person is qualified then why shouldnt they do it ?"
Sure, that is true for such a person.
The point here is: Being a qualified BA does not automatically make you a qualified Tester.
"The point here is: Being a qualified BA does not automatically make you a qualified Tester. "
I never said that....
But if a person is qualified to be a BA and QA person then why not...
You cannot generalize things...that BAs shouldnt do QA work or Developers shouldnt do Photography or etc etc...you get the point.
Is it not a reflection of organizational immaturity for an organization to combine such roles?
I couldn't agree more with this blog entry. Best practice is for the Business Analyst not to perform QA testing. That being said, every company doesn't follow best practices and certainly not on every project.
I am capable of performing QA testing but then again, so are many others. Why does it necessarily fall on the Business Analyst to perform the testing? Wouldn't the developers or the solution architects have the necessary skills to do so in addition to me?
"If a person is qualified than why shouldn't they do it" - I think this is a great example of the thought process behind why some projects ask Business Analysts to test. Am I missing out on other Business Analysis activities so that I can test? Is testing the best usage of my time, or am I simply another resource to be leveraged by the PM?
What else am I qualified to do? Where do you draw the line between what one is capable of doing, and what one SHOULD be doing? Testing? Coding? Changing lightbulbs?
"The point here is: Being a qualified BA does not automatically make you a qualified Tester. "
Sorry for any confusion... This refers back to the original point of the discussion, that some organizations assume this is true, or should be true.
Posted by Eva Grunfeld on LinkedIn:
I read the article, as well as some of the comments associated with it. I do agree with most of your reasoning. However, I think there is at least one good reason for a BA to do testing, and that is to verify that the requirements were correctly interpreted by the programmers. Sometimes a BA is so immersed in a project that she neglects to include some points in the requirements document becasue it does not occur to her that others don't have that knowledge. When a BA tests that particular function, and it does not play as she envisioned, it may well be due to interpretation rather than programming error. So, some testing is a very good check on the requirements.
In addition, while we may all agree that the BA and the QA role are separate, in today's environment, I see BA job postings that require, in addiiton to BA sills, a whole gamut of very specific technical and software knowledge and PM skills as well.
Postd by Otis D on LinkedIn:
Companies are trying to cut corners and save money. That is why they force BAs to do quality assurance as well. Especially in this economy.
A QA-Analysts should do the quality assurance and testing.
Quality assurance being making sure that the BA followed due process and that the requirements are atomic, unique, unambiguous and above all testable.
In essence QA is ensuring that both the developers and Bas follow the rules, to get to a good product.
If the BA is the QA, they tend to slack and cut corners themselves to get to the end.
I teach my BAs to refuse any position where they are required to do testing as well.
Cheers!
Posted by Udai Singh Rathore on LinkedIn:
Hello,
I agree with both of you that a BA should not do QA job. Denise, I can understand your previous job condition because I have seen companies do this to cut cost.
Actually what I believe is BA's should be doing only UAT part not the actual testing.
please guide if any different views
Posted by Mark Troncone, MBA on LinkedIn:
I believe that a BA should be involved in the QA process, but at a high level. By that I mean to assist the QA team in answering any questions that they have about the functionality, measurements, or results of the of the requirements and how they are to be incorporated into the existing system or built as a new system.
The BA should also be invovled at a high level, as a knowledge resource, to assist QA in their testing efforts as far as reviewing issues and any discovered "bugs" and fixes, or answering questions for clarificattion. The goal here is to be viewed as a subject matter expert for the requirements, the system functionality, and data processing.
Working with QA and reviewing their test plan and results makes my job easier for UAT testing and aiding me in developing a user test plan.
Posted by Linda Ros on LinkedIn:
Two comments with regards to BA involvement with QA..
First comes from a best practice perspective (and quoting Deming) "Quality is everyone's responsibility". By the very nature of building effective and robust business solutions the BA and the QA processes are linked and to view them as separate is to forgo a powerful opportunity to deliver a game changing improvement.
Who better to guide the testing efforts then the process expert. The expert who can draw upon his/her knowledge of the entire process not just a particular task or step, the person who knows the exceptions not just the "standard" process and has a solid vision of not only current conditions but also possible future need.
I have found the level of involvement has as much to do with the type of project and the reality of the project time-line as it does with job descriptions.
Second, I agree with the others, postings and hiring managers should make it clear the skill set required for a particular BA position. Hint to those in transition, this is a great topic to discuss during your interview.
Posted by Bill Reister on LinkedIn:
Depending on the size of the team and budget, this is absolutely wrong. No one is likely to have a better understanding of the requirements than the BA.
In these times of 20% real unemployment, the slacker who says, "I don't do QA" is the slacker who will find him/herself on the bench.
Posted by David Medici on LinkedIn:
disagree, Mr. Reister. Of course the BA will have the best understanding of the requirements, but he will not have the best understanding of QA processes. QA and BA are distinct professions that have their own required skillsets, competencies, and methodologies. I am sure an automotive engineer would probably have the best understanding of automobile technology, but I would rather have an automotive mechanic diagnose my auto ills. QA and BA are not mix-n-matchable.
I notice you are the President of Thunder Enterprises. Without meaning to offend, perhaps the reason QA is still generally poor across many industries (IT for sure), and perhaps the reason BA is still often relegated to "writing use cases" or "gathering requirements" is because management still does not understand either profession and continues to think it is six-of-one-half-a-dozen-of-another, a good chance to save money by hiring one person to do two roles. (Same reasoning that often combines BA and PM, to the detriment of both.) Understand and respect both professions and I would be willing to wager large sums of money that you will find your business people conceiving and articulating better business systems and processes, your QA people ensuring quality is built-in from the start and realized when the project ends, better speed to market, and lower costs overall.
Posted by Bill Reister on LinkedIn:
HI David,
You've missed my point entirely. My point was that taking a one-size-fits-nobody approach does a disservice both to yourself and your client/employer.
Does specialization and division of labor make sense in a large organization, or on a large project? Generally, yes. But not always. By thinking of yourself as a "Business Analyst" or a "Project Manager" or a "Tester," you have marginalized yourself and your value to your client / employer. We all have a bag of tricks, and if you want to maximize your own value you need to be willing to jump up and say, "hey, I can do that!" Those who keep silent in such an opportunity or, worse, proclaim that it isn't their job, may find they have no job at all when someone else with a more can-do attitude is readily available. Today, this minute, there are a LOT of highly motivated people with a can-do attitude looking to be that person to "give you a timeout on the bench..." ;)
President of Thunder Enterprises makes me master of exactly me, myself, and I. In 18 years "in the IT industry" I have worn every hat and, yes, sometimes less skillfully than another might have. No one is good at ANY job until they roll up their sleeves and DO IT. However, even if I am not the best possible person to do a job in THEORY, as Johnnie-on-the-Spot I may well be both sufficient for the business and the best in PRACTICE because I already understand the business, the team, the product, and the requirements. Making that decision should involve judgments on risk, time, budget, existing skill sets, and the ability of the individual to know their own limits and compensate accordingly. Part of that judgment and risk assessment is the willingness to stand up to management and say, "No!" when they suggest that you do something that you KNOW is beyond your skill or that will introduce unacceptable risk to a project which "cannot fail." That takes a spine - another skill not automatically granted by graduating from school. But attempting to take the judgment OUT of the process and applying the same rulebook irrespective of circumstances is a losing game - and it only serves to further commoditize our services and our value in the eyes of prospective clients/employers.
The point to all of this is that any project is only going to provide ROI if the cost to undertake it is less than the business benefit. Anything else is FAILURE - no matter that you might set and meet some arbitrary schedule or budget. Knowing this, and knowing that some projects may be running closer to red ink than to black, means that we all need to exercise our professional judgment to prevent "perfect" from becoming the enemy of "good enough." Just as in warfare, the perfect plan executed flawlessly one minute too late means failure, while a "good plan" that "compensates for errors in time" wins the day. The level of detail and specialization necessary to make a plan that "good plan" varies considerably with circumstances, so much so that some very small projects are best accomplished with a single person being BA; PM; Coder; and Tester. Put another way - the general who attempts to fight every engagement with the same plan may win some battles but will ultimately lose the war.
Hope that makes my intended point clearer!
Cheers...
Posted by David Medici on LinkedIn:
Mr. Reister, I do not believe I did misunderstand your point.
The question we were asked was, "Why [shouldn't] Business Analysts ... Perform Quality Assurance?" We were not asked whether one should refuse to do something outside the narrow confines of one's profession. I have, on many occasions, done things that were outside my BA profession, and on many occasions done it better than those whose responsibility it was. In most of my professional engagements I have been Mr. Manyhats, doing many different things simultaneously, swapping hats as the moment required it. That is all part of being professional, of getting the job done in a responsive, resourceful manner.
The question was seeking to understand possible reasons why, on general principle, Business Analysts should not execute Quality Assurance Analysis. It may have had, as a subtext, the idea that the general principle needed to be taken more seriously by management, for generally it is management that determines the responsibilities of a role.
My response addressed what I thought was the question's intent, namely, addressing the general practice of making BAs perform QA functions, and I threw in PM since many BAs are brought in to perform a BA/PM role (what we BAs humorously call a BM role).
Your point was entirely project oriented, in my opinion. You talked about someone willing to jump in at a minute's notice, about someone making themselves readily available, about risk to a project, about ROI on a project, etc.
My response was entirely profession oriented. I addressed why, on general principle, a BA should not be tasked with QA functions. As a rhetorical device I brought in the analogous situation of an automotive engineer diagnosing auto ills, which is properly the function of an automotive mechanic. I could have brought in the analogous situation of a dental hygienist diagnosing tooth decay, the proper function of a dentist. Could an automotive engineer diagnose that odd sound in my car? Sure. Could the dental hygienist look at my x-ray and diagnose a need for a filling or cap? Sure. Should they? No. Why? I answer it is because the entire point of professional differentiation is to produce excellence in specific capacities which, of and by themselves, add value to an organization as a whole. My answer was more concerned with value to the organization, with ROI on a far grander scale than a mere project.
I do understand your point, and there is merit to it. But not at a professional level. That is something that years of observation and experience has convinced me management, by and large, still does not understand with respect to BA, QA and PM. Perhaps that is why I noticed your title.
Posted by Bill Reister on LinkedIn:
Hi David,
No need to call me "Mr." - I wasn't intending to be critical of your position, but rather suggesting that my first answer had been too short and unclear. I'm Bill to everyone....
Ok, I see what you are driving at and I think perhaps it is a case of "violent agreement." What my original post was responding to was not the TITLE of the article, but the author's first line:
"I don’t believe a BA should be expected to do Quality Assurance tasks."
For my part, I believe such blanket statements drive us to build a silo-ed "world view" that both compartmentalizes and (unfortunately) commoditizes us as people.
I absolutely agree that, from an ORGANIZATIONAL perspective, it is best to keep your BAs doing BA work, etc MOST OF THE TIME. However, such an approach flies in the face of three significant counter-challenges: Most organizations are not large enough to support strict functional specialization, keeping any person in a single role narrows their perspective and reduces their opportunities for "broadening" their skill set; and team size is typically tending to hover around the 5-7 "optimal" size identified many decades ago (optimal in terms of human efficiency with respect to geometric expansion of communication as team size increases). If you are lucky enough to be in a corporate environment large enough to support strict role specialization you are among the lucky! Otherwise, welcome to the world populated by the rest of us.
Again referring to the article, job requirements that gave him pause were:
* Define test strategy and test plan
* Develop and execute test cases
* Perform stress and load test scenarios
Like you, as "Mr. Manyhats" I've often done other roles, and if I may say so often better than the "specialists." Well, we all think that don't we? :)
But, looking at those three bullets the first thing I think is, "if this is a large enough organization to have true role specialization, then the first bullet should be boilerplate; the second bullet should be half complete by default if I develop use-cases as I should; the second half of the second bullet I can probably do quicker than I can explain the use-cases; and the third bullet should be mostly accomplished by regression-test scripts created in prior releases, while I should be working with the scriptmasters to develop any NEW load test scripts that new functionality might require."
In other words, as a BA these bullets either fall directly to me or require my direct and full engagement - so I find myself asking, "what's the problem?"
Well, the world is wide and never is one answer right for all situations!
Cheers,
Bill
In small shops (read: tiny), the BA, DA, software engineer, programmer, tester, implementer and maintainer are all one person.
There is great merit in having more than one role because it heightens the awareness of the individual to satisfy the user community as completely as possible and to to *get it right* the first time.
Hi Bill and the rest of the community,
I appreciate and respect the topic posted and all comments but in particular, I would like to thank Bill. I have always been of the notion that BA's should not test (as per BABOK). Yes, there is reasonable truth to the article but I also like all your comments Bill and they have changed my mentality about work. Every individual has a right to his/her opinion and I thank Larimar for having raised this topic for your comments (Bill) have changed my like for good.
I am strong in both Business Analysis and QA; and have been planning to dump Business Analysis for QA. I have been so indecisive about this and it has been tearing me apart. I just wanted to specialise in one profession. I am more attracted to 'finding fault', hence the QA choice has been consuming my thoughts. You know what, no more stress for me, you have assisted in clearing my head. I love this Blog with a passion! Pardon my excitement!
One last thing, Bill, you can make a good mentor and coach!
I'm glad to see that this post generated so much discussion - many great points all around. I would like to clarify a couple points however:
- This article was not meant to advocate that individuals should only be a specialist in one area; over the past 12 months I have performed Business Analysis, Project Management, Quality Assurance, heck I even helped code up some functions when one of my teams was in a time crunch. Individuals don't need to be typecast in one role; in fact in most organizations that can be a career limiting move (which is unfortunate but all too often true). Dikeledi I'm glad that you have a passion for two specialties - that is a great asset to have. Don't ever feel like you need to be 'only' one profession.
- I still don't believe that someone who is a dedicated Business Analyst should be expected to do any level of Quality Assurance. If there is a specific job that requires both then it should be clearly stated as such in the job title (i.e. BA/QA, much like the BA/PM positions I often see). Without this descriptor it appears to me that they assume QA is part of the Business Analysis profession, which it is clearly not.
- From a Project Management perspective I see that there's risk to the project is there is only one person who is responsible for both requirements gathering/management and then validating these requirements are met. Some great mitigation strategies were discussed above but for me the ideal mitigation is prevention - if you can have two separate people to do each aspect then that's the way to go. If you have two BA/QA personnel in the organization then have one do BA work for one project and the other do the QA work for the same project.
Again great discussion and I appreciate all the detailed comments!
Larimar (and everyone) - this has been a wonderful discussion on role definition, accountability, and career advice. The only comment I would like to add is for those of you who may not be quite as old as some of us. I am a 20+ years Business Analyst veteran by virtue of being provided opportunities early in my career to explore the Analyst mentality by performing QA, programming, solution design, project management, staff management, etc.
I am fortunate to have been given those opportunities and still take advantage of my background to help out when needed to get a project or product delivered, but I love my role as a Lead/Senior Business Analyst.