In this first part of a two-part series, Mario Moreira writes that a reasonable application lifecycle management (ALM) product will have a common user interface for utilizing the ALM functionality. It will also include a meta-model and process engine to parse and share information across and amongst the various functions within the ALM framework. These technical needs must be accompanied by a strong business case for delivering higher customer value and new approaches for seamless integration.
What first may appear to be an obvious bug, may not be after all. Closely looking at a recent experience shopping online revealed what first seemed like a bug, but could also have very well been a cleverly placed, well-executed sales strategy.
In this second part of a two-part series, Mario Moreira explores the back-end disciplines of a lifecycle that establishes an ALM framework centering on customer value. If your organization has adopted agile and you are looking at building your ALM framework, consider an infrastructure and tooling that will help you establish and build customer value throughout the lifecycle.
Jonathan Lindo describes examples of automated test infrastructure utilizing both open source and traditional, independent-software-vendor-sourced software. In addition, he discusses new techniques for extending the value of automated testing by transforming the process from defect finding to defect resolution by reducing the effort required to document, reproduce, and troubleshoot the defects generated from automated tests.
Software development teams and software testing teams have numerous defect-management tool choices to help support their software defect efforts. But, selecting and utilizing an effective tool is really only part of an overall defect-management system.
This article discusses how testing teams can improve their test coverage and better communicate with technical support to uncover issues earlier than during product implementation. This kind of collaborative work can stop most defects from getting into production.
When Ipsita Chatterjee started testing about a decade ago, her test manager and mentor told her, "A good tester is not one who finds the most defects, but one who closes the most defects." After years of developing her testing and test management skills, she couldn't agree more. She now asks herself, how can a tester close more defects? Her answer: by using a fine combination of product and technical knowledge, intuition, and personal skills. With that in mind, this article focuses on the definition of defect advocacy; why, when, and how to approach it; and a few ways of achieving it to an optimum level, which should help you release quality software applications.
In his April 2005 column, "After the Bug Report," Danny R. Faught suggested that when you're testing a bug fix, you should also look for additional bugs. This week, he expands on that idea, showing you how one bug report can multiply into many more bugs.
We crank out bug reports and expect them to return like a boomerang so we can check to see if the bugs were fixed. In this week's column, Danny Faught shares some ideas drawn from recent experiences that could make you a better customer advocate subsequent to filing a bug report.