It is important to include specifications of what the test entails, how to execute it properly, and what specs will indicate and failing or passing test. The more detailed the plan the more likely it is that everything will be tested correctly. If it is a test that requires multiple people to get involved due to the sheer amount of tests to be completed, a well detailed test will ensure they all complete the test in the same manner. 

Not only should a test be detailed, like @ridmehta stated, but depending on the kind of device that is being developed you should also have different kinds of tests. If you had a blood chemistry testing machine for example, while you obviously have numerous tests to ensure that a specific part of your device functions properly, you should also have tests that lead to failing conditions, and if a specified message or alert to prompt the user of the failure are working as intended. For instance, you would want to have a test that measures the temperature in the instrument when analyzing a sample to see if within it is in normal operating range, and if it is not then to alert the user to make them aware. If this works properly then you are assured that if this issue arises in the field, then the user is able to do what they have to do in order to resolve as opposed to them operating without knowing and getting inaccurate results.

Another reason for incorporating tests that should conclude in a failure of the device is to broaden the companies knowledge of the device and its parts so that they can work on ways to circumvent those failing conditions, how to troubleshoot to resolve those issues, or if they need to include it under a warranty plan for the user, or if they should avoid using the material or component altogether. Detailed tests to demonstrate failure of the device are just as important as tests to demonstrate the success, and every design verification document should have a section for these kinds of tests in my opinion.

Design verification is one of the nine design controls which is a phase where each manufacturer establish clear, complete, and unambiguous procedures during the actual development, as oppose to after as in the case of the validation control, to verify the device design by confirming whether the device output satisfies the device input requirements/specifications. These procedures include identifying an aspect of the design and developing methods to test/verify whether the device is functioning properly and parts are manufactured as expected (i.e. expected dimensions), perform as expected (i.e. generate a certain voltage), and utilized as intended (i.e. turn on a remote) - as in the battery example I just laid out. As mentioned by @pv223, the number and type of tests depend on the device in question, whether it is biologic, electronic, or a combination device. Inadequate requirements as part of the design input component of 21 CFR 820.30 is likely why some necessary tests may be missed/overlooked by manufacturers, consequently, leading to design errors and the need for extensive rework.

I have some experience doing design verification since my Senior Capstone for my bachelors followed the 21 CFR 820.30 process. We had requirements and specifications for each aspect of our device. To expand on what previous posts have said, we specifically stated what we wanted each component to do. For example, we specified what the signals the device circuitry was supposed to filter out, how the microcontroller would receive inputs from the sensors and what the corresponding outputs would be, how accurate the biosensors would be, the battery capacity of the device, and the device size and weight. Once we were sure that our requirements and specifications covered all the device aspects that were relevant to the design goals, we began writing protocols that would test the specifications. Along with the procedure to run the verification tests, it was just as important to establish what the criteria were for the device to pass the test. Ideally the results from the verification testing should demonstrate that the device is functioning as it was intended to. 

As the previous posts have stated, the verification testing should have specifications that should be met with listed tolerances. Even how the product is made should be specified, such as machinery used, speeds, materials, and even the shape. The procedure provided should also have clear specifications and instruction so that those conducting the tests will not need any extra clarity on how it should be performed. Also, I believe that each test conducted should have a verifier to make sure the test is being conducted properly and is in accordance to with GMPs. Having procedures and protocols in place will make sure that there is no room for interpretation or re-testing later.

After coming up with the proposal and development plan, defining the specifications in the Design Input Document and Design Specification Document would follow. Afterward, the verification process can occur. In this test, one should make sure that the inputs equal the outputs. This means following the DID and the DSD. Documentation of these tests should be coll2ct2d for reference. If specific tests fail or don't meet the criteria, then corrections should be made and testing should be redone until deemed successful.

In verifying a design, the performance should be tested through ensuring that the device is able to process the proper inputs and that the device should yield the desired results. Another component of the performance that should be observed is the time that it takes from when the input occurs to when the output occurs and if there is a delay. Additionally, the accuracy of the outputs needs to be tested to observe whether there is a high degree of variability between uses. Reliability ties in with this in that the device should continue to produce accurate results without breaking down over time. The most important test to include is a safety test to ensure that the device will not hurt the user. Another key aspect to include in the testing is to make sure that everything is properly documented and that all regulations are met. In the case of a medical device, the device would be for one of the most highly regulated industries so it is critical that the device meets the proper FDA, ISO, etc. regulations. 

    To my knowledge, by reviewing and giving proof, design verification is a technique for ensuring that the output of a software product fits the input specifications. During the software development process, the design verification process aims to confirm that the designed software product matches the specifications. The basic steps for designing the verification test are:

• Identifying and preparing: Determine the most effective strategy for carrying out verification. Define the parameters for your measurement process. You should also think about the materials, labor, and equipment needed for successful verification.
• Planning: here, planning for verification happens all over the project life cycle. The design verification manager must create a test plan that catches significant milestones. The plan can be modified or updated when alterations are made to the design inputs.
• Developing: In general, product development is carried out using the practices of selections (scrum, hybrid, waterfall, etc). Usually, the product development process also incorporates writing, test driving, and approaching the test cases which will be further used for verification.
• Executing: generally, the test processes are performed as planned. Any invalid outcomes are recorded and examined, and either registered or accepted as defects. The defects in the goods or products are solved and released, and the test is performed again and again.
• Reporting: At the end of each stage of the verification, the report is performed. The design verification traceability report reveals test results and analysis for the requirements. Ultimately, reviews are finished and approved after each design verification activity.