Validation engineer

Thread Starter

alphacat

Joined Jun 6, 2009
186
Hello,

I work in a validation group in a student position, but according to what I see, I fill the position of an engineer.

I feel that what my team does doesn't require much electric knowledge nor unique skills.
I feel that it mainly requires devotion and ambition to improve test methods.

I have a problem with how to make test methods more efficient and make them better.
Therefore so far I just used to stay long hours at work to be able to have more tests and that way impress my supervisors.

I think that I need to dedicate more time for the test methods part instead of the tests themselves, because I don't want work to interfere with my leisure time.

I'd be happy if anyone here could share his validation experience, or anything related to the subject I brought up.

Thanks :)
 
Last edited:

seecumulus

Joined Jul 13, 2011
31
I suggest :

Prior to Under Going Any Test whether it be a Functional Test, Design Verification Test or Environmental / Reliability Test that the operator(s)
obtain a good grasp of what you are Testing.
If you have time to study the UUT Unit Under Test prior to Testing
whether it be general knowledge or down to the component level you will
be that farther ahead . . .
Understanding what you are Testing can eliminate repeated Test Error's ,
Un-neccessary Test's, Test Set Up Time, may abbreviate Test Scenerio's.
I find that the later is quite time consuming - Test Setup Test Tear Down, Arranging Equipment, organizing the Test Environment is much time consuming.
Do It Right The First Time !
 

someonesdad

Joined Jul 7, 2009
1,583
Just a tidbit: in all the companies I've worked at, the test engineers (both software and hardware types) are often the low men/women on the totem pole. It shouldn't be this way, but it in fact is. The most highly-regarded engineering positions were the top-level marketing, manufacturing, and R&D/product development roles. And, at a few of the companies I worked at, it wasn't unusual to see a high-level engineer move from e.g. R&D to marketing because he knew a) he'd learn lots of new stuff and b) this was rounding out his career and making him more valuable to the company. Guess what: once you become more valuable, you wind up participating more heavily and deeply in both the tactical and strategic decision-making processes (and that can be a lot of fun).
 

Thread Starter

alphacat

Joined Jun 6, 2009
186
I suggest :

Prior to Under Going Any Test whether it be a Functional Test, Design Verification Test or Environmental / Reliability Test that the operator(s)
obtain a good grasp of what you are Testing.
If you have time to study the UUT Unit Under Test prior to Testing
whether it be general knowledge or down to the component level you will
be that farther ahead . . .
Understanding what you are Testing can eliminate repeated Test Error's ,
Un-neccessary Test's, Test Set Up Time, may abbreviate Test Scenerio's.
I find that the later is quite time consuming - Test Setup Test Tear Down, Arranging Equipment, organizing the Test Environment is much time consuming.
Do It Right The First Time !

seecumulus
Thank you very much, these are good advices.
I mostly validate SW.
There's a new SW released on a daily basis, and I ran mostly the same test automation scripts.

The thing is that I don't manage to decipher whether some failures that occurred, happened because of the test setup/script or because of the SW.
So I don't always report on failures as a bugs because I don't know if these are really bugs or just test setup/script issue.

someonesdad said:
Just a tidbit: in all the companies I've worked at, the test engineers (both software and hardware types) are often the low men/women on the totem pole. It shouldn't be this way, but it in fact is. The most highly-regarded engineering positions were the top-level marketing, manufacturing, and R&D/product development roles. And, at a few of the companies I worked at, it wasn't unusual to see a high-level engineer move from e.g. R&D to marketing because he knew a) he'd learn lots of new stuff and b) this was rounding out his career and making him more valuable to the company. Guess what: once you become more valuable, you wind up participating more heavily and deeply in both the tactical and strategic decision-making processes (and that can be a lot of fun).
Well, I must say that in my team, there're brilliant engineers who excelled in their studies and graduated with honors.
These team mates could have applied for any position they wanted to.
 

DumboFixer

Joined Feb 10, 2009
217
But isn't a test script failure/issue still a bug ?

It may not be a bug in the software being tested but it is a bug in the test system and, in my opinion, should be reported. I have often raised fault reports on test systems because they haven't performed correctly.
 

JoeJester

Joined Apr 26, 2005
4,390
The thing is that I don't manage to decipher whether some failures that occurred, happened because of the test setup/script or because of the SW.
So I don't always report on failures as a bugs because I don't know if these are really bugs or just test setup/script issue.
You still need to identify the problem no matter the source.

Not reporting will allow your company to put the product on the market sooner, but then when the complaints come in, where do you think they will look? You could become infamous in your former company for falsifying the validation tests.
 

#12

Joined Nov 30, 2010
18,224
Doing the work of the Engineers and getting paid as a QC tech is the stimulus that finally provoked me into going to college. By my second year, I WAS the engineer where I worked, at triple the pay I used to get as a QC tech, and I hadn't taken a course in electronics yet!
 
Top