Category Archives: test driven development

How Can Our Scrum Team Improve Product Quality?


Quality dial turned all the way upThank you for the certified scrum master training last week in Beijing. Your training is very impressive, and I appreciate it a lot. I asked you a lot of questions; may I ask one more? In our company, the automation for regression tests hasn’t been set up, yet. Without automation of the regressions tests, unit test, and pair-programming, how can our scrum team improve the quality of the product?



First, let me encourage you to keep up the work to automate your regression tests. Few things have as big a return on investment. Test automation enables the team to move much faster and make improvements fearlessly. The other practices you mention: unit testing and pair programming, are also great practices, and I encourage your team to try them too.

Having said that, your question was what else could your team do. Additional practices I would recommend your team consider are: code reviews, frequent testing by real users, testing bashes, and whole-team ownership of quality and testing.

Read the full article…

Share it!

Test Driven Development – Life Beyond the Insanity

“Insanity: doing the same thing over and over again and expecting different results.”
~ Albert Einstein


Are you a survivor of insane software development? Design-code-integrate-test-deploy. Maybe it’s time for a different approach.

Test driven development takes some of the insanity out of the software development process by shifting the emphasis on testing from post-development necessity to the first objective in the project. Create a test and see it fail. Then write enough code so that the test passes. Then refactor mercilessly.

The result?
Read the full article…

Share it!

What exactly is agile design? Or better yet, what could it be?

Chris just published an article on InfoQ called Refactoring is Not A Substitute for Design about the debate over what role design plays in agile development. The worry is that agile processes shortchange the very principles of good design, because so much of agile happens at the granular level while design is seen as a macro-level activity. But is that the case? Here is the bit that I consider Chris' main point: Big Design Up Front is not design; it is just one way to accomplish design.

Read the full article…

Share it!