When we schedule too many variables, things start to slip and soon the schedule is out the window. Paying attention to your project's constraints can help you set realistic scheduling goals that you will actually be able to stick to.

As a test professional in waterfall, I was used to getting the code much later and buggier than I expected and being under tremendous pressure to finish my testing before the go-live date hit. Then one day, I found out that there was a better way. Testers could be involved much earlier in the lifecycle, they could participate in requirements and design decisions as they happened, and the code could actually be unit tested before I received it! Heaven? Nope, agile.

In the March 2006 issue of Better Software magazine, Dan North began a discussion of the evolution of behavior-driven development from test-driven development. Here, North continues the conversation with closer look at "mocks," utility classes that, for testing purposes, pretend to be some component or service with which your object will interact.

Miscommunication is at the heart of most software defects. Being knowledgeable about a company as a whole, and not just about the specs of a particular project, is just one more way to safeguard against failures. Read on as Elisabeth Hendrickson explains the importance of technical people staying informed about business strategies.