turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Twenty years ago, the hot thing in hardware development was “design for test,” or D4T as we affectionately referred to it. The idea was that hardware complexity was growing so fast—especially for chips—that you couldn’t possibly test these systems without special test-only features built into the hardware. JTAG was all the craze–as were chip simulators and emulators and test vectors. Today, though, you won’t find any credible engineer designing a chip or a circuit board without building in this kind of testability.
It’s time to realize that we need the same mindset in the world of software testing. Software has always been just as complex, if not more so, than hardware. But because it seemed so easy to update software, a few bugs here and there didn’t matter, right? Wrong. The cost of a software bug found by a customer is at least 100 times more expensive than the cost of a bug found during the development phase.
It’s time for D4T to come to software. This means that software developers need to be designing in features that are meant for testers. Most testers today are limited to what is available to end users via control and management functions. Testers need to be able to “peek and poke” inside the software using a solid, robust, and stable interface designed specifically for testing. Some organizations have “internal user-only” interfaces inside their software—but these are often compiled out before they get to the testing organization. In other cases, these interfaces simply don’t exist. And when I say, “stable,” I mean that testers should be able to count on these interfaces remaining consistent with each new release.
Think about JTAG for software. It’s a stimulating idea.
This is not to suggest that testers skip testing public user interfaces. Not at all. These require thorough testing, too. Developers, however, already understand that internal test harnesses are invaluable for testing the underlying functionality. Now let’s share them with the engineers who are trying to test and automate the testing of this software.
If you’re a developer, ask yourself what you are doing to make life easier for those trying to test the features that you develop. If you’re a tester, think about what you really need from your developers, and ask for it!
It’s time to realize that we need the same mindset in the world of software testing. Software has always been just as complex, if not more so, than hardware. But because it seemed so easy to update software, a few bugs here and there didn’t matter, right? Wrong. The cost of a software bug found by a customer is at least 100 times more expensive than the cost of a bug found during the development phase.
It’s time for D4T to come to software. This means that software developers need to be designing in features that are meant for testers. Most testers today are limited to what is available to end users via control and management functions. Testers need to be able to “peek and poke” inside the software using a solid, robust, and stable interface designed specifically for testing. Some organizations have “internal user-only” interfaces inside their software—but these are often compiled out before they get to the testing organization. In other cases, these interfaces simply don’t exist. And when I say, “stable,” I mean that testers should be able to count on these interfaces remaining consistent with each new release.
Think about JTAG for software. It’s a stimulating idea.
This is not to suggest that testers skip testing public user interfaces. Not at all. These require thorough testing, too. Developers, however, already understand that internal test harnesses are invaluable for testing the underlying functionality. Now let’s share them with the engineers who are trying to test and automate the testing of this software.
If you’re a developer, ask yourself what you are doing to make life easier for those trying to test the features that you develop. If you’re a tester, think about what you really need from your developers, and ask for it!
 | Kingston Duffie is the founder and CTO of Fanfare. Learn more about Kingston >> |
You must be a registered user to add a comment on this article. If you've already registered, please log in. If you haven't registered yet, please register and log in.