testing

Articles

When Helping Doesn't Help

The term "codependency" was coined to describe an unhealthy coping pattern--one that focuses much on compensating for another party's shortcomings or weaknesses. This week's column asks the question, "Are you involved in codependent relationships with your software developers and project managers?" If so, you may be causing long-term harm in your effort to "do the right thing" for the project at hand.

Lee Copeland's picture Lee Copeland
A Child's-Eye View of Software Testing

You've had to explain and justify your job to Management, to Human Resources, and to everyone at your high school reunion. But now comes the ultimate test: Your child's assignment for the next show-and-tell is to describe what her mom or dad does for a living. You scramble for an easy way to explain—maybe for the first time—what you do at the office, but your software testing reference books just don't have enough pictures of cute animals to really do the trick. This book might be just what you're looking for.

Alyn Wambeke
Getting a Late Start on Test Automation

Successful test automation requires team commitment, teamwork between testers and developers, and getting an early start. That's what Bret Pettichord said in a previous column. Bret notes that a reader, Jack Baseley, replied with a very good question: "How do you propose to deal with late starts?" Do we just give up? Bret picks up where he left off and devotes this column to answering that question.

Bret Pettichord's picture Bret Pettichord
Looking for What's Not There

This column asks the all-important question, "What isn't there that should be?" The same idea for spotting black holes also applies to spotting "holes in designs and requirements." For example, there are often connections between the quantity of bugs filed against an area and whether the area is thoroughly tested. There can also be holes in what KIND of bugs have been reported. Hendrickson lays out the territory for the search and goes on to suggest how to "look for where there's a lot of nothing."

Elisabeth Hendrickson's picture Elisabeth Hendrickson
Test Planning in a Fluid Environment

As a test manager, I know the product needs to be released on schedule. I'm trying to stay on schedule, but there are changes in the software. I have to keep my test team apprised of the changes and revise the test plan…again. Now it's time to plan for the next test cycle. This article offers four keys to a successful test plan: Involvement of Test Team from the Beginning, Integration Testing, Identification of Handoff Criteria, and Interaction Among All Players.

Chris DeNardis's picture Chris DeNardis
What Do You Manage?

You're a test manager. But do you manage only the testing? A frustrated test manager recently said, "With my SQA hat, I want to focus on finding defects and discovering risk in the product. With my support hat, I want to solve problems. With my tech pubs hat, I'm trying to get the documentation written. But last week, everyone needed my help at once. I'm only one person—how the heck do I do all that?" Well, maybe you shouldn't have to.

Johanna Rothman's picture Johanna Rothman
Three Keys to Test Automation

How can you get your test automation project off on the right foot? I've been asked this question many times. It has prompted me to review the test automation projects in which I've been involved and identify the factors most associated with success.

Bret Pettichord's picture Bret Pettichord
Is Software Testing Advancing or Stagnating?

The quality movement started in 1924 when Walter Shewhart gave his boss at Bell Labs a memo suggesting the use of statistics to improve quality in telephones. Later came Juran and Deming, and the movement was well on its way. Not surprisingly, the software industry eventually took up the challenge of systematically improving quality. Let's look at how that began.

Steve Whitchurch
The Open Source Test Tool Paradigm

Testing is often seen as an effort to determine the quality of the product at the end of a project, so it needs to be executed when development has finished instead of being a means to deal with risks at the earliest stage possible. Therefore, project budget, is in most cases spent on the processes that actually produce tangible products, at the expense of the testing budget. Whatever budget is left for testing will be spent on people rather than on test tools, especially since most of the mainstream tools are often perceived to be too expensive. A solution to this may be found in the use of open source test tools. With no license fees, the use of open source tools can provide a customer some of the benefits of test automation, without the costs.

Reinder Otter's picture Reinder Otter

Pages

StickyMinds is a TechWell community.

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