From the Blogosphere
Getting Beyond the Software Quality Debate | @CloudExpo #BigData #IoT
Regardless of perspective, everyone agrees that ensuring high-quality software isn’t solely the job of a 'QA department'
By: Betty Zakheim
Dec. 6, 2015 09:00 AM
One of the most hotly debated issues in software development and delivery is the definition of "software quality." Depending on one's perspective the issue can take many forms. For example, is it:
Software Quality Not Just the Job of QA
Sure, testers test, developers build, business analysts develop requirements and the service desk helps users overcome issues, but it's the interaction of these groups that drives quality into the application. And interestingly, the interaction of these groups tends to center on development artifacts such as defects and requirements.
For example in a simplified view:
In this simplified view of the lifecycle, each case where an artifact (italicized above) is "conveyed" to another group, the transition represents either an opportunity for collaboration or the cause of friction between groups. Why the friction? Because each of these disciplines use specialized tools that are optimized for the kind of work they do. But because these tools aren't integrated, the only way to share and collaborate on these artifacts is through email, meetings and spreadsheets.
Invariably there are long status meetings, with colleagues pouring over spreadsheets that were manually collated by exporting data from each individual lifecycle tool. Communication between two team members about a particular artifact - e.g. how a defect was discovered, or when the defect was fixed and ready to be retested -- is done via email. Unfortunately, these ad hoc methods are separate from the actual defect records. So when looking at the defect records themselves, there is no trace of the detailed communication. If this defect later occurs in another part of the system, the next tester who finds it or developer that to tries to fix it won't have access to critical communication the previous developer and tester had. This results in much wasted time and lost information.
Integrating Tools, Synchronizing Artifacts
For example, when a tester creates a defect report, that defect would be mirrored in the Agile planning tools for triage. Once the developer starts work, she and the tester could communicate using the comments on that defect record. Neither of them would have to use email to discuss the defect; the tester would make his updates in the test management tool, and the developer in the Agile tool. When the developer changes the status in her tool to "fixed," the tester would immediately see that change reflected in the test management tool.
Taking Life Cycle View
Clearly this type of integration reduces the friction between the tools, increases communication among practitioners and reduces the information scavenger hunt that always seems to occur during software development. But the bottom line is that integrating the tools used in software development and delivery connects all project stakeholders and enables organizations to take a lifecycle view of their software quality.
As such, teams interested in measuring quality based on a low defect count, should be able to have an accurate view on the status of all the defects recorded. Unintegrated systems require manual and almost heroic efforts just to find the current status of each defect. With integration, this is available automatically.
If teams are interested in measuring quality by making certain that the application conforms to the requirements, they must put in place a mechanism for requirements to test result traceability. Without integration, traceability reports are created manually if the artifacts live in disparate systems. With integration, reports can be automatically generated.
And finally, and most interestingly, if organizations are in the business of delighting their users, the sheer number (or lack) of defects is often less important than ensuring that the areas most important to users are relatively free of defects. Wouldn't it be nice if the team could focus on areas that had the highest profile within the application? For example, being able to spend more time on the defects in the user authentication code (the area that all users encounter when they first start the application).
With integration, wasted time is reduced, increasing the team's capacity to focus more on what's important. Couple this with the fact that lifecycle tools provide better information, and you have an infrastructure that helps the team develop and deliver high-quality applications, no matter your definition of quality.
Reader Feedback: Page 1 of 1
Latest Cloud Developer Stories
Subscribe to the World's Most Powerful Newsletters
Subscribe to Our Rss Feeds & Get Your SYS-CON News Live!
SYS-CON Featured Whitepapers
Most Read This Week