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

היכרות עם אלמוג כהן

ותק: מעל 15 שנות ניסיון בעולם הבדיקות

כניסה לתחום הבדיקות

בתקופה בה התחיל, לא היו קורסים מוסדרים בתחום

גישתו להוראה ופיתוח מקצועי

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

עבודה בבנק ובחברות פיננסיות

העבודה חייבת להיות שיטתית, רגולטורית, מדידה וברורה

שילוב מתודולוגיות בדיקה

מדגיש את החשיבות של שיטה גם בעולם אג׳ייל או דבאופס

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

החל כראש צוות, התקדם לניהול אגף שלם הכולל

גישתו לפיתוח קריירה

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

המסר המרכזי

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

תחום הבדיקות הידניות לא מת – ניתן לפתח בו קריירה שלמה

תובנות עיקריות

בדיקות זה לא רק טכניקה – זו גישה ניהולית ועסקית

קישור לפרופיל לינקדאין של אלמוג

קישור לקבוצת הוואצאפ של קהילת ארגון הבודקים הישראלי

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

הגדרת “מנהל ״האנדס-און״
מנהל שמבצע חלק ניכר מהעבודה הטכנית בעצמו – כתיבת קוד, בדיקות, ניתוח תקלות – בנוסף לאחריות ניהולית
בדרך כלל מדובר בשילוב משתנה: 50% ניהול, 50% טכני (תלוי בגודל הצוות)

יתרונות הניהול ה-״האנדס און״

חיבור אמיתי לשטח ולכאבי הצוות

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

״השראה ומוטיבציה לצוות כשמנהל “מלכלך את הידיים

חדשנות גבוהה יותר בזכות עדכניות טכנולוגית

אתגרים וחסרונות

שחיקה וניהול זמן קשה – שילוב בין ישיבות, משימות, וקוד

סכנה שהאחוז הטכני ירד עם גדילת הצוות

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

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

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

קישור לפרופיל לינקדאין של שביט

🧠 Main Themes Discussed:

• The Importance of Community in QA

Igor emphasizes the role of professional communities in knowledge sharing.

He mentions the proactive involvement of the Israeli QA community, including webinars, meetups, TikTok, articles, podcasts, etc.

He presents Israeli efforts at international conferences (e.g., STQB) and notes global recognition of Israel's contributions to software testing.

• Igor's Background

Focuses on providing QA/testing frameworks for startups.

Writes articles based on real-life experience and field challenges.

Member of the international academic team of a global testing organization.

🧰 Main Topic: Exit Criteria

A set of conditions or actions that must be completed before advancing to the next phase (e.g., feature completion, release, sprint).

Examples: all planned tests are executed, critical bugs are resolved, monitoring is in place, sufficient automation coverage.

🔁 Common Confusion:

Often confused with Acceptance Criteria:

Exit Criteria: A QA/testing-focused gate to move forward.

Acceptance Criteria: Business/development-focused requirements for accepting a story or task.

🧭 The Problem:

Many teams treat exit criteria as a checklist — a "tick box" exercise — which leads to poor understanding and superficial QA.

✔️ Igor's Approach:

Exit criteria should be a living, collaborative tool.

Created with the entire team (devs, testers, managers) for clarity and shared responsibility.

It should reflect real quality control, not just formal documentation.

🧪 Agile & Quality Engineering Connections

Move from the traditional "QA owns quality" to a team-wide quality ownership model.

Shift Left approach: Developers take on unit, integration, and UI testing.

Testers become more like quality coaches/gatekeepers, focusing on strategy rather than just executing test cases.

🧱 Tools and Practices:

Exit Criteria = Acceptance Tests = Shared understanding.

Not every step is manual testing – criteria can be automated, observable, or integrated into CI/CD pipelines.

🧩 Key Takeaways:

Exit Criteria is not just technical – it's cultural.

Its real value is helping teams stop, reflect, and align.

It's about clarity, not control – knowing when a feature or release is truly ready.

Checklists are good, but only if they reflect meaningful, agreed-upon quality goals.

🧠 Final Reflections:

Exit Criteria should empower teams – not burden them.

It's not just a QA tool; it's a team alignment mechanism.

When used properly, it improves collaboration, quality ownership, and development velocity — especially in fast-paced environments like startups.

Link to Igor Linkedin profile

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

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

מהי ״הזזה שמאלה״

המונח מתאר הקדמה של תהליכי הבדיקות מהשלבים המאוחרים של מחזור הפיתוח (אחרי קוד) אל שלבי ה־העיצוב והאפיון

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

הדבר תואם את אחד מעקרונות הבדיקה – בדיקות מוקדמות 

עקרונות מרכזיים של ״הזזה שמאלה״

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

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

שילוב בדיקות בתהליך הפיתוח - כתיבת בדיקות עוד לפני הקוד (פיתוח מונחה בדיקות), שימוש עקבי ב־בדיקות יחידה ,בדיקות התממשקות  ו־בדיקות נסיגה  מוקדמים

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

יתרונות הגישה

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

שיפור איכות: פחות באגים מאוחרים → פחות רגרסיות

שיפור תקשורת בין צוותים: נדרשת מעורבות מוקדמת של פיתוח ובדיקות

גילוי בעיות סטטיות: למשל קוד מת ״קוד מת״, נזילות זיכרון או ״קוד ספגטי״ – שלא תמיד עולים בבדיקות דינמיות

זמן לשוק מהיר יותר: שחרור מוצרים מהר ובאיכות גבוהה

אתגרי היישום

לא קורה מיד – דורש חשיבה מוקדמת, הכנה ותכנון ארגוני

צורך ב־סטנדרטים איכותיים ברורים (למשל תנאי כניסה לבדיקות)

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

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

שינוי תפיסתי: בודקים אינם רק “בודקי מוצר” אלא תומכי איכות כוללת

תנאים להצלחה

תמיכת הנהלה – קריטית להטמעת שינוי ארגוני

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

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

סיכום המסר

:הזזה שמאלה מאפשרת

מוצר אמין ובטוח יותר

פחות באגים בשלבים מאוחרים

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

המסקנה: "לעבור שמאלה זו החלטה נכונה" – היא משתלמת עסקית, טכנולוגית וארגונית

  פרק 6 - כלי בדיקה 

נעשה באמצעות כלי הבינה המלאכותית של גוגל

notebook LM

פרק 5 - ניהול פעילות הבדיקות 

נעשה באמצעות כלי הבינה המלאכותית של גוגל

notebook LM

פרק 4 - ניתוח ועיצוב בדיקות 

נעשה באמצעות כלי הבינה המלאכותית של גוגל

notebook LM

פרק 3 - בדיקות סטטיות 

נעשה באמצעות כלי הבינה המלאכותית של גוגל

notebook LM

פרק 2 - בדיקות לאורך מחזור חיי פיתוח תוכנה 

נעשה באמצעות כלי הבינה המלאכותית של גוגל

notebook LM

פרק מס 1 - יסודות בדיקות התוכנה

נעשה באמצעות כלי הבינה המלאכותית של גוגל

notebook LM