One school of thought says each should do what he's best at and no more. But one company has graduated to a new way of life. Instead of isolating testers and business analysts, the two teams are melded into one—resulting in a more robust product created in less time at a reduced cost. Could this hybrid approach work for you?
EVERY SOFTWARE QUALITY team's ultimate purpose is to work toward the goal of the best possible software quality. This usually involves advocating, initiating, and executing tasks and processes to improve the quality of one or more of the steps in the software development lifecycle (SDLC).
Software testing teams often have a defined sphere of influence in the SDLC. It begins with test planning and ends with test execution, either manual, automated, or both. However, expanding the role of the testing team to new stages of the SDLC has the potential to significantly enhance the quality of the testing process and, in fact, the SDLC as a whole.
A Team Approach
Clear information regarding expected functionality is one of the most important inputs to successful software testing. This information may take many forms, including software requirements, specifications, use cases, and discussions with the business analysts and the user community. To a large extent, the success of the testing process is a function of the quality (accuracy, completeness, etc.) of these inputs. With this in mind, on a recent project with a Fortune 50 client, we formed a somewhat radical team comprised of testers and business analysts sharing identical duties. The mission of this team was to research and define major functional additions to a highly complex application, plan the tests, and execute the tests. The reason for including the testing team in the requirements gathering and definition process was two-fold: 1) to provide the testers with unparalleled intimate knowledge of the purpose and intended functionality of the application—which would improve and expedite test planning; and 2) to involve passionate quality advocates (testers) in creating the highest quality requirements. However, there were several unexpected benefits that resulted from this initiative, as I will detail later in this article.
Initially, the business analysts exhibited some resistance to the participation of the testers in the requirements gathering process. It seems they perceived the testers as a threat—which perhaps is not all that surprising. Imagine if roles were reversed and the business analysts were suddenly added to the testing process in an effort to improve test plans and test execution. It is reasonable to assume that testers would feel threatened by this situation. In order to allay the concerns of the business analysts, we made it clear that this project was intended to improve the capabilities of both teams equally. The business analysts would learn more about quality and testing from the testers, and the testers would learn more about how new software is defined and documented from the business analysts. Both teams also were told that, from a career perspective, working in multiple areas of the SDLC would be beneficial. Although some residual skepticism appeared to remain in a few individuals, overall, both teams were comfortable with the new arrangement for this project.
Cross-Training
Semi-formal cross-training was provided to help the testers become capable business analysts and similarly to help the business analysts become capable testers. This training was in the form of a "kickoff meeting" held by the two groups together. At the meeting, one representative from each team made a twenty- to twenty-five-minute presentation about how his team (e.g., the business analyst team) executes its responsibilities and how the other team (e.g., the testing team) can integrate these points in adopting the new cross functional responsibilities. The meeting was successful, but the primary education still took place “on the job,” as the testers and the business analysts worked together and learned from each other.
Logistics
We knew that it would have been optimal for the new cross-functional team to sit together. However,
About the author
Gedaliah Friedenberg (gf@ymsassociates.com), QA Principal at YMS Associates, a New York-based information technology consultancy, has been in the QA and software engineering fields for nearly ten years. His clients include serveral major pharmaceutical, financial, and retail firms. Mr Friedenberg holds a degree in Mechanical Engineering and an MBA.
