QA במיקור חוץ פירושו העברת בדיקות התוכנה של המוצר, ידניות ואוטומטיות, לצוות חיצוני שעובד לפי תוכנית בדיקות מוסכמת, מחובר לכלי הפיתוח שלכם ומדווח על תקלות ועל מוכנות הגרסה לשחרור. השירות מתאים כשצריך לבדוק מהר יותר ממה שהצוות הפנימי מסוגל, כשחסרה מומחיות באוטומציה, בעומסים או באבטחה, או כשהמוצר כולל רכיבי תקשורת כמו VoIP, מרכזייה בענן ואפליקציית מובייל.
עיקרי הדברים
- שירות QA חיצוני כולל אסטרטגיית בדיקות, בדיקות ידניות, אוטומציית בדיקות, חיבור ל-CI/CD ודיווח שוטף, ולפי הצורך גם בדיקות עומסים ובדיקות אבטחה.
- בישראל טווח השוק הוא 200 עד 460 ש"ח לשעה לפני מע"מ. במזרח אירופה ובהודו התעריף נמוך יותר, אבל עלות התיאום והניהול עולה.
- אוטומציה משתלמת בתהליכים יציבים שחוזרים בכל גרסה. בדיקות ידניות נשארות הכרחיות לתרחישים חדשים, לחוויית משתמש ולבדיקות חקר.
- במערכות תקשורת בודקים גם את מה שאינו נראה במסך: איתות SIP, איכות שמע, מעבר בין רשתות והתנהגות המרכזייה בענן תחת עומס.
כמה עולה QA במיקור חוץ? מחירי שוק ממוצעים ב-2026, לפני מע"מ
| שירות | טווח מחיר שוק (לפני מע"מ) | יחידה והערה |
|---|---|---|
| QA בישראל, מבדיקות ידניות ועד אוטומציה | 200 עד 460 ש"ח | לשעה, לפי ותק ותחום |
| QA במזרח אירופה | 90 עד 220 ש"ח | לשעה |
| בודק ידני בהודו | 55 עד 160 ש"ח | לשעה |
| בודק אוטומציה בהודו | 75 עד 230 ש"ח | לשעה |
| בדיקות עומסים וביצועים | 18,500 עד 222,000 ש"ח | לפרויקט, לפי מספר התרחישים והממשקים |
| מבדק חדירות לאפליקציה | 18,500 עד 134,000 ש"ח | לפרויקט, כולל בדיקה חוזרת לפי ההסכם |
|
רוצים הצעת מחיר מותאמת לעסק שלכם?
|
||
המחירים הם טווחי שוק לפני מע"מ: הקצה התחתון משקף ספקים קטנים ופרילנסרים, והקצה העליון ספקים גדולים. זה לא מחירון של טלקום אקספרט. הצעה מותאמת מקבלים בלחיצה על הכפתור בשורה הרלוונטית.
הפער בין ישראל לחו"ל נראה גדול על הנייר, אבל הוא לא כל התמונה. צוות בדיקות במזרח אירופה או בהודו דורש תיעוד מפורט יותר, חפיפה בשעות העבודה, ניהול צמוד מצד הלקוח, ולעיתים גם תרגום של ממשק בעברית שמיועד למשתמשים ישראלים. צוות בישראל יקר יותר לשעה, אבל מכיר את המשתמשים, את השפה ואת הרגולציה, וצורך פחות זמן ניהול מצד מנהל הפיתוח. לכן מודל נפוץ הוא היברידי: מוביל QA בישראל שאחראי על האסטרטגיה, על תעדוף התקלות ועל הקשר עם הפיתוח, וצוות ביצוע מרוחק שמריץ מחזורי רגרסיה ומתחזק סקריפטים. בדיקות עומסים ומבדקי חדירות מתומחרים לפי פרויקט, והטווח הרחב נובע מהיקף התרחישים, ממספר הממשקים ומהצורך בסבב בדיקה נוסף אחרי התיקונים.
מה כולל שירות QA במיקור חוץ?
שירות מלא של בדיקות תוכנה במיקור חוץ מתחיל באסטרטגיית בדיקות (Test Strategy): מה בודקים, באיזה עומק, באילו סביבות, ומה נחשב תקלה שעוצרת שחרור. אחריה נכתבים תיקי בדיקה (Test Cases) לתהליכים העסקיים המרכזיים, ומתחילים מחזורי בדיקה קבועים לכל גרסה. הרכיבים העיקריים:
- בדיקות פונקציונליות ובדיקות רגרסיה (Regression), כדי לוודא ששינוי חדש לא שבר יכולת קיימת.
- אוטומציית בדיקות לממשק המשתמש ול-API, בכלים כמו Selenium, Playwright, Appium או Postman.
- בדיקות עומסים וביצועים לפני השקה, קמפיין או מעבר לענן.
- בדיקות אבטחה בסיסיות בתוך מחזור הבדיקות, ומבדק חדירות (Penetration Test) כפרויקט נפרד.
- ניהול תקלות ב-Jira או בכלי שהצוות שלכם כבר עובד בו, ודוח מוכנות לשחרור לפני כל גרסה.
היקף העבודה נקבע לפי המודל: צוות ייעודי שעובד בתוך הספרינטים, בנק שעות למחזורי בדיקה לפני שחרורים, או פרויקט מוגדר כמו הקמת תשתית אוטומציה. ההחלטה על QA חיצוני היא חלק מהחלטה רחבה יותר על מיקור חוץ בעסק: מה מוציאים החוצה, מה משאירים בבית ואיך שומרים על שליטה.
בדיקות ידניות או אוטומציית בדיקות: מה מתאים למוצר שלכם?
השאלה הנכונה איננה ידני או אוטומטי, אלא מה בודקים בכל אחת מהשיטות. אוטומציה טובה לבדיקות שחוזרות על עצמן בכל גרסה ושהתוצאה שלהן ברורה. בדיקה ידנית טובה כשצריך שיקול דעת, למשל בפיצ'ר חדש, בזרימה שמשתנה כל שבוע או בהערכת חוויית המשתמש. ההשוואה הבאה מסכמת את ההבדלים:
| היבט | בדיקות ידניות | אוטומציית בדיקות |
|---|---|---|
| מתי מתאים | פיצ'רים חדשים, ממשק שמשתנה, בדיקות חקר וחוויית משתמש | רגרסיה, API, תהליכים יציבים שחוזרים בכל גרסה |
| מה צריך כדי להתחיל | תיקי בדיקה, סביבת בדיקות ונתוני בדיקה | בנוסף: מסגרת אוטומציה (Framework), סביבה יציבה וחיבור ל-CI/CD |
| עלות לאורך זמן | עולה עם כל גרסה ועם כל תרחיש שנוסף | השקעה גבוהה בהקמה, עלות נמוכה יותר לכל ריצה |
| תחזוקה | עדכון תיקי הבדיקה כשהמוצר משתנה | תיקון סקריפטים כשהממשק משתנה, טיפול בבדיקות לא יציבות |
| החולשה העיקרית | איטיות ותלות בזמינות הבודקים | מוצאת רק את מה שתוכנתה לחפש |
במוצר צעיר שהממשק שלו משתנה כל ספרינט, אוטומציה מוקדמת מדי מייצרת בעיקר תחזוקה. נקודת פתיחה סבירה היא בדיקות API ובדיקות עשן (Smoke Tests) לתהליכים הקריטיים, ורק אחר כך אוטומציה של ממשק המשתמש.
איך ספק QA חיצוני מתחבר ל-CI/CD ולצוות הפיתוח?
ספק בדיקות שעובד נכון לא מקבל קובץ התקנה בסוף החודש. הוא עובד מתוך מאגר הקוד ומערכת המשימות שלכם, והבדיקות האוטומטיות רצות בתוך הפייפליין (Pipeline) הקיים, למשל ב-GitHub Actions, GitLab CI, Jenkins או Azure DevOps. מבנה מקובל: בדיקות עשן קצרות על כל מיזוג קוד, רגרסיה מלאה בלילה או לפני שחרור, ודוח תוצאות שכל הצוות רואה. כך תקלה מתגלה כשהמפתח עוד זוכר מה שינה, ולא שבועיים אחרי.
כדי שזה יעבוד צריך שלושה דברים מצד הלקוח: סביבת בדיקות יציבה שאינה סביבת הייצור, נתוני בדיקה שאינם מידע אישי אמיתי, והרשאות גישה מינימליות לפי תפקיד. סביבת בדיקות יכולה לרוץ על שרת בענן שמוקם ומכובה לפי הצורך, וכך לא תופסת משאבים קבועים. כשגם הפיתוח עצמו נעשה בחוץ, כדאי שהבדיקות יהיו אצל גורם נפרד מצוות הפיתוח, או לפחות תחת אחריות נפרדת, כדי שמי שכותב את הקוד לא יהיה היחיד שמאשר אותו. על המודלים של מיקור חוץ פיתוח תוכנה והחלוקה בין הצוותים הרחבנו במאמר נפרד.
מה כוללות בדיקות טלקום ו-VoIP למרכזיה בענן ולאפליקציות תקשורת?
מערכת תקשורת נכשלת לעיתים קרובות במקומות שבודק תוכנה כללי לא מסתכל עליהם. הממשק יכול לעבור את כל הבדיקות, והשיחה עדיין תתנתק בהעברה, תישמע רק בכיוון אחד מאחורי NAT, או תיפול כשהטרנק מגיע לשיא שיחות במקביל. בדיקות טלקום ו-VoIP דורשות סביבת מעבדה עם שלוחות, סופטפונים ומחוללי שיחות, ויכולת לדמות תנאי רשת גרועים. מה בודקים בפועל:
- איתות SIP: רישום שלוחות, הקמת שיחה, העברה, המתנה, שיחת ועידה וניתוב לפי שעות פעילות.
- איכות שמע: השהיה (Latency), ריצוד (Jitter) ואיבוד מנות, ומדד MOS להערכת איכות השיחה.
- קודקים, NAT וחומת אש: שמע דו כיווני בכל שילוב של רשת ומכשיר, והצפנה ב-TLS וב-SRTP כשהיא נדרשת.
- תפריט קולי (IVR), תורים, הקלטת שיחות ותמלול, כולל התנהגות כשהשירות החיצוני לא זמין.
- שרידות: מעבר לגיבוי (Failover) כשקו או שרת נופלים, וחזרה מסודרת למצב רגיל.
- אינטגרציות: חיוג מתוך CRM, חלון לקוח בשיחה נכנסת ותיעוד השיחה במערכת.
אותו היגיון חל על אפליקציות תקשורת מבוססות WebRTC, על מערכות SMS ועל מוקדי שירות. מי שמזמין בדיקות למערכת כזו צריך לוודא שבצוות יש מי שמבין פרוטוקולי תקשורת ויודע לקרוא לכידת תעבורה, ולא רק להריץ תסריט בממשק.
איך עושים בדיקות מובייל במיקור חוץ?
בדיקות מובייל מתחילות במטריצת מכשירים: אילו דגמים, אילו גרסאות Android ו-iOS ואילו גדלי מסך מייצגים את המשתמשים שלכם בפועל. את הרשימה כדאי לגזור מנתוני האנליטיקה של המוצר ולא מניחוש. אמולטורים מתאימים לבדיקות פיתוח מהירות, אבל לפני שחרור צריך מכשירים אמיתיים, מקומיים או בחוות מכשירים בענן (Device Farm). מעבר לפונקציונליות בודקים התנהגות ברשת חלשה ובמעבר בין Wi-Fi לרשת סלולרית, התראות דחיפה, צריכת סוללה, הרשאות, תצוגה מימין לשמאל ונגישות.
באפליקציות תקשורת יש שכבה נוספת: שיחה נכנסת כשהאפליקציה סגורה או ברקע, השתלבות במסך השיחות של מערכת ההפעלה, שיחה סלולרית שנכנסת באמצע שיחת VoIP, ומעבר שיחה בין אוזניות Bluetooth לרמקול. כאן נוצרות רוב התלונות של משתמשים, והן כמעט לא נתפסות בבדיקה על אמולטור. לפני הגשה לחנויות בודקים גם עמידה בהנחיות של Apple ו-Google, כדי לא לגלות בעיה רק אחרי דחייה.
מתי צריך בדיקות עומסים ובדיקות אבטחה?
בדיקות עומסים נדרשות לפני השקה, לפני קמפיין שצפוי להביא תנועה חריגה, אחרי שינוי ארכיטקטורה ולפני מעבר לענן. הכלים הנפוצים הם JMeter, k6 ו-Gatling, אבל הכלי פחות חשוב מהגדרת היעד: כמה משתמשים או שיחות במקביל, איזה זמן תגובה מקובל, ומה קורה כשחוצים את הסף. במרכזייה בענן או במוקד שירות, עומס פירושו גם שיחות במקביל על הטרנק וגם פניות במקביל לממשקי ה-API, ושתיהן צריכות להיבדק יחד.
בדיקות אבטחה מתחלקות לשתי שכבות. השכבה הראשונה היא בדיקות בסיסיות לפי OWASP בתוך מחזור הבדיקות הרגיל: הרשאות, הזדהות, טיפול בקלט ונתונים רגישים. השכבה השנייה היא מבדק חדירות מקצועי לפני שחרור משמעותי או לפי דרישת לקוח ורגולציה. בכל מקרה, נתוני הבדיקה צריכים להיות מותממים או סינתטיים, בהתאם לחוק הגנת הפרטיות ולתיקון 13. מבדקי חדירות ומדיניות אבטחת מידע מקבלים טיפול נפרד מצוות ה-QA, אבל התוצאות שלהם צריכות להיכנס לאותה מערכת ניהול תקלות.
איך מודדים ספק QA ומה מכניסים להסכם?
מספר התקלות שהספק פתח הוא מדד חלש, כי הוא מעודד דיווח על פרטים שוליים. מדדים שימושיים יותר:
- תקלות שדלפו לייצור (Escaped Defects) ביחס לתקלות שנתפסו לפני השחרור.
- זמן משוב: כמה זמן עובר מגרסה מוכנה לבדיקה ועד תשובה ברורה אם אפשר לשחרר.
- כיסוי של התהליכים העסקיים הקריטיים, לא כיסוי קוד כללי.
- יציבות האוטומציה: כמה בדיקות נכשלות בלי שיש תקלה אמיתית.
- איכות דיווח התקלה: האם מפתח יכול לשחזר אותה בלי לחזור לבודק עם שאלות.
בהסכם עצמו כדאי לקבוע שסקריפטי הבדיקה, תיקי הבדיקה והתיעוד שייכים לכם ונשמרים במאגר שבבעלותכם, להגדיר הסכם סודיות וכללי טיפול במידע, לפרט זמני תגובה לגרסה דחופה, ולכתוב תוכנית יציאה שמאפשרת להעביר את העבודה לספק אחר או לצוות פנימי בלי לאבד ידע.
מתי לא כדאי להוציא QA למיקור חוץ?
יש מצבים שבהם QA חיצוני לא יפתור את הבעיה. כשאין דרישות כתובות והמוצר משתנה כל יום, הספק יבזבז את רוב הזמן על בירורים. כשהמוצר דורש ידע עסקי עמוק ונדיר, למשל תהליכים רגולטוריים ייחודיים, צריך לפחות אדם פנימי אחד שמחזיק את הידע. וכשהמוצר קטן ומשוחרר לעיתים רחוקות, בנק שעות נקודתי עדיף על צוות קבוע.
גם כשמוציאים את הבדיקות החוצה, כמה דברים נשארים בבית: הבעלות על איכות המוצר, ההחלטה הסופית אם לשחרר גרסה, הגדרת קריטריוני הקבלה, והגישה לסביבת הייצור. ספק יכול לבצע ולהמליץ, אבל האחריות על מה שמגיע ללקוחות נשארת אצלכם.
מה טלקום אקספרט מספקת בתחום בדיקות התוכנה?
טלקום אקספרט מספקת שירותי מחשוב, פיתוח תוכנה ואבטחת מידע, בעצמה ועם שותפים עסקיים, ובכלל זה בדיקות תוכנה ואוטומציה במיקור חוץ. הייחוד של העבודה בתחום הבדיקות הוא הרקע ההנדסי בתקשורת: מרכזיות בענן, VoIP, רשתות ואפליקציות תקשורת, שם נדרשת הבנה של פרוטוקולים ולא רק של ממשק משתמש. הבדיקות יכולות לעמוד בפני עצמן או להשתלב בשירותי מיקור חוץ IT רחבים יותר לעסק.
תהליך העבודה מתחיל באפיון: מה המוצר, אילו תהליכים קריטיים, אילו סביבות ואילו כלים כבר קיימים. אחריו מגיעה הצעה עם מודל עבודה מתאים, צוות ייעודי, בנק שעות או פרויקט. בשלב ההטמעה מוקמות תוכנית הבדיקות, תשתית האוטומציה והחיבור לפייפליין, ואחר כך מגיע ליווי שוטף עם דוחות לכל גרסה ובחינה תקופתית של המדדים.
לבדיקת התאמה של שירות QA למוצר שלכם, ולתכנון בדיקות למערכת תקשורת או לאפליקציה, אפשר לפנות בטלפון 077-8123111.
שאלות נפוצות
זה תלוי בעיקר במצב התיעוד ובזמינות הסביבות. כשיש דרישות כתובות, סביבת בדיקות יציבה וגישה מסודרת למערכת המשימות, הצוות מתחיל מלמידת המוצר ומיפוי התהליכים הקריטיים, ומבצע מחזור רגרסיה ראשון כבר בשלב מוקדם. כשאין תיעוד, השלב הראשון הוא בעצם כתיבת תיקי הבדיקה, וזה לוקח יותר זמן. כדאי להגדיר מראש מה ייחשב סיום תקופת הקליטה, למשל מחזור רגרסיה מלא ודוח מוכנות ראשון.
כן, וזה מודל נפוץ. בודק פנימי שמכיר את המוצר ממשיך לבדוק פיצ'רים חדשים ולתת משוב על חוויית המשתמש, וספק חיצוני מקים את מסגרת האוטומציה, כותב את סקריפטי הרגרסיה ומחבר אותם לפייפליין. התנאי להצלחה הוא בעלות ברורה: מי מחליט אילו תרחישים עוברים לאוטומציה, ומי מטפל בבדיקה שנכשלת בלילה. בלי ההגדרה הזו, הבדיקות האוטומטיות נזנחות אחרי כמה חודשים.
תחזוקה היא חלק קבוע מהעבודה ולא תוספת. כל שינוי בממשק או בזרימה דורש עדכון של הסקריפטים הרלוונטיים, ולכן כדאי שההסכם עם הספק יכלול שעות תחזוקה לכל ספרינט. כדי להקטין את העומס, מבקשים מהמפתחים להוסיף מזהים קבועים לרכיבי הממשק, ובונים את הבדיקות בשכבות כך ששינוי במסך אחד מחייב תיקון במקום אחד בלבד.
ככלל, עדיף שלא. חוק הגנת הפרטיות ותיקון 13 מטילים על העסק אחריות למידע אישי גם כשמי שמעבד אותו הוא ספק חיצוני. הדרך המקובלת היא סביבת בדיקות עם נתונים סינתטיים או מותממים, שמשמרים את מבנה המידע בלי לחשוף אנשים אמיתיים. אם אין ברירה, מגדירים בהסכם את כללי הגישה והאבטחה, מגבילים הרשאות לפי תפקיד ומתעדים מי ניגש למה ומתי.
לא מחליפים, אבל משנים את העבודה. כלים מבוססי בינה מלאכותית עוזרים לכתוב טיוטות של תיקי בדיקה, להציע תרחישים חסרים, לתקן סקריפטים שנשברו אחרי שינוי בממשק ולסכם תוצאות ריצה. ההחלטה מה חשוב לבדוק, הבנת ההקשר העסקי ושיקול הדעת אם תקלה מעכבת שחרור נשארים אצל בודק אנושי. ספק QA שעובד עם הכלים האלה יכול לכסות יותר תרחישים באותו זמן.
עובדים בסביבה נפרדת: טננט (Tenant) או מרכזייה ייעודית לבדיקות, עם שלוחות בדיקה ומספרי טלפון שאינם משויכים ללקוחות. בדיקות עומס מריצים מול הסביבה הזו בלבד, בתיאום עם ספק הטרנק כדי לא לחרוג ממגבלות הקו. כשחייבים לאמת משהו בסביבת הייצור, למשל ניתוב של מספר חדש, עושים זאת בחלון זמן מתואם ובהיקף מינימלי של שיחות בודדות.
