Process

Articles

Free time Free Time is Not Free

Unpaid overtime has negative personal and business consequences. Although regarded as free time by many organizations, there is a true business cost to not estimating or counting overtime hours, whether paid or not. Ed Weller presents the argument that those who do not count free time in their planning and tracking will make poor decisions and often invest in the wrong projects.

Ed Weller's picture Ed Weller
Ping-Pong Programming: Enhance Your TDD and Pair Programming Practices

Team player Dave Hoover wants to share a software development practice he enjoys. It emerged from the practices of extreme programming as a competitive yet simultaneously collaborative practice. Dave has found that this practice promotes the flow of knowledge between software developers better than any other practice he has experienced. As you might have guessed from the title of this week's column, this practice is called ping-pong programming, or P3 for short.

Dave Hoover
QA Preventing Failure Suffering for Success

One of the most valuable services a QA group provides is preventing failure. Ironically if the group succeeds at this, QA might find themselves unpopular or out of a job. Linda Hayes reveals how typical methods of measuring success can actually cause failure. Especially if success is achieved at the loser's expense.

Linda Hayes's picture Linda Hayes
TimeLine Postmortems

We should use project postmortems to improve our software process. But few teams do, and fewer teams reliably learn from project postmortems. You can introduce postmortems to your team easily with a timeline postmortem process. If you are already doing postmortems, a timeline-based approach may improve your results.
This process:

  • Takes little time (a few hours).
  • Has a high degree of software engineer acceptance.
  • Provides immediate feedback into your development process.
  • Increases team cohesion and rapport.
  • Reduces finger pointing.
Seth Morris
test automation Not Your Father's Test Automation

If you think that test automation is mostly about executing tests, then you're missing out on a big opportunity. Or rather, you're missing a lot of small opportunities adding up to a big one. Consider this: stop thinking about test automation as merely executing automated tests, stop thinking about test automation as something you need expensive tools for, and start discovering automation you can implement in a couple of days and usually with extremely inexpensive tools or tools you already have available. In this week's column, Danny Faught and James Bach suggest taking a more Agile approach to test automation.

James Bach's picture James Bach Danny R. Faught
Agile Codeline Management

Software developers often view version management tools and techniques as a necessary evil. This is particularly true of developers practicing agile techniques. However, version management, can be an aid to agility rather than something that gets in the way.

Steve Berczuk's picture Steve Berczuk
Tinkerable Software

In what ways should software be like a house? In a recent issue of STQE magazine, Technical Editor Brian Marick's musings about the concept of "tinkerable software" generated some interesting discussion about the very nature of software design. This week's column runs a portion of that piece so that our Sticky-minded readers can sink their thoughts into the concept.

Brian Marick
Bug Counts vs. Test Coverage

Occasionally, we encounter projects where bug counts simply aren't as high as we expect. Perhaps the product under test is in its second or third release cycle, or maybe the development team invested an inordinate amount of time in unit testing. Whatever the reason, low bug counts can be a cause of concern because they can indicate that pieces of functionality (which potentially contain bugs) are being missed. When low bug counts are encountered, management may begin to wonder about the quality of testing. This article covers techniques for dealing with low bug counts, and methods for reassuring management that coverage is being achieved.

Andrew Lance
Can You Negotiate Quality?

XP teams have the right to do their best work. On the other hand, customers have the right to specify and pay for only the quality they need. How does one reconcile two potentially conflicting points of view? Is quality negotiable? If so, how do we go about negotiating it? This paper will explore the following questions: Is quality negotiable? How can we negotiate quality? What are internal and external quality, and are either or both negotiable? What's the XP tester's quality assurance role? How far should testers go in helping the customer define acceptance criteria?

Lisa Crispin's picture Lisa Crispin
The 11th Hour

Testers are often on the critical path for getting a software release out. They must plan carefully in order to minimize the critical path, while still doing a complete job of testing. This schedule pressure is taken to an extreme when a production server must be taken offline in order to deploy the software, and everyone is waiting for the final test results before the system can go live again. Karen Johnson describes her company's carefully planned and orchestrated method for doing a final check of an installed system. Her story is relevant to e-commerce companies as well as IT shops that are under pressure to keep systems updated while minimizing downtime.

Karen N. Johnson's picture Karen N. Johnson

Pages

AgileConnection is a TechWell community.

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