New! and Improved!

Now that our book is almost out (and it IS out on Safari Rough Cuts), I've decided to start a new website, where I will blog as well as posting articles and interesting links. This blogspot will be deprecated and I'll be transitioning over.

Please visit the new site, lisacrispin.com, and comment. I'm developing it with agile practices and I need "customer" feedback!

My old website will remain as a prime location for new action photos of the wonderfully agile miniature donkeys, Chester and Ernest!

A Plague of Updates

I have a basic distrust of OS updates. My coworker Joe used to religiously update his Windows box, and it died several times. I never used to update mine and it just kept marching along.

Now, I know that's bad, I need to do the updates for security and so on. So I am better about doing it on my PC and Mac. As for my Linux box, one time I asked our sys admin Tony if I should install the updates, but he said no. Then recently, he noticed I had over 100 pending updates, and said I should update. I pointed out that he had recommended against that earlier, but he couldn't remember any reason he would have said that.

After updating, my network connection no longer worked. Tony suddenly remembered why he had told me not to update. He worked some magic and I was connected again.

That was only a couple of weeks ago. I forgot about the bad part of that updating, so yesterday when I noticed some pending updates, I let it go ahead and update. Even after I lost my network connection, I couldn't remember from two weeks ago that the updates had caused that, so I had to call Tony over again.

This time I watched what he did, and when I twittered about it, Jeffrey Fredrick suggested that blogging about things that you might forget is a good idea. So next time I let my Linux box do updates, and can't connect to the network anymore, I'll remember to su root, go to /root/l1-linux-v1.2.40.2, and make install. This is only needed for kernel updates. Note to self!

I'm trying to get organized in other ways too. Janet Gregory has her own personal storyboard, just stickynotes on the wall next to her desk. I've adopted this at work, it really helps. I'm going to do it at home, too, I'm thinking about using the microwave door for it!

Tester-Developer Ratios on Agile Teams

A question that came up yesterday on the Agile Testing Realities discussion, and that comes up a lot everywhere, is "What is the ideal tester-developer ratio on agile teams"?

Naturally, the answer is "it depends". Here are some factors to consider:

• Are the developers doing a good job of TDD? Does the team use acceptance tests to drive development, also?
  
• How good is the automated regression test coverage?
• How good is the communication between developers and customers?
• Is the application testing-intensive, or does testing go pretty fast compared to coding?
• Do the developers help with testing activities such as automating acceptance tests?
  

My current team works with a financial services web app that is quite testing-intensive. The functionality is complex, and since we are dealing with peoples' money, we have to get it right. For some stories, testing takes more time than coding. Our programmers are quite experienced in TDD and our regression test coverage is excellent. While our developers and customers sit close to one another and communicate well, and the developers have a high degree of domain knowledge, our stories are often quite complex. A lot of tester time is devoted to working with customers to get examples of desired behavior and sort out technical challenges and other questions. The developers take on a lot of testing tasks, including automating FitNesse tests and often writing the FitNesse test cases themselves. We have five programmers and two testers, and even so, the developers often have to pitch in extra on testing.

I worked on another team of 20 more more developers (subdivided into smaller teams but all working on one project) where I was the only official tester. While the team did a good job of TDD, and we had good communication with customers despite the fact that we were a distributed team, this was clearly not enough. Fortunately, we were developing a non-critical internal application that would be used by a few expert users, so it wasn't the end of the world if the functionality wasn't perfect. One or two developers or business analysts wore a tester "hat" each iteration and performed testing activities. I worked hard to transfer my testing knowledge to everyone on the team, so that our unit tests covered more test cases, and we could automate at least some of the functional regression tests.

My third successful agile team consisted of 8 programmers and me, the tester. At first, the programmers could not get a handle on TDD or even unit test automation after coding, and I was buried. I asked our coach for help. He helped us figure out how to get traction on unit testing, by providing training and time to learn. Once the team mastered TDD, and pitched in on functional test automation, I was able to handle the other testing activities and we all worked well together.

Those are my stories on tester-developer ratio. Got any of your own to share? Please comment.

Agile Testing Realities

Today I participated in an Agile Testing Realities live Q&A discussion with Elisabeth Hendrickson, Tauseef Kahn and Tom Wissink. It was fun and interesting, especially hearing Tom's experiences working on huge government projects (how fun would it be to work on the Hubble Telescope?)

I was frustrated, though, because there were so many excellent questions being posted, and we only got to a fraction of them. So, I've decided to start addressing some of the question areas here. If you posted a question in the session today and didn't get it answered, feel free to send it directly to me. Another good forum is the agile-testing Yahoo group.

Test automation is a big challenge for everyone and I noticed questions related to "How can I get tests automated with back-to-back, short iterations? I don't have time". Obviously, I can write whole book chapters on this subject, but here are a few key points for a successful automation strategy:

• The whole development team, not only the testers, needs to tackle test automation.
• Start by implementing a continuous integration and build process so you have a way to run your tests automatically, and get quick feedback from them.
  
• Unit tests have the best ROI, so start test automation efforts there. For legacy code, try a lightweight automation tool and do simple smoke tests that don't have a lot of logic in them and are easy to maintain. You'll be surprised how many regression bugs they find.
• Cut down the scope of work your development team commits to in each iteration so you make sure there is time to finish all test automation tasks. Don't put them off until the next iteration - that's the road to perdition.
• Repeat this mantra, write it on your story board or whiteboard: No story is done until it's tested! This includes automating regression tests for it too!

Test automation obviously has many more facets. What about exploratory testing, what about non-functional tests such as performance and security testing? We'll need more blog posts for those.

'Tis the Season

I just ran across this cool inspirational story.

HP has a "magic giveaway" where they give top bloggers $6,000 in HP products to review, and in turn, each blogger runs their own contest to give this equipment away.

Liz Henry's winner is Sara Moriera, a Portuguese professor who teaches computer engineering in East Timor. Sara is using the computers and other equipment to help young women in East Timor.

What cool women these are to be able to use technology to help educate other women who are in the most difficult of circumstances. What a difference the computers and other equipment will make for them.

Now that makes me feel this really is the season of giving (not that all year shouldn't be). Hooray for HP, Liz and Sara.