The Latest

Manual software testing can never catch all errors–so can automation help? David Norfolk looks at the pros and cons of automated testing and offers advice–and warnings–on its use.

Writing isn't easy--let me just make that perfectly clear. Anyone who tells you that writing is easy is either lying to you or doesn't understand what quality writing entails. Writing requires careful thought, a great deal of planning, constant review of your work-in-progress, and a great deal of skill, which can only be gained through experience and practice. Sounds a lot like a description of software testing, doesn't it? The truth is that there are a number of similarities between quality writing and quality software testing, and skills in one discipline can help you a great deal in the other, both directly and indirectly. While written documents may or may not be required within your test team, the process of writing can be extremely beneficial in itself.

Do you feel stressed out by pressure to deliver more reliable software faster and cheaper? Customers for software-based products make these conflicting demands, and they trickle (or rather flood) through the management chain down to you. Software reliability engineering (SRE) can help.

The postmortem exercise, used to summarize project successes and failures, is not the only way to gain process efficiencies crucial to the success of any IT project. Many times prenatal exercises are in order. Prenatal exercises are a simple yet powerful way to organize the activities and communicate expectations associated with any project before the project begins.

It makes sense that people who are always correct will have the power to influence others. But testers who base their authority on correctness might be in for a rough time. Bret Pettichord explains in this week's column why it's a good idea to show concern as well as correctness.

"Our Take" is a regular column from the editors at Software Quality Engineering. It appears in the twice-monthly StickyLetter since its inception in September 2000 (originally "STQe-Letter"). From jazz music, to car troubles, to the Lewis and Clark expedition, Robert Rose-Coutré, former StickyMinds.com Editor, will use anything to make a point about building better software. The editors at Software Quality Engineering have compiled a collection of some of these pieces. Musings from StickyLetter's "Our Take" are presented here.

When errors are not detected during testing, somewhere down the line someone has to take responsibility. In this week's column, Linda Hayes shows you when and how to do so...and you might even be able to turn the situation to your advantage.