Process

Articles

Estimating Testing Time

Testers are always facing a time crunch. As part of a recent assessment, a senior manager asked, "How long should the testing really take? It takes our testers from four, five, six, to thirty (insert your number of choice here) weeks, and we need it to take less time. Why can't it take less time, and how can we tell what's going on so we know how much testing we need?" In this column, Johanna Rothman answers with a timeline. By estimating how many testing cycles will be needed, plus how long each will take, she can map out the entire testing process. From this viewpoint, she is able to pinpoint where the process can be streamlined thus reducing the time spent testing.

Johanna Rothman's picture Johanna Rothman
After the Bug Report

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.

Danny R. Faught's picture Danny R. Faught
Cook until Done

There's no shortage of advice on how you should model, design, test, build, and deploy your software project. Every author, trainer, and pundit will swear up and down that "they know the secret." They know how to build great software—they've done it before and all you have to do is follow their lead. Buy their software, read their books, buy their tools, attend their seminars, and do it just like they do it and you'll be a success, right? But somehow it doesn't seem to be that easy. In this column, the first in a series of articles that will explore the different avenues of software development, Andy Hunt and Dave Thomas, the Pragmatic Programmers, begin the journey by revealing that learning software development isn't as easy as the pros make it out to seem. Find out why these books and seminars work for them, but not always for the rest of us.

Andy Hunt Dave Thomas
The Goldilocks Parable: How Much Process Is Just Right

Getting process improvement "just right" is difficult. Go too far in the definition of processes, and it really does get too hot, with the heat coming from the people trying to use the processes. On the other hand process definitions that are too short to contain anything of value will leave users in the cold, and then there will be no improvement in the organization. Ed Weller states that a useful process improvement activity develops a set of process artifacts that meets the needs of the user. This helps the organization capture "tribal lore" and cast it into a set of process definitions that eliminates waste and improves time-to-market.

Ed Weller's picture Ed Weller
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
Test-Driven Development Isn't Testing

There's a common misconception that test-driven development is a testing technique when in fact it's a design technique. In this column, Jeff Patton explains this and how you might use your unit tests to explicitly guide and describe the design of your software.

Jeff Patton's picture Jeff Patton
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
Bumper Stickers for Testers

Why is software testing perceived as dull? How many other jobs can list "crash," "hang," and "death march" in their daily vocabularies? In this week's column, Harry Robinson encourages testers to embrace a little pride and excitement in what they do, and Harry has just the mottos for bumper stickers that announce Tester Pride. Author's note: Feel free to add your own favorite slogan in the comment section at the end!

Harry Robinson's picture Harry Robinson
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

Pages

StickyMinds is a TechWell community.

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