Should You Pursue a Career in Verification Engineering?
Before they hit the market, products must be rigorously checked against a long list of criteria.
This is not big news for electrical/electronics engineers: verifying that the product works as it should is a prerequisite for successful design, development, and manufacture—but it can be an exciting career choice for conscientious engineers.
Verification and validation are not the same, although they can often be part of the job description for a particular engineering specialty. They both include the performance of a range of tests, which can further confuse what each process should accomplish (both may be mixed with testing carried out at the later stages). Furthermore, validation and verification can vary in their formality levels, with differing consequences that come from failing to do them correctly.
Considering the high-risk environment, verification and validation in electrical and electronics engineering are quite a painstaking process that must (or should least never be taken lightly. Still, mistakes happen and engineers are accounted for.
If you want to sign on the dotted line as a verification engineer, prepare to work long hours, gain at least five to eight years of experience as a specialist, be good with managing teams, and meticulously go through the validation and verification process during each design stage. That’s how you’ll prevent common career mistakes.
Pictured: a padlock holds compliance paperwork together. Image used courtesy of Steve Buissinne.
Verify, Validate, and Test: Aren’t They the Same Thing?
A series of tests, checkups, inspections and evaluations are run through the course of product development.
Formal product verification can be an external process conducted by a reputable independent party, which guarantees that the product or service will work according to the design specifications and product regulations.
Although formal verification is often required to wrap up the process once a product is launched, verification is neither a one-off formal activity nor an external process. In fact, verification takes place internally and informally during the development and post-development stages.
Engineers rely on design specifications before they start building a product, mainly by turning the concepts and other details of the given Engineering Requirements Document (ERD) into a factual outcome.
An example of technology that involves strict verification and validation work is a telecommunication test set connected to a network switch to perform various data transmission quality measurements.
What to Build Versus How to Build
ERD is the counterpart of a PRD (Product Requirements Document) for engineers. It explains what to build. How you build that ‘what’ is the fun part of the job, but remember that there are multiple paths to achieving a goal, and it’s this stage that can lead to a cause of concern during verification.
Validation is closely related to verification, an externally-oriented process that ensures the final product meets the desired outcome.
Simply put: whoever verifies ensures that the product is built properly according to engineering rules and best practices, and
whoever validates ensures that the proper product is built as required by the buyer(s). In turn, once validated, products must meet user needs as planned.
Obviously, the verification and validation processes are interdependent and include multiple stakeholders, the number of which is increasing in parallel with the product complexity.
A product is initially verified and then validated. With the shared expertise, variety of opinions, and sometimes even interests, verifying a product can turn out to be an exhausting process that places a huge responsibility on verification engineers. (This ‘How to Write an Engineering Requirements Document’ article effectively evaluates the meaning of everyone’s input and how correlated team tasks and responsibilities can be).
Testing Ready Products
Finally, testing is performed once a product is ready. Verification and validation are before the ‘ready’ stage, while testing comes last. Therefore, while verification places the most onus on engineers, validation usually places the onus on the product development manager and the manufacturer.
A close-up of a computer processor.
Application-specific Integrated Circuit Verification
Perhaps the best example to help define verification is application-specific integrated circuit (ASIC) verification, which is used in software electronics for the production of specific-purpose microchips.
An ASIC is commonly used in portable devices, such as handheld computers. If verification for a particular chip is not included in the process, the chip may fail to perform, costing the manufacturer a huge amount of money. Verification in this example involves simulating the performance of the microchip (according to a created testbench) and comparing the test model to the RTL (Register Transfer Level) design.
Verification should not be viewed as part of the testing process. It is an engineering design element based on an established verification methodology.
Verification is by no means exclusive to electronics, and it is extensively applied to industrial electrical equipment and machinery or automotive design, including running engineering validation tests on engineering prototypes and design verification tests to ensure functionality, performance, usability, conformance, safety certification, and reliability.
Design verification tests can include environmental and mechanical testing, as well as mean time between failures (or MTBF) and electromagnetic compatibility testing. It’s a mixed bag that varies depending on the product in question.
A perfect example of what a conundrum verification can be is the autonomous vehicle design, where legal liability is under scrutiny, as described well by The Atlantic referring to Bryant Walker Smith: “autonomous vehicles represent a shift from vehicular negligence to product liability”. On this occasion, verification done poorly will not only increase manufacturing costs but also incur casualties.
The Onus Placed on Verification Engineers
When it comes to working on verification, it is not easy to bear such an onus by yourself. If you decide that this is a career worth pursuing, you will need to gain wholesome experience in a specific field because you will need to make decisions for yourself and your team.
After all, verification engineering requires the necessary technical knowledge to manage interdependent relationships. Therefore, a fair share of interpersonal and communication skills would do you a world of good in handling people during product development. Many of these people skills are gained as you progress through the jobs you take on. Also, expect to do verification and validation in the same job role, as this is perfectly possible.
In the end, you must keep abreast of the industry trends and innovations because they end up writing new standards and regulations—failing to meet them is out of the question.