The names we give to things can have a powerful influence on how we think about them and also on how we get others to think about them. In thiscolumn, tester, test manager, and consultant Fiona Charles examines names we have given to two essential roles in software development and explains why at least one of them is both inaccurate and a problem for testers.

If you hear that someone doesn't have "both oars in the water," you know he's out of control, he doesn't "get it," or he's going in circles. Why? To move forward in a rowboat, you need both oars in the water to steer and to gain speed. In this week's column, Mary Gorman explains how this concept applies to modeling requirements.

Traditionally, relationships between testing and coding teams often bordered on frosty. But the wall has started to come down, especially in organizations that have embraced agile principles, values, and practices.

Software development teams don't always need, want, or have time to make decisions via group consensus. And project leaders often already feel over-burdened with the multiple decisions they have to make on their own. But there is a middle path-an alternative to consensus-in which shared responsibility for decision-making provides for input from many and one voice to represent the team and make the final choice. In this decision-making process, a team member volunteers to be the decision-maker on a particular issue with only one mandatory rule-seek guidance. The greater the impact the decision will have on the organization, the wider the quest for advice must be-all the way to the board of directors, if appropriate. Join Michele Sliger to learn how this approach to decision-making might be right for your organization.