I believe this is a more complicated task than originally intended because its "impossible" to create a verification test that can't fail. That would be similar to assuming a newly built car will never have any problems on first startup. Sure, it would be very very unlikely for a new car to have an issue at 0 miles but it is not completely impossible. Similarly, to design a verification that is perfect would be very difficult. To create a verification test laying out all variables as well as the expected deliverables of a product should be your first step. Next, instituting tests that accurately and confidently test a singular variable at one time is important. There should not be any question as to whether or not the passing of a test was due to the desired product function or something unrelated/adjacent

I agree with @anthonynjit its impossible to design a design verification test that is guaranteed not to fail. The purpose of design verification is to make sure that your inputs = outputs. It's an important part of the design control process to ensure your device is safe and effective. While it's impossible to design a test that will be Guaranteed not to fail, there are still measures that are taken to prevent that from occurring.  One thing that is often done, is unofficially running the design verification test to see how the device will perform. By doing this, you are able to access the functionality of the test but get a good indication on how your device will perform on testing day (there is still no guarantee that if your device passes one day, that it will pass the next). If your device does pass unofficially, it is likely that it will pass officially.

Does anyone know any other ways how design verification testing can be done to minimize failures?

Thanks,

Matt

Based off of your wording, I am going to phrase my answer under the assumption that you curious as to how to create a test that is guaranteed to pass the first time around. Under that assumption, much like what @mmd55 and @anthonynjit stated, it is impossible and, in my opinion, pointless to create a design verification test like this because if the product is guaranteed to pass the test the first time then what is the test verifying? The way I see it, the purpose of a design verification test is more to make sure the device does not fail more than it is to make sure it passes. The purpose of a design verification test is to make sure the product passes the test, but some devices can pass the first time around and others may fail and need to be looked at and need troubleshooting before it passes. You can definitely design a verification to minimize the amount of failures that can be seen by prior tests that address a necessary condition to pass or advise the user to perform certain preventative measures to try to optimize the conditions as much as possible. 

Based off of your wording, I am going to phrase my answer under the assumption that you curious as to how to create a test that is guaranteed to pass the first time around. Under that assumption, much like what @mmd55 and @anthonynjit stated, it is impossible and, in my opinion, pointless to create a design verification test like this because if the product is guaranteed to pass the test the first time then what is the test verifying? The way I see it, the purpose of a design verification test is more to make sure the device does not fail more than it is to make sure it passes. The purpose of a design verification test is to make sure the product passes the test, but some devices can pass the first time around and others may fail and need to be looked at and need troubleshooting before it passes. You can definitely design a verification to minimize the amount of failures that can be seen by prior tests that address a necessary condition to pass or advise the user to perform certain preventative measures to try to optimize the conditions as much as possible. 

As the others above have stated, verification tests are designed so that they do fail. Learning from mistakes allows for growth and sometimes, a product may fail in a way you have not anticipated. The process of verifying inputs = outputs ensures that the product is of high quality when each component passes. Creating the verification test involves identifying the deliverables and creating a testing procedure that aligns with the deliverables. Essentially, it’s a way to say, here is where I want the product to finish so let’s run analyses and adjust as necessary until the desired product is achieved.

I agree with some of the responses above. While it is impossible to make a failproof verification test it is important that you make sure you have a realistic verification test. Here you have to find a good balance between making the test too hard or too easy because a test made too hard can disqualify a good product while a test made too easy can let a bad product through. Finding this balance is very important to the success of what you are testing and it takes having good background knowledge on the product and the conditions it will be used in to make this test work for you

You should not set out to design a verification test that cannot fail. The engineer should strive to design a test that can accurately verify that the specifications of the product are met. This heavily depends on what type of product of industry. Medical device products often have very strict specifications, and a sufficient level of testing may be required to verify it.

In the 'Simulation 1', the labels were failing a verification test after being submerged in water at 37 deg C. It was found that after submerging the bottles in room temperature water, the labels would not peel. What was the point of the 37 deg requirement? There was none. The specification did not require the water to be at 37 C, so why test it for that. There must be a reasoning for the testing.

I believe that verification tests are "almost" guaranteed to fail. The chances of having a test be perfect the first time around after making it are slim. The verification test is meant to test your project and the expected implementations to them, ensuring it meets the requirements set for the product. So I believe that the test would not be correct right away, you should look to have a  test which has potential failure in it to allow the product to develop into a better version of itself. 

The verifcation test should include processes which test the product in aspects which it is meant to succeed,  but also for its quality. I think making tests which  allow the products to perform well under different circumstances allows the product to be a quality product. 

As others have previously stated, your question of how to make verification tests so they don't fail is not the correct way to look at the verification process. I believe that whether the product passes the initial test or not is irrelevant. While it would be ideal for it to pass, having the product fail is just as important. The purpose of verification testing is to see if the product meets the desired output. If the product fails then you can make adjustments to the device and redo the verification process for that input. Having a product fail a verification test is just as beneficial as having it pass because the entire point of the verification process is to ensure the device is meeting the required specifications. 

I agree with the above posts that the purpose of the verification testing is to see if the input meets the desired output, not to create testing that is fail proof. In order to ensure a device is truly safe and effective it is essential to accurately test/identify inputs and meets the requirements. Regardless of the research and development put into a project, verification testing does fail. What are some ways a team can trouble shoot and problem solve if verification testing fails? What are some ways to prevent verification testing from failing at the start?