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!!
Recently MARTA, Atlanta’s mass transit system, installed a fancy new fare system which takes “smart” cards instead of tokens. Things were a little bumpy at first but overall the new system seemed to be working well until the unexpected happened. Yesterday an article in the Atlanta Journal-Constitution talked about how MARTA took a heavy economic hit when the new fare system suddenly crashed during a maintenance upgrade and was down for about a day. About 115,000 people ride the MARTA daily. During the system downtime none of the cards would swipe, the Marta smart card vending machines quit working, more clerks were required than usual at each of the 38 stations affected, confused riders could not get through the blocked turn-styles, and others were inconvenienced to find cash to ride the bus. One of the outcomes is that MARTA is considering suing the outsourced software provider for damages.
Even though I do not know the details, clearly thorough testing was not performed during the upgrade process and based on the “free riders” snafu an acceptable disaster recovery plan was not in place. Like Jet Blue’s recent software fiasco that left travelers stranded, the MARTA system crash is another example of the potential financial impact an organization can suffer when technology suddenly goes awry. The lessons learned for these organizations may be more attention to plan for higher quality systems and also to have plans in place when the unexpected happens. One of my recommendations would be to hire and utilize skilled and thorough Business Analysts who will define excellent requirements and who will be proactive in finding problems early before the defects can be coded in the software.
The MARTA system upgrade should have been a normal maintenance activity. MARTA could/should have involved a BA to review the upgrade changes and validate that sufficient testing would be performed for the upgrade. Based on the money that was lost the temporary workarounds were not effective. No matter how stable a system seems to be, planning for disaster recovery is vital for any critical software system. A BA has skills to elicit and document an acceptable disaster recovery plan to reduce the business exposure in the event that something drastic happens. Disaster recovery planning can be started early in the project when BAs identify potential risks and assess their impact to the business. The plan can be finalized once a solution has been defined. Lastly, MARTA could/should have a skilled BA facilitate and document a root-cause analysis about what happened and communicate the results to the impacted stakeholders. This analysis would establish why the crash occurred and would hopefully lead to process improvements for future software changes. I think MARTA (and Jet Blue) should either hire or make better use of Business Analysts.
