The Latest

Many bemoan the strained relationship between testers and developers. But while we can't force testers and developers to see eye to eye on everything, we can reduce some of the tension by making simple changes in the way we communicate. Learn some great tips and tricks in this article.

Ever try to navigate the Web with your eyes closed? Without a mouse? Fifty million Americans are differently-abled, and nearly half of these people encounter difficulties accessing the World Wide Web. The U.S. government recently took steps to tackle the accessibility issue. Here's some coverage of the issue.

You have an approved project that is about to begin - the project team is in place, the product owner has been identified - the stakeholders are eagerly waiting to see results of this agile approach that they have all heard good things about ...

Here's your dilemma ... the stakeholders are expecting to see tangible progress at the end of the first iteration in two or three weeks - having been through presentations of Agile processes. But you know that it's really not feasible to deliver anything remotely useful in that short a period. Agile processes warrant early delivery of business value, stressing on working code. Release planning and iteration planning are all based around user stories completed to the extent of being ready to deploy. But the reality is often different.

A software project is a complex thing. It involves many players, many tasks, and lots of things that could go wrong (and often do). If not for dogged optimism, some projects might not be tackled at all. But optimism doesn't mean turning a blind eye to potential pitfalls. In this column, Esther Derby applies a lesson about asking, "What if..."

Why do some teams "catch fire" and excel, while others never seem to gel? Ms. Dekkers and Mr. Lister talk about this, as well as other topics from Mr. Lister's book, PeopleWare.

Are you inadvertently setting up a one-dimensional team? Managers regularly make statements to recruiters like, "I need another test engineer just like Charlie." Sometimes hiring people with very similar qualifications makes sense, but sometimes breaking the mold makes a better team.

Is the tester doing a good job or a bad job when she proves that the program is full of bugs? It’s a bad job from some developers’ points of view. Ridiculous as it seems, there are project managers blaming testers for the late shipment of a product and developers complaining (often jokingly) that “the testers are too tough on the program.” Obviously, there is more to successful testing than bug counts. Here are some tips about how testers can build successful relationships with developers.