It's happened to all of us. You're at competition, something breaks, and you rush frantically to fix it. With the drive team breathing down your neck because they have to go queue, you put the last bolt in place and the robot is wheeled out of sight and onto the field. So you sigh, and run to the stands, only to see the robot sitting there twitching instead of running, because something in the repair wasn't correct. Something that could have been found with a 30 second test.
With the time constraints we have during the build season and at competition, it's extremely easy to forget to test, or to not leave enough time for testing. Sadly, this isn't a phenomenon experienced only in FIRST. Corporations constantly release products with bugs in them that could have (and in some cases really should have) been identified and fixed with a testing process. A great example of this occurred yesterday - Antivirus maker McAfee released an update that shutdown 100's of thousands of computers. (see
http://blogs.zdnet.com/hardware/?p=8108 for reference). The impact of this is huge for affected companies.
So, as you start to plan for next year, I want to encourage everyone to take this as a lesson, and add some time to your schedule for testing. During the build season, spend some time figuring out exactly how you'll test each component. Figure out and write down somewhere what the test results should be. If you need to test something with the drive train, is it enough to spin the wheels with the robot on blocks, or do you need to set it down and actually have it move? If you're testing a manipulator of some sort, what field elements do you need readily available to confirm that it actually works? Spend some time now thinking about these things - I can guarantee 9 months from now you'll be too busy to figure it out.