מה זה V&V Engineer? הסבר פשוט + כמה משרות פתוחות בישראל

זמן קריאה: 7 דקות

V&V Engineer הוא מהנדס אימות ותיקוף: מי שמוכיח בראיות מתועדות שהמוצר נבנה נכון לפי המפרט, ושהמוצר הנכון נבנה מבחינת הצורך האמיתי של המשתמש. התפקיד נפוץ במכשור רפואי, בתעופה, בביטחוני וברכב, שם הראיה חשובה לא פחות מהתוצאה. בלוח HiTakeJob פתוחות כרגע 9 משרות בקטגוריית QA.

Verification מול Validation: ההבדל המדויק

שתי המילים מתורגמות בעברית לעיתים לאותו דבר, וזה מקור הבלבול. ההבחנה המקובלת קצרה: verification שואל האם בנינו את המוצר נכון, ו-validation שואל האם בנינו את המוצר הנכון.

ממד	Verification - אימות	Validation - תיקוף
מול מה בודקים	מפרט הדרישות הכתוב	הצורך האמיתי של המשתמש או המטופל
השאלה	האם המימוש תואם את מה שהוגדר	האם מה שהוגדר פותר את הבעיה
מתי מתבצע	לאורך הפיתוח, אחרי כל רמת עיצוב	לקראת הסוף, על המוצר השלם
סביבה	מעבדה, סימולציה, ספסל בדיקה	שימוש מייצג, לעיתים בסביבה קלינית
דוגמה	המכשיר מתריע מעל ארבעים מעלות, כנדרש	אחות באמת שמה לב להתראה בתנאי מחלקה

הדוגמה בשורה האחרונה היא המהות. מכשיר יכול לעבור אימות מושלם - כל דרישה מומשה במדויק - ולהיכשל בתיקוף, אם ההתראה נשמעת בעוצמה שנבלעת ברעש המחלקה. זה בדיוק סוג הכשל שמתגלה מאוחר ויקר, ולכן קיים תפקיד ייעודי שמחזיק את שני הצדדים.

מכאן נובעת גם ההיררכיה של המסמכים. בראש יושבות דרישות המשתמש, מתחתן דרישות המערכת שהן תרגום הנדסי מדיד של הראשונות, ומתחת להן מפרטי העיצוב. Verification מתבצע בכל מעבר בין רמה לרמה, ו-validation נעשה רק מול הרמה העליונה. מי שמערבב בין השתיים מוצא את עצמו בודק את המוצר מול עצמו: כותב בדיקה שנגזרת מהמימוש ולא מהדרישה, ואז כל בדיקה עוברת בהצלחה בלי שהוכח דבר.

מטריצת עקיבות: מדרישה לראיה

מטריצת עקיבות היא הטבלה שמקשרת כל דרישה אל המקום שבו היא מומשה ואל הבדיקה שמוכיחה אותה. בלעדיה אי אפשר לענות על שתי שאלות שנשאלות תמיד: האם כל דרישה נבדקה, והאם קיימת בדיקה שאינה נגזרת מדרישה כלשהי.

עמודה	מה יושב בה	מה מגלה כשהיא ריקה
דרישת משתמש	מה המשתמש צריך, בשפתו	פיצ'ר שפותח בלי צורך מוגדר
דרישת מערכת	התרגום ההנדסי המדיד	דרישה שלא ניתנת לבדיקה
מפרט עיצוב	הרכיב או המודול שמממש	דרישה שאיש לא לקח עליה אחריות
מקרה בדיקה	הפרוטוקול שמוכיח	דרישה שלא נבדקה כלל
תוצאה וראיה	הדוח, הקובץ, הצילום	בדיקה שבוצעה ולא תועדה
ניתוח סיכון	הסיכון שהדרישה מפחיתה	אמצעי בקרה שאינו מקושר לסיכון

העמודה האחרונה היא מה שמבדיל את התחום מבדיקות תוכנה רגילות. בסביבות מוסדרות, כל אמצעי בקרה שנועד להפחית סיכון חייב להיות מקושר לסיכון שזוהה ולראיה שהוא אכן עובד. מטריצה שבה קיים אמצעי בקרה בלי סיכון מקושר, או סיכון בלי אמצעי, היא ממצא בפני עצמו.

מבחינה מעשית, המטריצה מתוחזקת בכלי ניהול דרישות כמו Jama, Polarion, DOORS או Helix ALM, ובצוותים קטנים גם בגיליון אלקטרוני מסודר. ההבדל בין כלי ייעודי לגיליון מתגלה כשדרישה משתנה: בכלי ייעודי כל הבדיקות שנגזרו ממנה מסומנות מיד כדורשות בחינה מחדש, ובגיליון מישהו צריך לזכור. בפרויקט עם אלף דרישות, ההפרש הזה הוא בדיוק ההבדל בין תיק שלם לתיק שיתגלה כחסר חודשיים לפני ההגשה.

פרוטוקול, ביצוע, דוח: איך בדיקה נראית על הנייר

בעולם V&V אסור להריץ בדיקה ואז לכתוב מה קרה. הסדר הפוך, וזו הנקודה שהכי קשה למי שמגיע מפיתוח תוכנה מהיר:

כתיבת פרוטוקול - מטרת הבדיקה, הדרישה שהיא מוכיחה, הציוד וכיולו, תנאי הסביבה, השלבים המדויקים וקריטריון הקבלה - הכל לפני שמריצים.
אישור הפרוטוקול - חתימה של הגורמים הרלוונטיים, כדי שקריטריון הקבלה לא ייקבע אחרי שראו את התוצאה.
ביצוע מבוקר - על גרסה מוגדרת של המוצר, עם תיעוד מספרים סידוריים וגרסאות קושחה, וכל סטייה נרשמת בזמן אמת.
טיפול בחריגות - כל אי התאמה נפתחת כרשומה, מנותחת לשורש ונסגרת בהחלטה מתועדת: תיקון, בדיקה חוזרת או הצדקה מנומקת.
דוח סיכום - תוצאה מול קריטריון, הראיות הגולמיות כנספח, ומסקנה חד משמעית של עבר או נכשל.

בציוד ייצור ובמערכות ממוחשבות מתווסף רצף ההסמכה המוכר - IQ לוודא שהותקן נכון, OQ לוודא שהוא פועל כנדרש בטווח, ו-PQ לוודא שהוא מבצע את התהליך האמיתי בתנאי עבודה. הרצף הזה מופיע גם בהקשר של ייצור מוצרי חומרה, ומי שרוצה את הצד השני של אותו עולם ימצא אותו במאמר מה זה NPI Engineer.

איפה V&V הוא חלק מהותי מהתהליך

בשלושה תחומים הפרקטיקה הזו היא חלק מובנה מאופן העבודה, ולא בחירה של הצוות. התיאור כאן הוא של הנוהג המקצועי בשטח, ואינו ייעוץ רגולטורי - כל קביעה לגבי תחולה או דרישה חלה נקבעת מול גורם מוסמך.

תחום	מה מאפיין את העבודה	סוג הראיה שנדרשת
מכשור רפואי	ניהול סיכונים לאורך מחזור החיים, תיקוף שימושיות	תיק תכן מלא, מטריצת עקיבות, דוחות תיקוף
תוכנה רפואית	סיווג לפי רמת הנזק האפשרי, ניתוח רכיבי צד שלישי	תיעוד מחזור חיים, בדיקות יחידה עד מערכת
תעופה ואוויוניקה	רמות חומרה, כיסוי מבני של הקוד, עצמאות בין תפקידים	ראיות כיסוי, סקירות מתועדות, מעקב דרישות
רכב	ניתוח כשל ובטיחות תפקודית, בדיקות בתנאי קיצון	תיק בטיחות, תוצאות בדיקות סביבה
ציוד ייצור	הסמכת מכונות ותהליכים, בקרת שינויים	חבילות IQ, OQ ו-PQ חתומות

המשותף לכולם: התוצר של הצוות אינו רק מוצר תקין אלא גם ערימת ראיות שניתן להציג לגורם חיצוני שנים אחר כך. בשדה הקטגוריות של הלוח מסומנות כרגע 4 משרות תחת MEDICAL_AND_REGULATORY, לצד 46 תחת QUALITY_ASSURANCE ו-5 תחת QUALITY_ENGINEERING.

חבילת הראיות שמוגשת

בסוף פרויקט נאסף תיק שמורכב מפריטים קבועים. מהנדס V&V שמתראיין נשאל לעיתים קרובות מה הוא כלל בתיק האחרון שלו, והתשובה מגלה מיד את רמת הניסיון:

תוכנית V&V - מה ייבדק, באיזו שיטה, מי אחראי, ומה נחשב סיום.
מפרט דרישות מאושר בגרסה נעולה, שאליה מתייחסות כל הבדיקות.
מטריצת עקיבות מלאה ללא שורות ריקות בשני הכיוונים.
פרוטוקולים חתומים לפני ביצוע, ודוחות אחרי ביצוע.
ראיות גולמיות - קבצי מדידה, צילומי מסך, תעודות כיול של מכשירי המדידה.
רשימת חריגות עם סטטוס סגירה והנמקה לכל אחת.
דוח סיכום עם מסקנה מפורשת והפניה לכל הנספחים.

הכישלון הנפוץ ביותר אינו בדיקה שנכשלה אלא ראיה חסרה: בדיקה שבוצעה בפועל אבל תועדה חלקית, או מכשיר מדידה שתעודת הכיול שלו פגה באמצע הסדרה. במקרה כזה הבדיקה כולה עלולה להידרש שוב, ולכן ניהול הכיולים והגרסאות הוא חלק שגרתי מהתפקיד.

נקודה מעשית נוספת היא ההפרדה בין מי שמבצע למי שסוקר. בסביבות מוסדרות נהוג שהמבצע והמאשר אינם אותו אדם, ובחלק מהתחומים נדרשת גם עצמאות ארגונית בין מי שפיתח למי שבודק. בצוותים קטנים זו מגבלה כואבת, כי אותו מהנדס מכיר את המערכת הכי טוב, אבל היא בדיוק מה שמונע מבדיקה להיכתב סביב ההתנהגות שכבר קיימת.

V&V מול QA תוכנה ואוטומציה

שני התחומים חולקים כלים אבל נבדלים במטרה. בודק תוכנה מחפש באגים כדי לשפר את המוצר לפני שחרור; מהנדס V&V מייצר ראיה שדרישה מסוימת מתקיימת. מכאן נובעים ההבדלים: קצב איטי יותר, תיעוד כבד יותר, ופחות סובלנות לשינוי בדיעבד.

האוטומציה נוכחת גם כאן, אבל תחת אילוץ נוסף - כלי הבדיקה עצמו נדרש להיות מתוקף. סקריפט שמריץ בדיקה ומדפיס תוצאה צריך להוכיח שהוא מדווח נכון, אחרת הראיה שהוא מייצר חסרת ערך. זו הסיבה שצוותים בסביבות מוסדרות נוטים לכלים ותיקים ויציבים על פני החדשים ביותר. השוואה מפורטת בין הגישות מופיעה במאמרים מה זה אוטומציית בדיקות ומה זה בדיקות ידניות.

מבחינת שוק העבודה בישראל, משרה אחת בלבד נושאת V&V בכותרת כרגע, אך התפקיד מתפרסם גם תחת verification engineer, מהנדס איכות ומהנדס בדיקות - ולכן חיפוש לפי תוכן המשרה עדיף על חיפוש לפי שם.

שאלות נפוצות

מה זה V&V Engineer במילים פשוטות?

מהנדס שמוכיח בראיות מתועדות שהמוצר עומד בדרישות שהוגדרו לו, ושאותן דרישות באמת פותרות את צורך המשתמש. הוא כותב פרוטוקולים, מריץ אותם ומרכיב תיק ראיות.

מה ההבדל בין verification ל-validation?

Verification בודק מול המפרט - האם בנינו את המוצר נכון. Validation בודק מול הצורך האמיתי - האם בנינו את המוצר הנכון. אפשר לעבור את הראשון במלואו ולהיכשל בשני.

מה זו מטריצת עקיבות?

טבלה שמקשרת כל דרישה למימוש שלה, לבדיקה שמוכיחה אותה, לראיה שנוצרה ולסיכון שהיא מפחיתה. היא מגלה דרישות שלא נבדקו ובדיקות שאינן נגזרות מדרישה.

למה כותבים את הפרוטוקול לפני הבדיקה?

כדי שקריטריון הקבלה ייקבע לפני שרואים את התוצאה. פרוטוקול שנכתב אחרי הריצה אינו ראיה, כי אי אפשר לשלול שהקריטריון הותאם למה שיצא.

האם V&V זה אותו דבר כמו QA?

לא. QA בתוכנה מחפש באגים לשיפור המוצר. V&V מייצר ראיה מתועדת שדרישה מתקיימת, בקצב איטי יותר ועם תיעוד כבד יותר, ולרוב בסביבות מוסדרות.

איזה רקע נדרש?

תואר בהנדסה - חשמל, ביו רפואית, מכונות או תוכנה - ולעיתים רקע בבדיקות. חשובות יכולת כתיבה טכנית מדויקת באנגלית, סדר בתיעוד ונוחות בעבודה מול מסמכי דרישות.

כמה משרות רלוונטיות פתוחות בלוח?

בקטגוריית QA פתוחות 10 משרות. בשדה הקטגוריות מסומנות 46 משרות תחת QUALITY_ASSURANCE, 5 תחת QUALITY_ENGINEERING ו-4 תחת MEDICAL_AND_REGULATORY.