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..."