Electronics testing - in general - Page 1
Forum section: electronics / general

author: brumbarchris
author_rank: Regular Contributor
timestamp: November 22, 2024, 11:00:53 am
content: Greetings all!I must shamefully admit that I, as an electronics engineer, have come a long way in this profession without having and adequate method of organizing the testing and recording the test results of the various projects I have been working on.Sometimes we need to carry out tests at PCBA level, sometimes at fully assembled product level, with a product involving multiple boards, each with their own different lifecycle (revisions) which are yet different from the lifecycle of the assembled product.I have seen test activities organized around an physical item (so list of tests to be carried out on specific physical revisions of boards) and I have seen test activities organized around a problem (list of tests to be carried in order to evaluate a problem).Occasionally I need to carry out tests where the results can be easily classified as pass/fail, based on existing limits expected for the various measurements or based on expected PCBA or product behaviour. At other times, the tests I carry are only investigative in nature, where I just need to find root cause of various defects. Many times we also need to carry out ... well, not necessarily tests, but measurements which characterize the various circuits we design and which allow us to make improvements or design changes; however in most such situations the results of these tests cannot be classified as pass/fail - they are just that... measurement results; maybe these are inappropriately referred to as "testing", but this is how it is, in real life.I have seen test reports including the detailed description of the testing specification, I have also seen test reports only referencing the test specification (I can see both approaches have some merits, but also drawbacks).I want to improve, but when I look for theory and literature on the subject, this seems to be mostly geared towards software testing and it is rife with a lot of notions which are not always the same in-between the various sources I have consulted: test case, test item, test set, test session, test run, test objective, test definition, test specification etc.So what I do at a moment, in terms of method is...undefined, and sort of a mess, really. I mean I always get it done (testing and test results documentation) to a reasonable level but I am always left with a "could be done MUCH better" taste. On top of that, various companies I worked for are also quite relaxed concerning this topic, and no firm guidance is available. Consequently, every project does it in its own way, every discipline (HW, SW, mechanics) does it in its own way and many of the engineers have their own preferred methods and solutions for handling testing.I realize testing itself is a complex subject (complex enough to warrant the existence of "test engineers") so my problems might not have a simple or unique solution.What do you guys do in this regard? I am mostly interested in answers related to physical hardware testing, including the firmware on it.Regards,Cristian

author: Brumby
author_rank: Unknown
timestamp: November 22, 2024, 11:17:52 am
content: My first thought is a simple one - always keep the purpose for whatever testing you are doing clear in your mind. Then let the form of your process derive from achieving that function - and don't shrink away from modifying something if there is a misalignment.Admittedly, I speak from a software development perspective, but I have seen processes that have been defined by an "expert" resource that have been religiously followed, crossing all the 't's and dotting every 'i' and lower case 'j' - producing an exquisite pile of near useless garbage. Well, perhaps I'm being a bit strong there - but the defined process missed quite a bit of "other stuff" because people were reined in to follow the corporate model. I saw things were missed and it was no surprise that problems followed.Once you've done your testing, stand back and look at the results and ask yourself "Did that achieve everything that was needed?".

author: tggzzz
author_rank: Super Contributor
timestamp: November 22, 2024, 05:25:29 pm
content: Start by realising there are several classes of tests, to determine that:the design validation and verification, i.e.the design does what the user needs (i.e. does the right thing)the design does what the designer intends (i.e. does the thing right)one implementation of the (correct) design has been manufactured correctlywhether a (correctly manufactured) implementationis working correctly when installed in the field (i.e. installation and commissioning acceptance test)and if not, which sub-assembly needs replacing (i.e. maintenance)For each of those classes the detailed tests will beverydifferent.

author: RJSV
author_rank: Super Contributor
timestamp: November 22, 2024, 07:34:17 pm
content: If you are hiring, find a 'Qual Test' engineer to hire or retain for consulting. But, I realize that route isn't possible due to resource limits.That person (such as myself, with limits) would write the test plan, looks like you did a lot of focus on documentation.A test Engineer might be involved in aircraft Qualification trials, which are fairly strict and expensive. Myself, I did things like go stay in hotel while a 2 day testing was done, at (distant) official testing site.That was Viking Labs, in Sunnyvale, CA.Things happened like; Vibration table run for 2 hours, in each of 3 axis. Even worse, the aircraft subsystem under test was encased in a special OVEN for accelerating any flaw based failures.Things like that. The customer likely had numerous Engineers, writing all the oven parameters and vibration table intensity.Also similar case; we put the little digital switching unit through COLD SPRAY as well.They even had done testing using SALT sprays.My tasks there, as a guest QC tech at Viking were to periodically run short tests on the module functions, while under duress.Some boring, watching the thing heat-up ! Drank a lot of coffee, doing a lot of waiting and brief testing.Our manufacturing company also had to build the various fixtures, such as the metal block universal mounts, that connected to the top of the vibration table 'voice coil'.That vibration coil was approx size of a (small) bear!What a vibration table set-up system COSTS, $$, I don't know.All that is more than you might need, but it's out there.That was for Systron Donner Safety Systems.For less formal testing, a good set of lab notebooks is good start. Maybe hire a documents person, who only has limited electronic background, as long as you help supply the raw text, first.Some investors or agencies might even require certain level of daily documentation, for transparency for investors especially.Of course if your products have safety related features, such as smoke detection, those might even have LEGAL requirements to maintain testing records.O.k. now that I've scared the shit out of you, you can always send PM's with questions about Quality Assurance things. There are even trade magazines with that particular special aspect of manufacturing sub-systems.- - Rick