Process

Articles

Thinking Inside the Box

The problem with urging outside-the-box thinking is that many of us do a less-than-stellar job of thinking inside the box. We often fail to realize the options and opportunities that are blatantly visible inside the box that could dramatically improve our chances of success. In this column, Naomi Karten points out how we fall victim to familiar traps, such as doing things the same old (ineffective) way or discounting colleague and teammate ideas. Thinking outside of the box can generate innovative and ingenious ideas and outcomes, but the results will flop when teammates ignore the ideas inside the box.
Naomi Karten's picture Naomi Karten
December 3, 2004
Keyword-Driven Testing

A curious phenomenon occurring among testers has caught Danny Faught's attention; testers everywhere are independently writing their own keyword-driven testing scripts. But what is keyword-driven testing, and how does it work? Is it better than data-driven testing? In this week's column, Danny reveals the testing method's simple design that has made it popular with many testers and non-testers alike.
Danny R. Faught's picture Danny R. Faught
November 5, 2004
Learning Speed from Quality Programming

As software professionals we spend far too much time fixated on speed and asking questions about how long a task is likely to take. In this week's column, Mike Cohn says we need to focus more on quality than speed. When something is done well, it's only a matter of time until it is done quickly.
Mike Cohn's picture Mike Cohn
October 22, 2004
Schedule Chicken

For one reason or another, team members don't feel safe reporting bad news that marks the delay of a project. No one wants to take responsibility for the set back, so the blame is passed down the production line. At this point, the blame game is in full swing. In this week's column, Peter Clark refers to this game as Schedule Chicken. His commentaries on the game's development reveal strategies that perpetuate delays. And this game only has losers: the project and the customer.
Peter Clark
September 17, 2004
finding tools Being Resourceful When Your Hands Are Tied

You work hard to find tools that can help you. You learn how to use and configure them. Then you find yourself working in an environment where you can't even use them. Have you encountered this frustrating situation? Danny and Alan have encountered this frustration many times before, and in this week's column, they're here to say you don't have to abandon all hope. If you're creative, you can still find tools to use–even in the most inhospitable environments.
Danny R. Faught's picture Danny R. Faught
August 27, 2004
The Demons of Ambiguity

When ambiguity rears its nebulous head, how can we move our projects forward with certainty? According to Harry Robinson, one of the most useful things a tester can do is ask good questions early in the software development process to help the rest of the team members to think clearly about what they are doing. In this column, Harry offers us some weapons to defend ourselves against the misunderstandings, bugs, and rework that often result from ambiguities in the development process.
Harry Robinson's picture Harry Robinson
June 24, 2004
So Many Tests, So Little Time

In this corner—A harried project manager whose testing time has just been cut in half. And in this corner—A time-honored management tool to scale back project scope and make testing tasks do-able. Johanna Rothman shows us the ropes of timeboxing and explains why time constraints don't have to be a TKO.
Johanna Rothman's picture Johanna Rothman
May 6, 2004
Problem Resolution Optimization

No matter how well we plan and execute software development, defects are generated and can escape to the customers. Failure to quickly resolve software problems leads to negative consequences for our customers and increases internal business costs. A quick deterministic
method to prioritize problems and implement their solution helps to reduce cycle time and costs. Achieving this goal requires several steps. The first is to determine a model that links problem resolution performance to institutional variables and problem characteristics. Statistical Design of
Experiments (DOE) is a tool that provides data requirements for estimating the impacts of these variables on problem resolution. Once data has been gathered, the results of statistical analysis can be input into a mathematical optimization model to guide the organization.
This paper describes such an analysis.
Don Porter
February 26, 2004
Bug Movie

Lights. Camera. Action! This article suggests using multimedia tools that combine a visual display, voice recording, and screen annotations to illuminate the steps required to isolate a bug. The result is an effective means of simplifying the process for both testers and developers. Yogita explains the benefits and risks associated with producing your own bug movie.
Yogita Sahoo's picture Yogita Sahoo
October 27, 2003
Estimation IT Software Development The Estimation Fallacy in IT Software Development

Despite the fact that iterative approaches to software development are increasingly used, most of the people paying for IT software developmet have an expectation that we should be able to tell them—before coding starts—"what's it going to do, what's it going to cost, and when's it going to be ready?" This article exlains why that's an unattainable expectation and corrects the misleading "product-lifecycle-model" for estimating.
Bill Walton
October 13, 2003

Pages

StickyMinds is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.