Integration testing, or end-to-end testing, tests how well software components integrate. For large projects there may be several different components that are written by different people or even teams. There is a potential for a breakdown in communcation. For example one component may feed another component by placing a value on a database table.

While unit testing is focused on source code modules, integration testing is concerned about the system as a whole. In this testing data may be fed into the system to watch how it behaves when it reaches your source code and, in turn, how your code affects other components.

It is important to understand the system architecture as whole. Write a formal plan that describes two things: 1) what you plan to test and 2) what you expect the results to be. Document any results that differ from your expected results. They should either be fixed or explained.

Holy Batcars! Don’t miss tomorrow’s blog entry when I will discuss verification testing. Boffo!

This coming weeking I plan to discuss various topics in software testing. Today I am going to cover the fundamentals. Unfortunately, I do not recall formal testing being taught in college. My experience has come from on-the-job lessons learned.

To start with you should have at least three classes of servers. Your company and budget may be small. In that case the development and staging server could potentially share the same box.

TYPES OF SERVERS

• Development Servers
• Staging Servers
• Production Servers

A development server is a server on which code is developed. Once development is completed, then it is installed on a staging server. A staging server should match the production server as closely as possible. This includes, the same version of operating system, the same software and the same configuration. The staging server is your last chance to discuss bugs before it hits the production server. The production server is the server that runs your code live. It is what your customer uses.

By seperating the servers in this way you can test on the staging server and develop on the development server. This is particularly useful if the test takes a long time. The developers can start working on bug fixes even before all of the tests complete.

Stayed tuned for tomorrow’s topic: Unit Testing

There is an interesting project that aims to be the google of freely available source code. I have high hopes for krugle. It is a search engine that is smart about how source code is organized. Instead of just treating code just like lines of text, krugle organizes it into projects and displays it with syntax highlighting. Right now the site is in closed beta. I cannot wait to try it live.

Microsoft Research scientists say that schools and colleges are not training the next generation of scientists with the necessary computer skills. Hey Microsoft, how about you give us the next version of the Windows operating system before you judge? The last Microsoft Windows release was Windows XP in 2001! Computer journalists initially forecasted the next version in 2003. But after a redesign, streamlining planned features and a recent restructuring, we can look forward to seeing Windows Vista sometime next year.

One of my first tasks when I joined the staff of the U.S. District Court was to write a disaster recovery plan for the IT department. While everyone knows the importance of backups (right? RIGHT?), not everybody considers the importance of establishing offsite backups.

Offsite backups are critical for disaster recovery. You will need them in the event a disaster causes physical damage to your computers.

Things have changed since I wrote that first disaster recovery plan. Nowadays renting space on a managed Internet server is cheaper than tape backups. Take a look at file hosting providers and online backup and recovery services.

When dealing with project schedules, a dependency occurs when one task must complete before the next one can begin. Ideally you want to minimize the impact of dependencies on your schedule. One method is to schedule many tasks in parallel. If a developer is waiting for another task to complete, the schedule can give another task on which she can work.

Joel on Software says that dependencies are so obvious that he thinks that they should not be tracked. I agree that they can appear obvious to experienced project managers. But project managers are not the only people to use schedules. A new employee may want to use your schedule as a basis on which to estimate their schedule. Remember that your “customer” can also include your team and your company.

So, identify dependencies, document them and manage them with parallelism. Your project and your customer will benefit.

Lets face it. We are all different. We have different tastes and like different things. Wouldn’t it make sense that having choices would better please more people? In a recent article in the Linux Journal entitled “Separation of Church and Choice” the author made a case that choice alone is not a good reason to create software. While his article is churlish and bashes religion, it did make me think of an interesting question: Are too many choices in software bad?

The short answer is, of course not! I snicker when I hear about the supposed "tyranny of choice". Competition is good. The fact is that the strong will survive. The weak will adapt or find a small niche of supporters.

Having said that I see a case for cutting through the clutter. If you put together an integrated software system and plan to support it, then you will limit the number of supported choices. This makes fixing problems manageable. Also, provide a help system, e.g. a software wizard, to guide novice users by recommending common choices. It will keep them from becoming overwhelmed with new software.

Now, who wants some pie? What kind of pie?