מהנדס/ת אוטומציה QA בישראל: מה התפקיד עושה, שכר, ואיך נכנסים

מהנדס/ת אוטומציה QA כותב/ת ומתחזק/ת את הקוד שבודק את המוצר במקום אדם, ואחראי/ת על התשתית שמריצה אותו בכל שינוי. בפועל זו משרת פיתוח לכל דבר, עם לקוח פנימי אחד: צוות הפיתוח. בלוח HiTakeJob פתוחות כרגע 10 משרות בקטגוריית QA ועוד 47 שמזכירות CI/CD.

זו משרת פיתוח, ולא נוח לכולם לשמוע את זה

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

המספרים בלוח תומכים בכך: בשדה הקטגוריות יש 12 משרות מסווגות אוטומציית QA ו-15 מסווגות הנדסת אוטומציה, ובכותרות המשרות עצמן 10 משרות שמזכירות QA automation. זהו מקטע פעיל יחסית להיקף ה-QA הכולל, וזו לא במקרה גם הכותרת שמשלמת יותר מבדיקות ידניות. 365 המשרות שמזכירות Python הן אינדיקציה טובה לשפה שנדרשת בחלק גדול מצוותי האוטומציה בארץ.

פירמידת הבדיקות ואיפה שמים כל טסט

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

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

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

בעלות על הפריימוורק ותבנית Page Object

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

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

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

טסטים רועדים ומדיניות הסגר

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

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

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

להריץ את הסוויטה ב-CI

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

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

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

מה בכלל שווה לאטמט

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

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

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

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

שכר - הערכת שוק

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

ותק	שכר חודשי ברוטו (הערכת שוק)	מה מצופה
ג'וניור	14,000 - 20,000 ש"ח	כתיבת בדיקות בתוך פריימוורק קיים
2 - 4 שנים	20,000 - 29,000 ש"ח	עצמאות מלאה, שיפור התשתית, ניפוי כשלים
בכיר/ה	29,000 - 40,000 ש"ח	בעלות ארכיטקטונית, החלטות רוחב על אסטרטגיית בדיקה

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

מסלול הכניסה

שני מסלולים ריאליים, והם דורשים דברים שונים לגמרי:

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

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

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

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

שאלות נפוצות

האם צריך לדעת לתכנת כדי להיות מהנדס/ת אוטומציה?

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

איזו שפה ללמוד?

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

כמה משרות QA פתוחות כרגע?

בקטגוריית QA פתוחות 9 משרות. בשדה הקטגוריות יש בנוסף 12 משרות מסווגות אוטומציית QA ו-15 בהנדסת אוטומציה, ובכותרות המשרות 10 משרות המזכירות QA automation.

מה עושים עם טסט שנכשל לסירוגין?

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

האם אוטומציה מחליפה בדיקות ידניות?

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

מה ההבדל בין בדיקת API לבדיקת ממשק?

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

כמה זמן לוקח לעבור מבדיקות ידניות לאוטומציה?

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