Test everything

The picture below is from a computer backup I was doing over the network.


This was with the existing file on the target drive being overwritten. For new files the transfer rate is nearly constant and a little above the peak shown here.

I suspect the algorithm used by either the driver or the controller for the hard disk for update an existing file results in a large number of seeks of the head. The file copy program (Robocopy in this case) could work around the problem by deleting existing files before doing the copy. But the designers of the program may not have been aware of the problem with this particular hard drive.

In my situation I don’t care a lot because it can just run as a background task and it doesn’t much matter if it takes 10 minutes or 300 minutes (yes, the transfer rate is over 30x slower). But for some people it might.

As always, thoroughly testing your products, processes, and assumptions is important and either this one wasn’t fully tested or management marked the bug as “Won’t Fix” and shipped it anyway.

Having presided over numerous Boomerite failures I know how easy it is to say, “This change shouldn’t matter” or “This has to make it better, no need to test it.” There is a reason many companies have a test team that is independent of the development team and may even have a reporting chain independent of engineering.

This, almost, paranoia about testing can be generalized to a lot of things in your life. Have you ever changed a tire on your current vehicle? I bought a used vehicles a few years ago and discovered a day or so after I bought it that it didn’t have a jack in it.

You have a gun to defend your home and loved ones? Have you ever pied the corners of your home with that shotgun? Have you looked at possible choke points for stopping a home invasion? How about looked at what happens to misses or shoot-throughs from likely shooting positions? How do those speed reloads you practice for USPA matches work out for you when you are at the top of the stairs in your birthday suit?

Progressives want the government to have more power to implement “social justice”. Ask the tens of millions of people that went into the Gulags of the USSR how that worked out for them. Oh, that’s right, most of them that weren’t shot after their forced confessions were worked and starved to death. We don’t need to run that test again. 100+ million people have already been killed during the testing done by various progressives regimes in the 20th century.

Anti-gun people want to register guns. Ask Canada how that worked out for them.

Does your bug-out kit included canned goods but you forgot to include a can opener?

You’ll discover many such things when you test.

5 thoughts on “Test everything

  1. You’re almost certainly not overwriting an existing file but rather creating a new file which replaces the old one (i.e., the old one is deleted in the process). The result is that you’re doing file system operations to free file space. You may also end up with more fragmentation. If the backup program and OS are constructed right, that won’t make much difference. File system operations like delete should all be buffered so the overhead is not really visible, and disk I/O should be queued so seeks are sorted for efficient access. But if the backup program doesn’t build substantial I/O queues, that won’t happen. If so, the fault is in the backup program; a program with inadequate queues will never have good performance.

    Your observations about QA are well taken. In our company, we started building the QA team within months of starting product development, and it followed the separation principles you mention.

    On Canada: that may be the intent. I think people speak of “unintended consequences” too often, when the consequences are in fact intended (though not spoken of).

    Testing and backup reminds me of a review of backup programs I read maybe 15 years ago. The review article looked at speed and ease of use and how well a restore operation worked. Restore counted for 30% or so of the total score. The article mentioned a few programs that did not reliably restore, so they lost some of their points (most of the 30%, I suppose). That makes NO sense; for a backup program, restore is pass/fail. If you *ever* fail to restore in a product test, your score immediately goes to zero. No excuses, no exceptions.

  2. There is a reason many companies have a test team that is independent of the development team and may even have a reporting chain independent of engineering.

    But *not* independent of sales. If testing starts pushing the delivery date out because they’re finding the design is crap it’s the testers who are “holding up the show”

    I’ve heard the phrase “Just ship it” WAY too many times.

  3. Few years back at (employer name redacted) I was designing and implementng business automation systems (very easy job – off-the-shelf servers, shrink wrap software that was selected because all the apps had been proven to play well with each other and I put a fair amount of work into minimizing – and testing the crap out of – the customizations. Biggest problem was getting the organization to change biz processes to use the systems most effectively). Other SW in that shop wasn’t so lucky – the testers were also the developers. Actually, the real testers were the users. Ooops…..

    Funny you should mention can openers – when I find canned goods on sale I buy some, and package it in boxes in the form of “food units” – a 12X9X9 box holds 24 cans: 8 protein, 8 veggies, 8 fruit. Works well for “grab ‘n’ go” if I ever need to, and I date the box with purchase month&year so I can use oldest first. I tape several P38s under the box lid and slide a few plastic spoons and knives between the cans.

  4. One thing you discover when you test is whether management (or government) actively supports the test and reacts to the results as engineers to fix issues found, or sees it as another item on a marketing checklist (Oh yes, we test thoroughly! Ship it!).

    Progressives, with 100 million murdered by their political philosophy in the last century, obviously value the marketing over the engineering, the sales pitch over the user friendliness, of their product.

Comments are closed.