Prior to starting designing and during design you should have created a number of documents, like User Requirements Specification (URS) and Functional Requirements Specification (FRS).
Everything you specify sooner or later has to be tested!
Why else would you take the trouble to put it on paper?
The URS should be where you derive the User Manual from, but also the User Test Specification. Describe what you expect to happen when the user performs an action, like pressing a button, under which circumstances. Pressing button 1 may cause a different action depending on the state of switch A.
So you describe start conditions, actions, expected end conditions. For all normal user actions.
Then there's unintended use. Organize a creativity session to discover as many ways as possible to abuse the product. If you know how to conduct a brainstorm you could use that. Issues could go from pressing several buttons simultaneously to inserting batteries the wrong way. Can you insert the wrong type of batteries? Again you describe start conditions, actions, expected end conditions. If you don't know what the result of an (even unintended) action should be then you missed something during design.
This implies that writing a Test Specification (especially the part about unintended use) shouldn't be done just before testing. The software designer must know what should happen if you press two buttons at the same time before she starts writing the software. Remember that the cost of changes in a design rises exponentially with time.
It is of course that device failure under certain conditions is allowed. You may not have protection against inserting batteries the wrong way and you know the device will be damaged if the user does. (Not a good idea IMO, just an example.) Also then this has to be described in a functional spec, to show that you haven't overlooked it. I would even mention it in the test spec with the comment "test not required".
It should be obvious that pressing two buttons simultaneously shouldn't lock up the software. But don't say it's impossible. The software designer must be able to show in her code how she deals with this. Which is even better than just trying it. During testing one button may be pressed slightly later than the other.