Book, Coder to Developer

Since my computer was out of commission during the first part of this week, I took time to catch up on some reading I wanted to do. One of the books I finished reading was Coder to Developer: Tools and Strategies for Deliver Your Software by Mike Gunderloy.

I had mixed feelings about this book. It contains a lot of good information, but the information seems to be limited in its application. If you are a lone developer, or maybe a contractor working in your own environment, this book contains good information to help improve the quality of your work. However, if you are working in an established environment, a lot of the information probably wouldn’t apply.

Since I’ve been thinking about working on a small project in my spare time I got a lot out of this book, but if you are not planning on working on a small project I would recommend going to Borders, picking up the book and a cappuccino, and reading through some of the different chapters while you drink your specialty coffee. I found the first few chapters and the chapter on code comments to be the most valuable.

Overall, the book has some chapters containing good information and it was worth the time I spent reading through it.

Book, Effective Software Testing

Since my computer was out of commission during the first part of this week, I took time to catch up on some reading I wanted to do. One of the books I read was Effective Software Testing: 50 Specific Ways to Improve Your Testing by Elfriede Dustin.

The book really does not contain much new information but I did like the way the book is laid out. The chapters start with testing the documentation before any development begins and cover all the way up to testing the actual application. Each chapter is broken down into smaller items and each item can be read individually of the others. Each item has explanations of what the testing department should be doing and some suggestions on how to do it. This makes it easy for a reader to find isolated information and digest it without needing to read the entire book. After reading the book, I recommended it to the newer testers on the team because the information contained inside is valuable, especially for people without much testing experience. This book would also be a good fit for managers who might not have much experience in testing so they can get a better feel for what should be involved in the testing efforts.

I found the book to be a little dated even though it was published December 18, 2002. I also found the information to be geared more towards testing whole applications, to the extent there are a few sections in the book where the author warns people about Third-party controls.

Overall, the time spent reading this book was time well spent.

StarEast, Estimating with Confidence

During one of the group sessions at the StarEast conference, the presenter suggested all time estimations should be accompanied by a confidence level percentage. The idea behind this was to help put the time estimate into context because sometimes we are asked to give an estimate without having enough information. So, for example, if someone estimated it will take three weeks to test but they are only about 30% confident in the estimate, people would know they need to do some more planning and gather more information. However if the confidence level was 80%, they would know this is something they could work with.

The main thing to remember is to be truthful because if you always give inaccurate time estimates with inaccurate confidence levels, before too long neither one will have any meaning.

Below are a few main goals for specifying a confidence level:

  1. To demonstrate how accurate you feel the time estimates are at any given point. As more information is provided, the level should go up.
  2. To cause a warning flag to be raised by the team when they see a low confidence level. Hopefully this will lead to them ask what is needed to get the confidence level up.
  3. To provide a way to meet a requirement (project estimation) early on without putting any false pretenses in anyone’s mind.
  4. To help build confidence among the team when they see a higher level of confidence in the estimation.