TestIL Podcast

איך מזהים מה באמת עוצר עובדים וצוותים, וכיצד מובילים אותם להצלחה?

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

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

המודל מאפשר לבחון את האתגר באמצעות שלושה מרכיבים:

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

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

האם העובד רוצה לבצע את המשימה? האם הוא מבין את חשיבותה ומרגיש מחובר למטרה?

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

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

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

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

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

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

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

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

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

מה מקשה עליך לבצע את המשימה?

איזה ידע או כלי חסר לך כדי להתקדם?

עד כמה המשימה ברורה לך?

מה יכול לעזור לך להצליח?

האם יש משהו בסביבת העבודה שמעכב אותך?

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

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

Skill: האם העובד יודע כיצד להשתמש בכלי AI בצורה יעילה, אחראית ומקצועית?

Will: האם העובד רואה ערך בטכנולוגיה החדשה, או שהוא חושש מהשפעתה על תפקידו?

Hill: האם הארגון מספק כלים מתאימים, מדיניות ברורה, זמן ללמידה וסביבה שתומכת בהתנסות?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

השיחה עוברת מההתנסות הראשונית ב־ChatGPT וב־GitHub Copilot, דרך Roo Code, ועד לעבודה עם Cursor ו־Claude Code. ירון מתאר כיצד הסיוע של AI הקל עליו במעבר בין שפות תכנות ואפשר לו להתמקד יותר במטרת הפתרון ובהיגיון שמאחוריו.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

במהלך הפרק אנחנו צוללים לעולם של Performance Testing ו-Load Testing, מבינים מדוע התחום עדיין מהווה אתגר עבור ארגונים רבים, איך נכון לתכנן בדיקות ביצועים ועומסים, כיצד המעבר לענן משנה את כללי המשחק – וכמובן, כיצד AI נכנס לתמונה ומשנה גם את התחום הזה.

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

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

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

מתוך הצורך הזה נולד פרויקט Oxygen, ובהמשך נבנתה סביבו פלטפורמה רחבה יותר להרצה, ניהול, Reporting וניתוח של בדיקות אוטומטיות. בשנת 2018 הוקמה CloudBeat באופן רשמי.

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

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

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

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

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

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

בפרק עולה החשיבות של הגדרת Performance Criteria כבר בשלבי התכנון של המערכת.

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

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

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

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

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

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

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

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

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

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

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

חלק משמעותי מהשיחה מוקדש להשפעה של Generative AI על עולם ה-QA בכלל ועל אוטומציה ובדיקות ביצועים בפרט.

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

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

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

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

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

הפרק עוסק גם בבדיקות ביצועים ועומסים באפליקציות מובייל.

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

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

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

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

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

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

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

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

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

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

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

קישור לפרופיל לינקדאין של נחום: https://www.linkedin.com/in/ndimer/

קישור לפרופיל חברת CloudBeat: https://cloudbeat.io

קישור לפרופיל לינקאין של ניצן: https://www.linkedin.com/in/ngqa/

קישור לפרופיל לינקדאין של נתנאל: https://www.linkedin.com/in/netanel-harush/

קישור לקבוצת הוואצאפ השקטה של ITCB: https://bit.ly/TestIL_Whatsapp

בפרק 87 של הפודקאסט של TestIL מבית ITCB, ניצן גולדנברג מארח את רם רחמים ולס טל, מפתח אוטומציה ואיש AI, לשיחה מעשית על הדרך שבה כלי AI ו-Vibe Coding משנים את עולם האוטומציה ובדיקות התוכנה.

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

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

השיחה נוגעת גם באחד העקרונות החשובים ביותר בעבודה עם Vibe Coding: לא להתחיל מהקוד – להתחיל מהתכנון. עבודה ב-Plan Mode, הגדרת ארכיטקטורה, בניית Knowledge Base, כתיבת Rules ומתן הקשר נכון לסוכן יכולים לעשות את ההבדל בין פרויקט שהולך ומסתבך לבין פתרון שניתן להמשיך ולפתח.

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

אבל האם באמת אפשר לתת ל-AI לכתוב לנו את האוטומציה?

רם וניצן מדברים על הצורך ב-Human Review וב-Code Review גם בעידן הסוכנים: לבדוק שהקוד עומד בקונבנציות של הפרויקט, שלא נוצרות פונקציות כפולות, שה-Locators יציבים, שאין טסטים מיותרים ושקוד שנוצר על ידי AI לא נכנס אוטומטית ל-Repository בלי בקרה.

השיחה ממשיכה גם לעתיד המקצוע: האם בודקים ידניים וג'וניורים יוכלו ליצור אוטומציה באמצעות שפה טבעית? האם בעתיד נכתוב פחות Test Cases ויותר Intentions ו-Prompts? ומה הופך את איש האוטומציה ממי שכותב כל שורת קוד בעצמו למי שמתכנן, מנחה, מבקר ומנהל סוכני AI?

Vibe Coding בעולם הבדיקות והאוטומציה

Playwright MCP מול Stagehand

בניית אוטומציה באמצעות שפה טבעית

Plan Mode לפני Agent Mode

חשיבות הארכיטקטורה גם כש-AI כותב את הקוד

Logs ככלי מרכזי להבנת התנהגות הסוכן

Knowledge Base ו-Rules לסוכני AI

Prompt Engineering וחיסכון בטוקנים

יצירת קוד Playwright מתרחיש שנוצר באמצעות AI

Code Review לקוד שנכתב על ידי סוכנים

מניעת Flaky Tests ו-Locators לא יציבים

שילוב AI בתהליכי Git, Pull Requests ו-Code Review

שימוש בסוכנים לחקירת תקלות וכישלונות אוטומציה

האפשרות לבנות "Super Agent" שמפקח על סוכנים אחרים

תפקידו המשתנה של מפתח האוטומציה

המיומנויות שבודקי תוכנה צריכים להתחיל לפתח כבר היום

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

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

🎙️ פרק 87 – סיפור מהשטח על AI, Vibe Coding והדור הבא של אוטומציית הבדיקות.

קישור לפרופיל לינקדאין של רם: https://www.linkedin.com/in/ram-walas-tal-b1830770/

קישור לקבוצת הוואצאפ השקטה של testil: https://bit.ly/TestIL_Whatsapp

הבינה המלאכותית כבר משנה את הדרך שבה אנחנו מפתחים ובודקים תוכנה – אבל האם היא באמת בדרך להחליף את אנשי ה-QA, או דווקא להפוך אותם לאנשי מקצוע חזקים ויעילים יותר?

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

במהלך הפרק אנחנו מדברים על השינוי בתפקידו של הבודק, על השילוב בין בדיקות ידניות, אוטומציה ובינה מלאכותית, ועל הדרך שבה כלים כמו Claude, Cursor, Playwright, MCP ו-CLI מאפשרים לבצע היום בתוך דקות או שעות משימות שבעבר דרשו ימים ואפילו שבועות.

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

אבל לצד היתרונות, אנחנו עוסקים גם בשאלה החשובה יותר – האם אפשר באמת לסמוך על התוצרים של ה-AI?

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

אנחנו מדברים גם על הסכנה להפוך ל-"Lazy Testers", על החשיבות של שמירת הידע המתודולוגי והחשיבה הביקורתית, ועל הדרך הנכונה להשתמש ב-AI ככלי ללמידה, סקירה והאצת העבודה – ולא כתחליף להבנה המקצועית.

ולבסוף אנחנו מסתכלים קדימה: איך ייראה תפקיד ה-QA בעוד חמש שנים? האם הבודק יהפוך יותר ויותר ל-AI Operator שמנהל סוכנים, תהליכים ואורקסטרציה? ואילו יכולות יצטרכו אנשי QA כדי להישאר רלוונטיים בעולם שבו חלק גדול מהעבודה הטכנית כבר יכול להתבצע עבורם?

המסר המרכזי שלנו מהפרק פשוט:

אל תפחדו מה-AI – תלמדו אותו, תתנסו בו ותשלבו אותו בעבודה. אבל אל תתנו לו להחליף את החשיבה שלכם.

ה-AI כנראה לא יסיים את עולם הבדיקות – הוא פשוט משנה את הדרך שבה אנחנו עושים QA.

קישור לפרופיל לינקדאין של ניצן: https://www.linkedin.com/in/ngqa/

קישור לפרופיל לינקדאין של נתנאל: https://www.linkedin.com/in/netanel-harush/

קישור לקבוצת הוואצאפ לעדכונים של ITCB: 

https://bit.ly/TestIL_Whatsapp

בפרק 85 של הפודקאסט של TestIL מבית ITCB, נתנאל הרוש מארח את גיא דנביץ' לשיחה מעשית על אחת השאלות שמעסיקות כיום כמעט כל צוות QA: איך מכניסים בינה מלאכותית לתהליכי הבדיקות בארגון – ולא רק מדברים עליה?

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

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

כיום הוא עובד ב-Vonage, שנרכשה על ידי Ericsson, ועוסק בבדיקות של פלטפורמה בתחום התקשורת המשלבת יכולות AI ו-Agentic Workflows.

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

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

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

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

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

נושא שחוזר לאורך הפרק הוא Context.

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

גיא משתף בדוגמאות משימוש ב-AI לצורך Debugging. במקרה אחד, לאחר שסיפק למודל מספיק רקע על המערכת וה-Backend, ה-AI הציע כיוון שהצוות לא חשב עליו – והוא אכן הוביל לפתרון הבעיה.

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

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

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

הבנה וסיכום של מסמכי דרישות ו-FRD מורכבים.

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

סיוע בתכנון בדיקות וביצירת Test Cases.

כתיבת SDD ראשוני.

Debugging וניתוח תקלות.

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

בנייה ותחזוקה של בדיקות API.

יצירת Collections וטסטים ב-Postman.

יצירת תיעוד ל-API.

שימוש ב-Agent Mode וב-MCP לצורך חיבור תהליכים וכלים.

עם זאת, גיא מדגיש כי כל תוצר של AI עדיין דורש Human Review. ככל שהמערכת או הפיצ'ר מורכבים יותר, כך גדלה החשיבות של אימות התוצאה.

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

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

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

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

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

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

לאחר שגילה את יכולות ה-Agent Mode של Postman והבין שהן יכולות לסייע ב-Debugging, בבניית Tests ו-Collections, ביצירת Documentation ובאינטגרציות, הוא הציג את הרעיון לראש הצוות וקיבל תמיכה להתקדם.

אלא שאז הגיע המחסום הארגוני: הכלי לא היה מאושר לשימוש.

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

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

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

כן – אבל לא בצורה מוחלטת.

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

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

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

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

לכן בשלב הנוכחי AI מקצר תהליכים יותר משהוא מבטל אותם.

גיא משתף גם בכלים ובתשתיות שבהם הצוות עושה שימוש כיום.

אחד הכלים המרכזיים הוא Postman AI, שמשתלב בתשתית אוטומציית API קיימת ומאפשר לסייע ביצירת בדיקות, Collections, Debugging, Documentation ואינטגרציות.

בנוסף, הצוות עושה שימוש ב-GitHub Copilot ומתחיל לעבוד עם Playwright ויכולות Agentic הקשורות אליו.

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

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

השילוב מאפשר למערכת להבין בצורה טובה ומהירה יותר את כוונת המשתמש ולפשט משמעותית את בניית ה-Workflow של הסוכן.

לדוגמה, תהליך שבעבר היה דורש כ-30 Nodes עשוי כעת להיבנות באמצעות כ-15 בלבד – קיצור של כ-50%.

בצד הבדיקות, אחת היכולות הבולטות מבחינתו היא Agent Mode של Postman, שמאפשר באמצעות הנחיות בשפה טבעית לבנות Collections, ליצור Tests, לבצע Debugging, לכתוב Documentation ואף לעבוד עם MCP וכלים חיצוניים.

עדיין לא.

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

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

לכן בשלב הנוכחי AI חזק במיוחד ב- Research, Analysis, Assistance ו-Acceleration, אך עדיין פחות מתאים לקבלת אחריות מלאה על תהליך הבדיקות.

לקראת סיום הפרק גיא מעביר מסר ברור לבודקי תוכנה:

אל תפחדו לנסות.

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

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

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

עולם הבדיקות משתנה במהירות. Agents, MCP, יכולות AI ב-Postman, כלי פיתוח מבוססי AI ופתרונות חדשים נוספים נכנסים לעבודה בקצב גבוה – והתפקיד של אנשי QA משתנה יחד איתם.

המסר של גיא חורג בסופו של דבר מעולם ה-AI וה-QA:

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

לפעמים "לא" הוא פשוט השלב הראשון בדרך ל"כן".

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

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

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

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

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

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

נקודת המפנה הגיעה לאחר לידת בנו, דניאל.

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

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

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

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

לפעמים שינוי משמעותי בחיים אינו מתחיל מתוכנית מפורטת. לפעמים הוא מתחיל בהחלטה אחת ברורה לגבי מה באמת חשוב.

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

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

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

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

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

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

התקופה הזו הייתה רחוקה מלהיות קלה.

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

המטרה הייתה ברורה: אם כבר מבצעים שינוי מקצועי משמעותי אחרי כל כך הרבה שנים – צריך לעשות אותו ברצינות.

אחד הסיפורים המשמעותיים בפרק מגיע דווקא מתקופת הלימודים.

במקביל ללימודי המתודולוגיה וההכנה ל-ISTQB, ניצן למד SQL – ובתחילת הדרך פשוט לא הצליח להבין כיצד לכתוב את השאילתות.

במקום להחליט שזה "לא בשבילו", הוא הקדיש שבת שלמה ללימוד.

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

בשיעור הבא המרצה נתן תרגיל נוסף. הפעם ניצן היה הראשון שהרים את היד – ופתר אותו.

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

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

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

ואז הגיעה משרה שהייתה כמעט אירונית.

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

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

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

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

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

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

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

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

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

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

העבודה הראשונה בתחום לא הייתה נוחה.

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

גם השכר לא היה הסיבה לעשות את המהלך.

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

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

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

כבר בתחילת הדרך הוא התחבר מאוד למקצוע.

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

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

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

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

למרות זאת, הוא אינו מאמין שה-AI יבטל את מקצוע הבדיקות.

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

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

בנוסף, קיימים תחומים שבהם האלמנט האנושי ממשיך להיות משמעותי במיוחד – למשל חוויית משתמש, שימושיות, נגישות והיבטים שונים של בדיקות מובייל.

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

כך גם עם AI.

המקצוע משתנה, וחלק מהתפקידים משתנים יחד איתו. במקביל נוצרים תפקידים וכיוונים חדשים כמו AI-Driven Test Engineer – אנשי בדיקות שיודעים לעבוד יחד עם AI, לנהל Agents ולהשתמש בהם כחלק מתהליך הבדיקות.

אחת התובנות המרכזיות בשיחה היא שה-AI אינו "עובד עצמאי" שמחליף את איש הבדיקות.

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

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

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

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

ניצן שאל שאלה פשוטה: למה לא מארגנים מפגשים כאלה?

התשובה הייתה פשוטה לא פחות: כי אף אחד עדיין לא הרים את הכפפה.

אז ניצן החליט להרים אותה.

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

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

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

הפרק הזה הוא הרבה יותר מסיפור קריירה בתחום ה-QA.

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

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

ובעיקר, זהו סיפור על אהבה למקצוע.

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

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

לפעמים צריך פשוט להתחיל ללכת.

האזנה נעימה 🎧

קישור לפרופיל לינקדאין של ניצן: https://www.linkedin.com/in/ngqa/

מייל: [email protected] 

מס נייד: 052-6718757

קישור לקבוצת העדכונים של ITCB בוואצאפ: https://bit.ly/TestIL_Whatsapp

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

ההתפתחות של חברת רדואר לאורך השנים

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

 כניסה לעולמות אבטחת הסייבר והגנה על רשתות

 הגנה עמוקה על יישומים (אפליקציות)

אספקת שירותי ענן ותשתיות מרכזי נתונים

 הגנה על עולם ממשקי התכנות  והלוגיקה העסקית

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

בשיחה הועלו תרחישים עתידיים לגבי השפעת הבינה המלאכותית

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

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

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

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

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

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

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

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

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

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

זיהוי הפער בין כוונה לביצוע: המערכת מזהה מתי ה"כוונה" של המודל עברה מניפולציה בזמן אמת ועוצרת את ההתקפה באופן מיידי בזמן ריצה

רמת דיוק גבוהה: בעוד הממוצע בתעשייה לזיהוי התקפות עומד על כ-80%-90%, הפתרונות של רדואר מגיעים לרמות דיוק של 96%-98% הודות לשימוש בבינה מלאכותית לצורך חסימת איומי בינה מלאכותית

עולם הבדיקות ואימות המערכות עובר שינוי משמעותי

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

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

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

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

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

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

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

איך מתחילים קריירה ב-QA גם ללא רקע טכנולוגי.

היתרון שבהתמחות בתחום נישתי בזמן הנכון.

המעבר מבדיקות תוכנה לניהול מוצר.

בניית תהליכי איכות ואוטומציה בארגונים גלובליים.

עבודה בגרמניה ובקנדה והבדלי התרבות המקצועית.

המעבר לפרילנס ולייעוץ בתחום ניהול המוצר.

למה AI הוא התחום הבא שכל איש מוצר ואיש QA חייב להכיר.

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

קישור לפרופיל לינקדאין של זוהר: https://www.linkedin.com/in/zoharf/

לפרופיל לינקדאין של נתנאל: https://www.linkedin.com/in/netanel-harush/

לפרופיל לינקדאין של ניצן: https://www.linkedin.com/in/ngqa/

לקבוצת העדכונים: https://bit.ly/TestIL_Whatsapp

אל תשכחו להרשם לתחרות האוטומציה של ישראל: https://www.itac.co.il/

קישור לצפיית וידאו של הפרק

https://www.youtube.com/embed/KvaCSCg_iGQ?si=-zt6f993QHFv8CVI

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

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

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

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

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

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

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

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

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

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

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

הוא מדגיש את ההבדל בין:

• QC (Quality Control) – בדיקת איכות המוצר עצמו.
• QA (Quality Assurance) – איכות התהליכים שמובילים ליצירת המוצר.

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

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

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

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

ב-SAP אלכס עובד במודל שבו אנשי ה-QA הם חלק בלתי נפרד מצוותי הפיתוח.

המשמעות היא:

• השתתפות בכל ישיבות הפיתוח.
• עבודה יומיומית עם המפתחים.
• מעורבות כבר משלב הדרישות.
• Review על Test Plans.
• ליווי הפיתוח עד העלייה לפרודקשן.

בפועל, כל מפתח אחראי על ה-Feature שלו מקצה לקצה — מהפיתוח ועד הפריסה, כאשר איש ה-QA מלווה את התהליך ומוודא שהאיכות נשמרת לאורך כל הדרך.

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

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

• User Stories
• BDD
• Given / When / Then
• Test Cases קצרים
• Review מתמשך

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

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

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

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

איש QA מביא איתו יכולות ייחודיות כמו:

• חשיבה מערכתית.
• ראייה מנקודת מבט הלקוח.
• Exploratory Testing.
• רגישות ל-UI ו-UX.
• ניסיון בזיהוי סיכונים.
• חיבור בין כלל חלקי המערכת.

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

אחד המסרים המרכזיים בפרק הוא המודל של Whole Team Quality.

בגישה זו:

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

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

לדברי אלכס, אחת הפרקטיקות החשובות ביותר היא הכנת Test Plan כבר בתחילת הפיתוח.

כאשר הבדיקות מוגדרות מראש:

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

גישה זו משתלבת היטב עם עקרונות Shift Left ו-Test-Driven Thinking.

לסיום, אלכס מסביר שאין תבנית אחת נכונה ל-Test Plan, אך הוא צריך לשלב הסתכלות ממספר עולמות:

• Functional Testing
• Risk Based Testing
• Security Testing
• Accessibility Testing
• Compatibility Testing
• Performance במידת הצורך
• לדבריו, מוצר איכותי אינו רק כזה שעובד פונקציונלית, אלא גם כזה שמאובטח, נגיש, עקבי ומתאים למגוון משתמשים וסביבות עבודה.

קישור לאתר עמותת קורנליה דה לנג ישראל: https://cdls.org.il/

קישור לפרופיל לינקדאין של אלכס: https://www.linkedin.com/in/alex-s-77a3a68/

קישור לפרופיל לינקדאין של ניצן: https://www.linkedin.com/in/ngqa/

קישור לקבוצת העדכונים של TESTIL: https://bit.ly/TestIL_Whatsapp