Nonfunctional requirements describe aspects of the system that do not map onto a single piece of functionality. Essentially, they're constraints you need to operate within. Allan Kelly details how running performance tests regularly can be the key to nonfunctional requirements, as well as how much value these constraints produce.
This case study serves as an example of how adopting agile can be extremely beneficial to an organization, as long as situational factors are considered. Adopting a new development method is a strategic, long-term investment rather than a quick fix. As this article shows, making deliberate, fully formed decisions will ultimately lead to better outcomes.
Justin Rohrman writes that measurement is one of the biggest problems he's experienced in test management. How do we measure quality, how do we know those measurements are good, and how do we use them to tell a story to executives? In this article, Justin explains how to speak to your business using measurements.
Kent McDonald writes that identifying objectives and the assumptions underlying them provides you a way to measure whether the result of your project will actually get you closer to what you are trying to accomplish, as well as the impact your various assumptions have on reaching that objective.
This article explains methods to build a team that will embrace "required work" and deliver robust software in a predictable fashion. It proposes a measure that helps calculate the throughput of an agile team by comparing work committed to work actually done.
Observing customers in a usability lab can be invaluable for improving product design. But, once your software leaves the lab, do you know what your customers are actually doing and whether or not your software meets their expectations? Learn how engineers on the Microsoft Office team apply a variety of software telemetry techniques to understand real-world usage, how the results drive product improvements, and how you can apply similar techniques.
Managers often use metrics to help make decisions about the state of the product or the quality of the work done by the test group. Yet, measurements derived from bug counts can be highly misleading because a "bug" isn't a tangible, countable thing; it's a label for some aspect of some relationship between some person and some product, and it's influenced by when and how we count ... and who is doing the counting.
People often point to requirements documents and process manuals as ways to guide a new tester. Research into knowledge transfer, as described in The Social Life of Information, suggests that there is much more to the process of learning. Michael Bolton describes his own experiences on a new project, noting how the documentation helped ... and didn't.
The Mismeasure of Software: The Last Metrics Talk You'll Ever Need to Hear Lee Copeland claims that most organizations have some kind of metrics program—and almost all are ineffective. After explaining the concept of measurement, Lee describes two key reasons for these almost universal...
Committed to covering the latest trends and approaches for anyone investigating or implementing agile development practices, processes, technologies, and leadership principles, Agile Development & Better Software Conference West offers their 2013 interview series.
Lee Copeland maintains that most organizations have some kind of metrics program—and almost all are ineffective. After explaining the concept of measurement, Lee describes two key reasons for these almost universal metrics program failures.