I have found that many BAs cringe when talking about software testing. They don't want to test and don't seem to want to learn the basic testing principles. I fell in love with testing when I learned about the best practices and all of the techniques. When you are testing, your goal is to find problems. What other job encourages you to look for and point out problems?? The more problems you find the more successful you are! And of course, the ultimate goal of all quality assurance is to improve the quality of our solutions!
Five reasons that BAs should love testing:
1. Thoroughly testing (and fixing) the solution before deploying ensures that users will be very happy with your work.
2. Having testing principles in mind when developing requirements helps to improve every single requirement. If you are constantly wondering "How would I test this?" you are more likely to develop complete requirements.
3. Executing tests and investigating defects teaches you more about how software applications are created. If you don't have a technical background this is a great way to learn more about what developers do and improve your communications with them.
4. Executing tests gives the BA a hands-on opportunity to imagine the best rollout strategy for your business stakeholders. When you have entered data into the software and generated reports, etc. you will easily be able to help the business area make the transition to the new system.
5. BAs learn to really appreciate SQA professionals and treat them better when they are available. Having been involved in testing, you will understand the work of SQA people and hopefully request them on future projects.
So, the next time you are asked to help with testing – smile and enjoy!!
11 Comments
Well, I agree with those reasons, but I also agree with the reasons why I should eat more veggies, but…
Kerber,
Very funny! I appreciate your point, I have been trying to convince one of my co-workers to get excited about testing for 3 years and she still doesn’t buy it!!
Barb
I’m with you Kerber. Testing has never been my favorite, but I agree that it is vital!
I can completely vouch for the above reasons. As an add ons to the above reasons, I also feel that a BA can visualize additional scenarios and carry out What-If analysis thorugh end to end testing process.
I think your focus is completely wrong. BAs should not love testing, they should love test planning and strategy. While it is ok for the BA to perform testing, the primary goal of the BA should be providing guidance to the QA team to ensure that requirements are met.
The BA must first be able to communicate the requirements in a verifiable manner. (#2 in your list). In addition, the BA should verify that QA understands the goals of the product or solution. The BA should review test plans and if they understand testing principles, the BA should also review/discuss testing strategy for each section. The goal of the review is to ensure the QA team understands the testing priority and will provide proper coverage of the product. (#1 in your list)
I don’t agree with your assertion on #3 and #4. But I do agree if the BA assists in the testing, they will come to appreciate the QA professional. However, the BA should coordinate with testing so the effort is not redundant, and this requires that QA have faith in the BA’s abilty to test. Otherwise QA will have to tackle those areas again.
Sam. Thanks for your comments. I agree with you that when a QA team is available BAs should not test. But in my experience lots of BAs work on projects without a QA person so they are left to do all of the quality assurance work themselves.
Barb
Another perspective to consider is the role of the BA in an agile project;
If the BA is on the team they are basically the product owner (or a proxy for them) and so they need to participate in the testing and feedback activities to keep the development and design on target.
Frankly I reckon if you don’t have a BA involved in testing you can’t expect the BA to take any ownership of quality requirements. They won’t be around to see the mess they created (or avoided) due to the quality of their work.
I think that BA need not have any testing skills. If possible, developing a testing plan and executing the tests should be left solely to the testers. Having said that, testers may want BA to be part of the testing team helping them write test plan and do some testing.
BA’s should help in the testing team if possible. But BA’s cannot and should not replace testers. It would be of big advantage if the BA helps to define the test conditions.
I think BA should organize training session to discuss test strategy with testers and should execute some important scenario at the end of testing to ensure quality.
I agree with points #2 and 5 – make requirements test-able and appreciate those who do the testing.
The problem with BA as tester is on par with trying to proofread your own work – you tend to “see” what you intended and not what you actually wrote. In testing terms, if the BA is testing his/her own test plan/cases, the tendency would be to do what you intended. This means the BA is not paying attending to the details – but when its your own work, its tough to see exactly what is there.
Sure, I love testing – when someone else is doing it. The feedback you receive from the QA-folks will hit home more easily if there’s something lacking than if you found it, because at that point its your reputation on the line. I do agree that being part of the testing process at some point in your career will certainly provide a valuable perspective that you can take with you for future requirements, in addition to the added appreciation for those who do the testing.