Please enter an article title, author, or keyword
Computer Bribery

"There's a little something in it for you if the product is ready for testing next week." To make a date, have you ever resorted to offering or accepting such a payout? You don't often encounter the technique in management books, but we all know that people can be motivated by money. In this week's column, Sheryl Smith imagines a scenario where the equipment is "bribed" to speed delivery. Read on for the point of view from inside the computer.

Sheryl Smith
Estimating Tester to Developer Ratios (or Not)

Test managers often need to make an initial estimate of the number of people that will be required to test a particular product, before the information or the time to do a detailed task breakdown is available. One piece of data that is almost always available is the number of developers that are or will be working on the project in question. Common sense suggests that there is a relationship between the number of testers and the number of developers. This article presents a model that can be used in describing that relationship. (Editors note: Click here to read another paper on this topic, by Cem Kaner, Elisabeth Hendrickson, and Jennifer Smith-Brock.)

Kathy Iberle
Preventing Web Service Security Breaches with Unit Testing

As Web services increase in complexity and connectivity, security is growing as a major concern. Many security breaches have been the result of poorly tested software that allows unexpected inputs to pass and weaken security measures. Such inputs can create conditions in which intruders can obtain access to parts of the system that would otherwise be secure. One effective way for development teams to prevent unexpected inputs is to perform thorough white-box testing at the unit level. Unlike specification testing (which tests that code behaves as it was intended), white-box testing checks for the conditions and inputs that are not expected, thereby enabling developers to more thoroughly test for what they cannot foresee. By performing such testing at the unit level, developers can quickly and easily identify and correct any weaknesses before security breaches have the opportunity to occur.

TechWell Contributor's picture TechWell Contributor
What Does Your Title Say About Your Job?

"That which we call a rose by any other name would smell as sweet." True, sloppy naming schemes may be all right in some cases. But as Johanna Rothman explains in this column, when software professionals are looking for a job, hiring, or negotiating work assignments, it's crucial for their job titles to accurately portray the work they do. Read on to see if you agree with the definitions Johanna assigns to the more common QA-related job titles.

Johanna Rothman's picture Johanna Rothman
The Missing Link

The testing environment of many corporations is all too often composed of young employees thrust into the technical world fresh out of college. They are eager and completely overwhelmed with their new environment. Managers are called upon to teach these employees the ways of their company testing. The result is predictable. Managers with limited skills wind up with a work group that reflects these limitations. Even skilled managers with seasoned workers are facing significant problems. It is estimated that over eighty-five percent of all IT projects are delayed or delivered without meeting the predefined specifications by those authorizing the work. In addition, managers do not typically receive training in newer management methodologies such as project management. One organization that faced just such a dilemma was Software Engineering Services, Worldwide Revenue Capture Systems, Information Technology Division within Federal Express Services. Over a period of eighteen months, this department went from not meeting project load dates to an organization that delivered software on-time with fewer software defects. It is the purpose of this paper to provide a blueprint for other organizations looking to reengineer their testing processes based on this experience.

Karol Vastrick
Overview of STIR Improvement Is a Journey

So, you want to improve the quality of the testing done by your organization? The test quality improvement journey has several aspects to consider: the identification of improvement actions, which improvement action to start with and how to continue to improve. This document focuses on those improvement actions and ways to implement and improve on an existing set of good practices.

Karen Rosengren
Managing Distributed Software Development

Distributed development teams are becoming the norm for today's software projects. In lieu of close physical interaction, distributed teams are faced with the challenge of keeping software projects on track and keeping remote developers involved. This article provides some suggestions for keeping distributed software teams in touch and on target.

TechWell Contributor's picture TechWell Contributor
XP, Iterative Development, and the Testing Community

A recent StickyMinds column criticized the new Agile development methods as bad for business. The column generated many reader comments, and prompted this response from industry veteran Cem Kaner. Read on for his defense of iterative approaches.

Cem Kaner
Not Getting What You Want?

The project plan is clear and the specifications are detailed. So why is the final product so different from what you expected? In this week's column, Nicole Auger brings a product manager's perspective on how features get changed or added during the development process. And she gives tips on how to get what you ordered, instead of a substitute.

TechWell Contributor's picture TechWell Contributor
What To Do When What You're Doing Isn't Working

If at first you don't succeed, try, try again. But if you keep trying the same things that worked for you in the past, and they're not working for you now, you might never succeed. In this column, Eileen Strider shows you how to tap new sources for fresh approaches to tackling problems.

Eileen Strider


Upcoming Events

Apr 26
Jun 07
Oct 03
Nov 14