Test Planning
Articles
|
A Test Manager's Output: What Is That? Are you a project manager or test manager who feels like you're in constant motion? While your team works on products, your week is likely filled with meetings, conference calls, email, analysis, and consultation. But when your efforts have more to do with team performance and avoiding disasters than a tangible product, how can you measure what you've done in a concrete way? |
||
|
What's in a Name? Everything. Quality Assurance Manager. Senior Developer. Test Manager. Think you know what those titles mean? Are they mutually exclusive? If not, where do they overlap? Which one "owns" Quality? An important step in perfecting the software development process is negotiating and understanding the responsibilities of every team member. In this column, Elisabeth Hendrickson talks about unwrapping the responsibilities beneath the job titles. |
||
|
Snaring Black Widows in Ladybug Clothing The mood in the meeting was grim. All eyes were trained on Doris, the head of customer support. Doris surveyed the room as she spoke..."We have a problem in the field with the new release. Sixty-three users reported unrecoverable errors this week—a record high. An additional 152 people reported crashes, but the software recovered after reboot. This morning, I talked to an irate user who said he'd uninstalled our software after it crashed on him five times in a row. He wanted us to give him a full refund plus expenses. In short, the users are really angry. What do I tell them? When will we have a fix?" |
||
|
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. |
||
|
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. |
||
|
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." |
||
|
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. |
||
|
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. |
||
|
Running Down Assumptions Do you think the assumptions you make about your software project are important? I do. One of the biggest sources of software project failure is hidden assumptions, especially about your requirements. These assumptions have a way of coming out of the woodwork–usually at the worst possible moment–to foil your projects. But there are ways to track down and expose assumptions. |
Brian Lawrence
November 3, 2000 |
|
|
Shhhhhh! You Can't Say That! Treating symptoms instead of the root cause of symptoms is a mistake that dates back millennia (just ask Socrates). The current-day workplace is no different. In Johanna Rothman's column, we get a glimpse at what happens when a company doesn't value its people. |
Pages
Recommended Web Seminars
Featured Resources
Visit Our Other Communities
StickyMinds is a TechWell community.
Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.