בדיקות פונקציונליות למוצר פיזי

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

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

למה המוצר שלך עובד אבל עדיין לא באמת מוכן

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

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

אבטיפוס הוא הוכחת רעיון, לא הוכחת מוצר

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

אבל לפני שחרור צריך לשאול שאלות אחרות:

• האם כל פונקציה מוגדרת עובדת, ולא רק הפונקציה שהכי קל להדגים?

• האם המוצר מגיב נכון למצבי קצה, כמו מתח נמוך, עומס, הפעלה חוזרת או ניתוק זמני?

• האם אותה בדיקה מחזירה אותה תוצאה, ביחידה הזו וביחידה הבאה?

• האם המשתמש מקבל את ההתנהגות שהובטחה לו, בלי להסתמך על ידע פנימי של צוות הפיתוח?

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

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

למה זה קריטי דווקא לפני ייצור

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

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

מה זה באמת בדיקה פונקציונלית ולא משהו אחר

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

ארבעה מושגים, ארבע שאלות

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

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

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

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

דוגמה שמסדרת את הבלגן

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

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

במוצרים רפואיים-אלקטרוניים, התמונה רחבה עוד יותר. מכון התקנים מציין את סדרת IEC/EN/CSA 60601-1, את משפחות IEC/EN 60601-1-X ו-60601-2-X, וכן את IEC 62304 ו-ISO 14971 כחלק מהמסגרת הרלוונטית לבטיחות ציוד רפואי (בדיקות בטיחות לציוד רפואי במכון התקנים). לכן קריטריוני הקבלה הפונקציונליים צריכים להיגזר כבר מהאפיון, ולא להיכתב אחרי שהאב-טיפוס בנוי.

אילו סוגי בדיקות באמת צריך לפני שמשחררים גרסה

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

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

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

קבלה, סביבה ואמינות

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

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

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

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

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

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

איך בונים סביבת בדיקה שמחזיקה מים

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

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

מה חייב להופיע בפרוטוקול

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

כתבו בו:

• מזהה בדיקה: שם חד-משמעי לגרסה ולתרחיש.

• מטרה: איזו דרישה או פונקציה נבדקת.

• תנאים: מתח, עומס, טמפרטורה, לחות, מצב סוללה וכל תנאי אחר שמשפיע.

• ציוד: כלי המדידה, המתקן והאביזרים.

• צעדים: סדר הפעולות, כולל מצב התחלתי.

• קריטריון קבלה: מה נחשב מעבר ומה נחשב כשל.

• תוצאה: הערך שנמדד, תיאור ההתנהגות והחלטת הבודק.

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

ציוד בסיסי לפי צורך

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

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

ידני מול אוטומטי ואיך מחליטים בלי להתברבר

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

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

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

מתי אוטומציה מתחילה להשתלם

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

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

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

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

במכרז ממשלתי ישראלי לשירותי בדיקות איכות תוכנה נקבע שהיקף הבדיקות הפונקציונליות לא יפחת מ-13% מסך שעות הפיתוח של היחידה הנמסרת לבדיקה (מסמך מכרז שירותי בדיקות איכות תוכנה). זו לא נוסחה לכל מוצר פיזי, אבל היא מזכירה נקודה חשובה: בדיקה היא חלק מעבודת הפיתוח, לא שארית שמקבלים בסוף.

תיעוד, מדדי הצלחה וקבלת החלטות על בסיס נתונים

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

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

מדדים שמייצרים פעולה

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

• אחוז מעבר לפי סוג בדיקה: עוזר לזהות אם הבעיה נמצאת בפונקציה מסוימת או בתהליך הכללי.

• מספר תקלות חוזרות: מראה אם תיקון פתר את שורש הבעיה או רק הסתיר אותה.

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

• עלות תיקון ליחידה: מחברת את החלטת התכן למחיר האמיתי של כשל בייצור.

• כיסוי מקרי בדיקה: מונע מצב שבו מריצים שוב ושוב את אותם תרחישים ומתעלמים מדרישות אחרות.

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

תיעוד שמשרת גם את הייצור

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

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

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

מאבטיפוס לסדרה קצרה לייצור סדרתי

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

שלב האבטיפוס

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

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

שלב הסדרה הקצרה

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

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

שלב הייצור הסדרתי

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

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

בישראל, שירותי בדיקת ציוד רפואי של מכון התקנים כוללים את סדרת 60601, את IEC 62304, את ISO 14971 ומסגרות הסמכה כמו IECEE CB Scheme ו-CSA Data Acceptance Program (שירותי בדיקות לציוד רפואי). בציוד רפואי צריך לקשור בין ביצוע בפועל, תיעוד ודרישות המסלול הרגולטורי. בדיקות פונקציונליות אינן מחליפות validation, integration או EMC. הן משתלבות ברצף בדיקות נפרד, עם שאלות ותנאי קבלה משלהן.

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

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