It's the habit of perfectionists everywhere: only reveal what you're working on when it's done or as close to done as possible. Whether it's a term paper, a painting, a slide deck, or a software product, it's tempting to keep it under wraps until the due date. But just as with paper- or painting-in-progress, getting feedback [...]

It’s the habit of perfectionists everywhere: only reveal what you’re working on when it’s done or as close to done as possible. Whether it’s a term paper, a painting, a slide deck, or a software product, it’s tempting to keep it under wraps until the due date. But just as with paper- or painting-in-progress, getting feedback and regular checks along the way of software testing means you won’t be stuck with software or slides that no longer match the customer’s needs. You also avoid painting yourself into a corner that will take a lot of work to fix.

Iryna Chernenko at Software Testing Club has put together a list of seven software testing myths. The third one, “Only Ready Software Products Are Tested” jumped out as describing the situation really accurately:

Without doubt, testing depends on the written code. But, still it is necessary to test software requirements and create test artifacts and both these procedures can be carried out prior to release readiness of the final software product.

Testable Software Components

Architect your software so that you can test individual components. This makes it easier for the software developers, because they can isolate functionality, inputs, and outputs. It also means you can have testers verify that that part is working, and continues to work as you write the rest of the product.

Test When You’re Not Ready

Even though it’s going to be ugly and full of bugs, test early and often. Review whether your software is actually on the right path to meeting the project requirements. Check with your stakeholders and get feedback so you know whether those requirements are still accurate.

Keep doing this throughout the course of your development cycle. In fact, if you make this a key part of each milestone or release, you’ll actually end up saving time because you’ll avoid those big detours and wrong paths that inevitably happen when working without reality-checks and discrete components .

Take the course of wisdom: don’t let perfectionism or fear of feedback keep your project from succeeding.