EEVblog Electronics Community Forum
Products => Test Equipment => Topic started by: MrYakimovYA on February 10, 2017, 01:50:49 am
-
Hello, everyone! Sorry if I ask my question in wrong topic, I'm new here :)
I search some books describe the process of testing developing hardware (analog and digital circuits, maybe software that controls it). For example, we have just developed new DMM. It has a lot of hardware solutions and software things :) As the product is new one we need some tests that must be done to decide what to do next: throw it away and redisign or sell it.
Of course, I understand that we can test it from user view: press buttons, connect it to different voltage, current references and so on. But I want to formalize the procedure, take some scientific approach. To do it I need books... So I've come here to ask you help me :) Please, point me to some good books that clarify testing routines, that tell me how to build them in a right way :)
-
Seems like an alright area to post it. I would be interested in books on this subject myself.
-
There's an argument that it is already too late, since a product should be designed to be tested. "Design for test" or DFT might be a useful search key :)
-
There's an argument that it is already too late, since a product should be designed to be tested. "Design for test" or DFT might be a useful search key :)
That is a good point. When designing a circuit I like it to be able to test itself and if that is not possible it should be easy to test (special test mode, connector to hook up test equipment, etc).
For testing a product with buttons, display and so on I have good experience using a test plan which guides the tester through all the necessary tests and also collects data on the test results. In many test equipment service manuals you find similar test plans which usually are in the 'performance verification' section.
-
There's an argument that it is already too late, since a product should be designed to be tested. "Design for test" or DFT might be a useful search key :)
In my understanding, DFT focuses on designing the product for production tests, i.e. testing each unit for correct function before it gets shipped, to catch production flaws. In contrast, the OP seems to be after test approaches for a newly designed product, i.e. testing the prototype for weaknesses in the design. (MrYakimovYA, did I get that right?)
In that case, FMEA (failure mode effect analysis) is a good search term and starting point: You should start with a systematic analysis of what could go wrong in your product, and how the design tolerates, compensates, or at least indicates critical problems. E.g. think about effects of temperature drift, robustness against excessive voltages or wrong connections, robustness against electromagnetic immissions etc.. Once you have identified potential critical impacts and failures, that will inform the design of your testing program.
-
There's an argument that it is already too late, since a product should be designed to be tested. "Design for test" or DFT might be a useful search key :)
In my understanding, DFT focuses on designing the product for production tests, i.e. testing each unit for correct function before it gets shipped, to catch production flaws. In contrast, the OP seems to be after test approaches for a newly designed product, i.e. testing the prototype for weaknesses in the design. (MrYakimovYA, did I get that right?)
Just so, but there is significant overlap in the mental thought processes, and in the practical details. It isn't completely clear to me whether the OP is after design tests or production tests.
If they've thrown something together and are only now wondering whether it works, well.... good luck to them.
There's an old engineering axiom that is ignored by the XP/TDD brigade: "you can't test quality into a product".
-
There's an argument that it is already too late, since a product should be designed to be tested. "Design for test" or DFT might be a useful search key :)
For "DFT" thank you!
What about "it is too late" I can say that the DMM was just for example)))
-
In many test equipment service manuals you find similar test plans which usually are in the 'performance verification' section.
I suppose HP manuals are good starting point!
-
i.e. testing the prototype for weaknesses in the design. (MrYakimovYA, did I get that right?)
Yes, you are right! But DFT is also applicable for me :)
I collect information now, and any sort of topics may help me. I'm interested in how to test the prototypes for faults and weakness. I also would know what I should do for new designs to simplify testing.
-
It isn't completely clear to me whether the OP is after design tests or production tests.
Both :) As I mentioned earlier I want to cover as much information on testing as I can :) So I need books, if such books are real... may be there are no book on this topic?
-
Suddenly I recalled a buzzword: TMAP and it turns out there is a Wikipedia page about it:
https://en.wikipedia.org/wiki/Test_Management_Approach
-
Well, if you want to take a look at formal treatment of product development, for instance you can take a peek at :
https://www.crcpress.com/Design-of-Electromechanical-Products-A-Systems-Approach/Jamnia/p/book/9781498742191 (https://www.crcpress.com/Design-of-Electromechanical-Products-A-Systems-Approach/Jamnia/p/book/9781498742191)
And more directly to your question, it's not about testing. It is about verifying whether the product you're developing conforms to:
1. Requirements as defined by customer.
2. Regulatory and/or any other legal requirements for that product to be used and sold.
So it goes like this (very simplified):
1. In talking with customer you freeze specification of what product does and with what quality. That includes environmental requirements, accuracy and all such technical specs.
2. Then you make technical analysis and come up with technical solution that can achieve those specs.
3. Optimize for cost and/or other requirements
4. After roughly having technical solution defined, you devise test plan how to test your technical solution against specs in point 1.and 2.
That includes adding test points and test code to the prototype to be able to execute test plan.
5. Make prototype.
6. Test.
7. Make notes what was wrong.
8. Rinse and repeat.. Until it works as it should..
Regards,
Sinisa
-
Are you interested in product reliability or usability?
We use halt/hass testing methods for the former, customer surveys for the latter (just kidding ;))
-
Of course, both your points numbered "1" can be problematic. That leads to agile development and TDD - which are definitely beneficial in some circumstances. But of course, "you can't test quality into a design".
Anybody that thinks you can simply follow a process to get a good result is either a fool or has something to sell.
You have to think and use mature experience.
-
Of course, both your points numbered "1" can be problematic. That leads to agile development and TDD - which are definitely beneficial in some circumstances. But of course, "you can't test quality into a design".
Anybody that thinks you can simply follow a process to get a good result is either a fool or has something to sell.
You have to think and use mature experience.
Well, I said greatly simplified...
Critical is that, while you are talking to the customer, you don't let them go crazy with things that cannot be done..
And that you FREEZE requirements at one point..
And have that in writing, in a contract.
That part shouldn't be negotiable afterwards...
And you should design in the test facilities in the prototype.. At that point, experience is king...
I agree, there is no magical process that will, by definition, spit out good products..
Trick is to give yourself enough tools to be able to develop product that was ordered.
And to answer directly to OP, no there is no book that will tell you how to test every product...
In a design phase, you have to make a list what needs to be tested to prove product is as it should be..
And all starts with product specification, intended use and market and such..
-
Of course, both your points numbered "1" can be problematic. That leads to agile development and TDD - which are definitely beneficial in some circumstances. But of course, "you can't test quality into a design".
Anybody that thinks you can simply follow a process to get a good result is either a fool or has something to sell.
You have to think and use mature experience.
Well, I said greatly simplified...
Critical is that, while you are talking to the customer, you don't let them go crazy with things that cannot be done..
Yes.
And that you FREEZE requirements at one point..
And have that in writing, in a contract.
That part shouldn't be negotiable afterwards...
Often the customer doesn't know what they want at the outset; frequently requirements emerge during the design. That has to be catered factored into the process.
And you should design in the test facilities in the prototype. At that point, experience is king...
Most definitely.
And you should also implement, test and prove each part independently of the others, in a logical sequence.
I agree, there is no magical process that will, by definition, spit out good products..
Trick is to give yourself enough tools to be able to develop product that was ordered.
And to answer directly to OP, no there is no book that will tell you how to test every product...
In a design phase, you have to make a list what needs to be tested to prove product is as it should be..
And all starts with product specification, intended use and market and such..
Yes, with the caveat above.
If you don't have a specification, then anything will meet it!
-
OK... thanks for your replies, gentlemen!!! They clarify a lot for me.