Archive

Archive for the ‘Testing’ Category

Good organizations + good practices == far better code??

August 29, 2011 2 comments

I was reading an article about the result of a research that Microsoft and IBM about team an organizations in software. This research was pointed to me by Phil Haack.

The results are sometimes stunning!

Higher Code coverage

Higher Code coverage by tests does not necessary mean better product quality. This is right because if 95% of an application code is tested and the 5% that was left out contains code that is very often use then we will most likely end up with a lot of defects.

Test driven development

Write Test before code takes 35% longer to deliver but 60% to 90% better in terms of defect density. I see a lot of managers, leaders, project managers saying: Ouch! that’s a lot more.

Of course! The performance of those people are measured by their ability to make money, deliver a project on time etc. while the performance of a developer is mostly measured by is ability to build a highly scalable, fun to use, bug free piece of code. Many times in my carreer I’ve encountered projects that were pushed back at the end because the end result was not stable enough! Imagine if the company that hires you had to pay back to their customers for every bug they had found in production. May be then they wouldn’t mind adding 35% more time to ensure quality!

Remember this: Making a good  software is like making a good wine and neither happen within a couple of hours!

The people factor

Looks like Bigger is not better in term of project teams size. That I totally agree! As a developer, have you ever been part of large team? The work is not clearly cut out by team members. One project owner contradicts the other one etc. Apparently bigger teams a moving slower and the project they work on are more complex then required and more failure-prone. Personaly, some of my best carreer sucesses as a developer were acheived while I was part of a smaller team or alone! Earlier this year I was studying on Agile and SCRUM methodologies. I asked a SCRUM group what size were recommended for the project team. The most frequent answers I received was a max of 5 devs for a total of 15 persons including pigs and chicken. The research results are also saying that larger teams will larger code base by a factor of 8%.!

Conclusion

Ensure Code coverage is at 100% or else run a profiler an make sure that the code that runs the most is covered!

35% more time for testing…Have a discussion with the projects managers to find out if they want to have a hit before or after the release.

Last words…

The conclusion of the studies is: “…yes, the design of the organization building the software system is as crucial as the system itself.”

Read the original study here.

Advertisements

All MIX 11 Session Video via RSS, iTunes, Powershell or Juice!


Thanks to Scott Hanselman, who brought this up!  http://www.hanselman.com/blog/Mix11VideosDownloadThemAllWithRSS.aspx

Like Scott said, If you really want iTunes in your life…you can subscribe in iTunes from Advanced|Subscribe to Podcast (look for MIX11 Sessions)

But I find it cooler with Zune! The video is super crisp in MP4 High! 🙂

Tell me the ones you liked the most! There is soooo much information. Almost everything applies on technologies available today!

My best (in descending order) are :

  1. An Overview of the MS Web Stack of Love,
  2. NuGet In Depth: Empowering Open Source on the .NET Platform
  3. ASP.NET MVC 3 @:The Time is Now
  4. Fun with ASP.NET MVC 3 and MEF
  5. Deconstructing Orchard: Build, Customize, Extend, Ship
  6. Good JavaScript Habits for C# Developers

My worse is:

  1. Application Design for Windows Phone (She is so nervous and thirsty…)

Write a Test Before Fixing a Bug…


 

It’s a shame that i just discovered this guy (Brendan Enrick). Brendan has a good blog post on testing with TDD.

Thanks Brendan.

I knew how to do it. And I want to share with all the good feeling I had when I did it.

The fact that you write a test first to confirm the bug, fix the bug, then run the test again to confirm that the bug is fixed, makes correcting bugs easy and fun! Wink

In my sense, this makes unit testing an Art! (notice the capital letter ‘A’…)

Also, If you happen to use Team Foundation Software, you can associate the test with the bug which also improves traceability.

Categories: Testing