Is it effective to have the tester of the software also be the business analyst?
briley last edited by user
I work as a business analyst leading the charge on a medium sized internal software project. It's my job to create the requirements, design the UI, write the functional specs, work with the developers on implementing it and also to an extent write the queries for some of the reports (or at least show the developers how certain reports need to be implemented).
That being said, I also have to take a lead testing role and write all the test cases and do most of the testing myself (there are others who step in to do some of the testing work, but the test cases have to come from me). I find that much of the time this works fine; I catch a lot of bugs, they get fixed, etc.
However, sometimes I feel that because I am so close to the details (I am the only person who knows every single aspect of the application) it is hard for me to be truly objective in testing, which seems to be necessary. There have been times we deployed to production and there were things that I just didn't think about testing, maybe because subconsciously I tend to test the "happy path" more often than not (also I am a power user of the legacy version of the software that we are replacing, so I have developed certain biases if that makes a difference).
Is it right to say that the business analyst should be separate from the person who writes the test cases, or do I just need to learn to do a more thorough job when creating test cases and figuring out all possible scenarios? What doesn't help is that I tend to view myself more as a developer than a tester (not that I do any of the actual programming, but I do help the developers come up with solutions and often dive deeply into certain technical details).
One additional detail, if it makes any difference: I'm also essentially the project manager (although I don't officially hold the title of manager). It's my responsibility to make sure new features are prioritized, work is coordinated amongst developers, and that we meet our release goals.
There's no problem being BA+QA, but it looks that you're also an Architect in your project.
I see a direct evil in combining Architect and QA roles.
You have noticed for yourself every concern: the natural role of an Architect is to stand up for the idea that "the program is working". The natural role of QA is a direct opposite: to prove that "the program is not working". If the same physical person acts for two opposite roles, this may lead to compromises with yourself.
Yes, there are many people who can quickly "wear different shoes", but it requires the experience and trust of the team.
I see several ways to mitigate this:
- You can take some of development on yourself and assign someone else to act QA.
- You may find another team in your company who suffers the same problem. You become a QA in their team, and some of them become your QA. This would have an extra benefit of sharing knowledge among the teams.