Run it yourself.

I’ve worked on projects where one of the developers never ran their own code.  Never.  The results are obvious to everyone with 6 months of experience in QE.  It’s annoying and can come across as condescending.  Also it’s frighteningly naive.  That’s how segfaults during startup happen.  Or worse yet, entirely new features being completely or partially untested, if a developer is quiet about expected new output that QE never sees happen. So for the love of Kernighan & Ritchie, run your code just once as a smoke test before passing it along to the build process that ends in QA.

It doesn’t take very long. In QA it’s the first thing that I do, it’s just smoke testing at that point. Basically, determining if the build appear valid. By the time I’ve completed the part of integration testing covering the new features, I’ve spent 30 minutes setting up systems in a new configuration and 5 minutes testing. Many days I’ve tested something and the new feature immediately fails horribly, often badly enough that I can’t see how the feature worked at all.

It seriously helps to setup a test build system for pre-QA builds. It’s a couple of hours’ work once, and less than 10 to check out a build during development. It can save 1-2 hours / day for QA, frequently where the bottlenecks occur and at the most inconvenient time. I’ve seen software respin 3 times / day at various points, because of the lack of pre-QA smoke testing.

There are obvious ways to work around this in QA. They still require attention from QA, who will be logging the build’s status and initial smoke test results. It’s often a distraction from other testing in QA. I’ll cover that ground for QA in another article.