Betty Zakheim

Subscribe to Betty Zakheim: eMailAlertsEmail Alerts
Get Betty Zakheim: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


Related Topics: Cloud Computing, Security Journal

Article

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'

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 that has a low percentage of defects relative to the size and complexity of the application?
  • Software that conforms precisely to the stated requirements?
  • Software that "delights" its users?
  • All of the above ... and more?

Software Quality Not Just the Job of QA
Regardless of perspective, everyone agrees that ensuring high-quality software isn't solely the job of a "QA department." It requires the collaboration of every discipline in the software development and delivery lifecycle from the inception of business requirements to the administration of the application in production -- and every point in between.

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:

  • The PMO sets high-level business initiatives;
  • Those initiatives are conveyed to business analysts who create requirements;
  • Those requirements are conveyed to the development team, which distills them into user stories, and to testers, who create their test strategies and test cases;
  • The developers design and build the code, and the testers uncover defects, which have to be conveyed to the developers for remediation;
  • Once the application is put into production, the service desk team fields user incident reports that may, in fact, be defects that must be conveyed back to the development team.

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
But if these tools were integrated and the artifacts synchronized across them, team members would work on artifacts in their tool of choice, while the integration continually updates them with information from other team members working in their tools.

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
By taking a lifecycle view of software quality, and integrating the tools that each of the disciplines in this lifecycle use, organizations can increase the following:

  • Collaboration - Team members can collaborate on defects, requirements, test cases etc., from their tool of choice. They no longer would need to use email to communicate on these artifacts, they simply would make comments on the artifacts themselves.
  • Flow - Teams could unlock the data that's stuck in the individual tool silos and let it flow from system to system.
  • Traceability - Members could get a holistic view of the relationships between requirements, tests and defects, no matter in what tool those artifacts were created. An integration that is robust enough to understand the intricate relationships among requirements (including hierarchies of requirements and user stories), test cases and test results, would provide greater information about test coverage and an up-to-the minute reflection on the status of every test.
  • Visibility - Organizations would get better cross-project visibility through existing reports, or collect all lifecycle data in a separate reporting database. Lifecycle tools such as defect tracking, requirements management and Agile planning tools allow managers to get reports pertinent to their domain. Unfortunately, when they are disconnected from one another and don't share data, these reports can only present the information in their tool silo. When these systems are integrated, the reports from each of them are richer, because they include the most up-to-date information from across the lifecycle.

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.

More Stories By Betty Zakheim

Betty Zakheim is VP of Industry Strategy at Tasktop. Her role is at the vertex between Tasktop’s customers, the company’s product team and marketing team. She has an extensive background in software development, software integration technologies and software development tools. As a software development manager, she was an early adaptor of “iterative development,” the precursor to Agile.

As the VP of product management and marketing at InConcert (acquired by TIBCO), she pioneered the use of Business Process Management (then called “workflow) as the semantic framework for enterprise application integration. Previously, Betty served in leadership roles for many other companies including CopperEye, Progress Software, IBM/Rational Software, IONA Technologies and Lightbridge. Betty holds undergraduate degrees in Psychology, Advertising from the S.I. Newhouse College of Public Communications and is a Tau Beta Pi scholar in Computer Engineering. She also received a Master of Computer Science degree from Boston University.

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.