A.1. Test Management
From a purely test management point of view, the same tools I introduced in the last eleven chapters will work for a test project that involves both hardware and software. You still have to track tests and bugs, assemble a test environment and team, get releases into the test environment, and possibly work with a distributed test team. That doesn't go away.
However, if you are a big test-automation buff, know that many of these tools won't help you in the hardware and systems testing world. You can use load generators of various sorts as part of a reliability test (more to come), but the failures you see will be different from the type of functional regression bugs most people use the automated tools to catch.
That's not to say you won't need tools. On the contrary, whomever ends up doing the actual hardware testing—the hardware vendor, a third-party test lab, someone else, all of the above—will need lots of tools: thermal chambers, oscilloscopes, voltage/amperage meters, shock and vibration tables, mechanical life harnesses, and more.
When testers find bugs with these tools, you'll soon learn that sometimes hardware systems behave differently, one to the next. Bad unit failures happen. They can be perplexing until you stop and think about the nature of a "bug" in hardware instead of software. In two hardware systems, bugs can arise because one system has a bad solder connection, a broken write, a faulty chip, or any other number of unique reasons. In software, ...