Category Archives: test driven development

How Can Our Scrum Team Improve Product Quality?

XZ, a participant in a public Certified ScrumMaster workshop that I gave in Beijing last week, asked me how his scrum team could improve their software product’s quality. I thought that the answer would be of general interest, so here it is.

Hi Chris,

Thank you for giving us 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 setup, yet. Without automation of the regressions tests, unit test and pair-programming, how can our scrum team improve the quality of the product?


Dear XZ,

First, let me encourage you to keep up the work to automate your regression tests; few things have as big a return on investment. It enables the team to move much faster, and make changes and improvements in the code 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.

Code reviews
A code review is a meeting between 2 or more developers where they look at some code and talk about how it could be improved. This isn’t about finding fault, or showing how much better or smarter one developer is. The simple fact is that all code can be improved, and having multiple people look at it can lead to improvement. It also leads to learning. The participants in the code review share and learn techniques that will make them all better coders. Thus, all future code will be improved, not just the code currently being reviewed.

By the way, one more reason to consider pair-programming is that it gives you continuous real-time code review. I’ve seen a few teams adopt code reviews, and then move on to pair-programming, so that they could speed-up the feedback loop, and learning, that their code reviews were providing.

Frequent Testing by Real Users
If you want a reality check on the quality and usability of your new functionality, just grab a real user and ask them to accomplish something with it. This doesn’t have to be a big deal; 10 minutes might be all you need. If you don’t have a real user handy, get as close to real as you can. A team I was on had one of the customer support people try to use new features. They were close enough to ‘real’ to know how a real user would approach the task and what they would expect the software to do. Note, I’m not talking about full-blown user acceptance testing here. That’s good stuff too, but I’m talking about ad-hoc testing, as soon as possible. Just added the ability to make text bold? Grab a user (or support person, or your mom) and ask them to make some text bold, without explaining to them how to do it. You will probably learn something about the usability and quality of what you have built.

Testing Bashes
A testing bash, or testing party, is time set aside for the whole team to get in a room and test the product, in any way they can think of. The idea is to make it a fun, interactive, and social event. Who can find the most edge cases? The most unusual input? Let’s explore the edges of performance with big input, or on a machine that is running very slowly, or with low memory. Are there configurations we haven’t thought of? The idea is to encourage creativity. The testing bash should not replace your regular testing techniques, and alone it won’t provide sufficient testing to ship with confidence, but you may find it a worth-while addition to your testing regiment. One of the things I like about a testing bash is that it gets the whole team involved in testing the product. Which leads me to…

Whole Team Ownership of Quality and Testing
In my work with new scrum teams, I often find that ‘the team’ is really two teams: the coders and the testers. A team is a relatively small group of people working interdependently towards a common goal. For a good scrum team, the common goal is a shippable product. Of course, the product isn’t shippable until the coding and testing (and probably other stuff too) is done. If we allow the coders to think that they’ve done their job as soon the code is written, we are undermining the team and reducing our chances of shipping a quality product any time soon. We want the whole team to be responsible for creating shippable product. That means writing code, and testing it as well.

Very often, I see teams that can write new code at a much faster rate than they can test. In these cases, if the coders only code, the testers will never really catch up. Better that the coders stop coding and help the testers test! Several powerful things happen when coders do this. First, they start to take ownership for delivery of product, not just code. Second, the coders often find ways to accelerate the testing. You want to see good test automation come together quickly? Get your production coders to write the automation code! They will be motivated to do so if they don’t get to move on to new code until the current code is fully under test.

I hope some of these ideas are helpful to you.



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?

  • 60% to 90% fewer software defects according to an IBM/Microsoft study. That could make the head of your department giggle for the first time in months.
  • More confidence that code changes can be made swiftly and effectively without the recurring nightmare of current functionality heading south of the border.
  • Useful, functional specifications available to be executed by new team members. Now you aren’t the only cog in the software machine who understands how to make this particular hunk of code sing and dance.

Skip any of the steps in test-driven development – and you’re just blindly blazing new trails in the land of insane software development. Instead – make an investment in your sanity.

Agile Learning Labs presents “Test Driven Development in C#” on September 26-28 in Redwood City. Led by TDD-evangelist Rob Myers, this hands-on course delves into the techniques of fearless test-driven development – including test-first, refactoring, mock objects, and more. You won’t be talking about coding – you’ll be working in pairs to produce code using test-driven development techniques. After this class – you’ll be ready to tackle your “real life” software insanity head-on.

Not fluent in C#? Never fear. Rob promises a multi-lingual approach to the class. Get your C# on – or bring a little Java on the side. Whatever the language – this course will set you on a new course towards software sanity using test-driven development.

Early bird pricing for the Test Driven Development class ends September 12. Use code ‘StoptheInsanity’ to save an extra $300 on your registration. Register today!

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.

Agile practitioners tend to prefer a different approach, in which the current design emerges in response to the actual functionality being supported. The design reacts and adapts to the needs of the system, which itself is constantly evolving and adapting to the needs of the customers.

Chris addresses a common misconception, that foregoing up front design in favor of an agile process is tantamount to no design at all. Yes, yes, agile is anarchistic, the sky is falling, and kids these days listen to the darnedest music, we know, we know.

It strikes me that this type of sea-change has all happened before:

When the first impressionist painters broke the rules by dispensing with classical rendering and embracing naturalistic forms and gestures, a great many people refused to call it "art." But in hindsight, we now recognize the equal level of artistry involved in making art that departed from classical norms. Just because Van Gogh didn't block and draw on the canvas with charcoal before he took up his palette knife didn't mean he lacked an eye for shape, perspective and line: in fact, art students now are taught that "You must know the rules by heart in order to break them."  The expectation now is that artists will be able to break the rules, and thus they are now expected to know these things at the cellular level.

I predict that we'll look back on this change in our attitudes toward design and software in much the same way–we'll think of the curious olden days when developers were seen as code monkeys wrenching on software that someone else designed. By engaging developers in all aspects of coding, and including design and test, agile actually seeks to elevate design and function to a higher level of importance, to where it's part of everyday practice for everyone who writes code.

Share it!