Testing, Testing, Testing… somebody’s gotta do it… and that’s not a joke.
How do I tackle this? My first thought is of other Business Analysts who insisted that testing was part of the job, saying something like “you do the requirements, then you test them.” When I met people who could not be swayed from this, I usually parted their company by saying “I hope you are getting two salaries.”
What this state of affairs implies is that because I as the Business Analyst was responsible for getting the requirements defined, that makes them my requirements; I own them. Nay, nay,(as John Pinette would say). The requirements belong to the business sponsor and staff who need these requirements met in order to be successful. Even if I stay through the whole of a project to implementation, I will eventually move on to another project, probably in a different part of the company. The business people who I worked with to get the requirements will be using the delivered solution for a long time after I am gone; the requirements are theirs.
Of course, the solution delivered to meet the requirements does need to be tested. For most of my career as BA employee, I have been fortunate that my employers employed dedicated testers, with Quality Assurance Analyst developing as a common title. Their perspective on the solution is different than mine. When I am doing requirements delivery, I am focused on the need, not what the solution could be. The solution evolves after I am done. The tester sees the solution when it has been delivered, so their work is directly involved with the solution.
And most of the time, the solution is an enhancement to existing systems that QA has tested many times before, including regression testing to make sure enhancements have not broken an existing part of the system. Testers end up knowing the systems better than anyone else. I could never match that level of experience and knowledge. I also just think it is a different skill-set, one I don’t have and am happy to have worked with people who do.
But Testers and Business Analysts have a connection that can encourage the situation I described above. It is a question of how people become Testers and/or Business Analysts, at least for many years during my working career. I graduated from university with a Computer Science degree and started as a programmer; no one graduated as a BA in those days or testers either. The source of most testers I knew was the special business person, the “power user”, the person all other business people went to when they had problems with their systems. That person would eventually become involved with User Acceptance Testing, when that came into vogue. This person might then decide that they might like to move to the IT side of the company (where the pay was usually better) because of their system knowledge. The move would happen, and the power user would now be a new Tester in the IT shop.
This new tester would be known to be an expert in the business and the existing systems, so when there was ever a shortage of business analysts, the power user/tester would be called on to do analysis, and then having done enough of it would get the job of Business Analyst…but with the continued responsibility of testing.
This path from business expert to business analyst is seen to be natural, and seen as a career path at many companies. The problem that I see is that their strong knowledge of the specific business and systems works well when all the projects are variations on the same business and enhancements to the existing systems. What happens when a BA is needed in another part of the business they have never worked in? Or when those current systems they know get replaced, as they will? This BA’s strengths turn into weaknesses, as their knowledge has no place to be applied anymore. Do they go back to being a user in the business and try to build that system expertise again? That’s a hard road, and probably with a cut in pay to boot.
If you recognize yourself in this description, or know others in this situation, and still have the chance to avoid the above final fate, my advice is: learn to a be Requirements expert, take courses, read, join the IIBA, whatever it takes to be the kind of employee who can be a Business Analyst for any business.
