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

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

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

וזה בדיוק המקום שבו ניהול בדיקות הופך למורכב.

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

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

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

המנהל.

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

---

1. יכולת להקשיב באמת – ולא רק לחכות לתור שלך לדבר

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

זה רק חצי מהסיפור.

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

בצוות QA המידע החשוב ביותר לא תמיד מגיע בדוח הסטטוס.

לפעמים הוא מגיע במשפט קטן של בודק:

"משהו פה לא מרגיש לי נכון."

או:

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

או אפילו:

"יש לי רעיון איך לקצר את התהליך."

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

וזו כבר בעיה ניהולית.

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

למה זה קשור לחדשנות?

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

מישהו מזהה משהו שלא עובד.

מישהו מציע דרך אחרת.

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

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

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

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

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

---

2. יצירת אמון – במיוחד כשיש חדשות רעות

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

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

וזה מסוכן.

כי ב־QA החדשות החשובות הן לא תמיד החדשות הטובות.

יש באג קריטי.

הגרסה לא מוכנה.

הבדיקות מתעכבות.

הסביבה לא יציבה.

האוטומציה לא באמת חוסכת זמן.

הדרישה לא ברורה.

מישהו בצוות לא מצליח להתמודד עם המשימה.

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

בפעם הבאה, אל תספרו לי.

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

זו בעיניי אחת התכונות החשובות ביותר של מנהל QA.

לא מנהל שאומר:

"מי עשה את הטעות הזאת?"

אלא מנהל ששואל:

"מה קרה, ומה אנחנו יכולים ללמוד מזה?"

ההבדל עצום.

המטרה היא כמובן לא לוותר על אחריות. להפך.

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

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

ואיך זה משרת חדשנות?

חדשנות דורשת ניסוי.

וניסוי יכול להיכשל.

אם כל כישלון הופך לחיפוש אשמים, אף אחד לא ינסה משהו חדש.

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

---

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

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

אוטומציה.

בדיקות API.

CI/CD.

בדיקות מבוססות סיכונים.

AI.

בדיקות אבטחה.

בדיקות ביצועים.

כלים חדשים.

שיטות פיתוח חדשות.

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

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

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

אפשר להגיע למצב שבו מנהל אומר:

"אנחנו עובדים ככה כבר עשר שנים."

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

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

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

הוא כן צריך להיות האדם ששואל:

"מה חדש?"

ואפילו יותר חשוב:

"מה השתנה בעולם שאנחנו עדיין לא הכנסנו לצוות שלנו?"

---

4. יכולת לפתח אנשים – לא רק לנהל משימות

אפשר לנהל צוות גם בלי לפתח אותו.

מחלקים משימות.

עוקבים אחרי ביצוע.

בודקים עומסים.

פותרים בעיות.

מדווחים להנהלה.

והעבודה מתקדמת.

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

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

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

"מה האדם הזה יכול לדעת בעוד שנה שהוא עדיין לא יודע היום?"

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

וזה לא חייב להיות משהו גדול.

אחד ילמד API Testing.

אחר ייכנס לאוטומציה.

שלישי ילמד כלי חדש.

רביעי יקבל אחריות על תהליך.

וחמישי יתחיל להוביל שיפור קטן.

כך בונים צוות חזק.

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

ויש כאן עוד נקודה חשובה

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

להפך.

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

זו הצלחה ניהולית.

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

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

---

5. אומץ לשנות – גם כאשר התהליך הנוכחי עדיין "עובד"

זו אולי התכונה הקשה ביותר.

כי שינוי עולה כסף.

שינוי דורש זמן.

שינוי מייצר התנגדויות.

ולפעמים השינוי גם נכשל.

לכן קל מאוד להישאר במקום.

"כרגע זה עובד."

"נדבר על זה ברבעון הבא."

"אין לנו זמן."

"הצוות עמוס."

"נראה מה יהיה."

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

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

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

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

ומתודולוגיה שהתאימה לפרויקט Waterfall אולי דורשת התאמות בסביבת Agile.

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

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

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

לא אומץ לעשות מהפכות בכל חודש.

אלא אומץ לשאול מדי פעם:

"אם הייתי מקים את צוות הבדיקות הזה היום מאפס – האם הייתי בונה אותו בדיוק באותה צורה?"

אם התשובה היא לא, כדאי להבין למה.

---

חדשנות לא מתחילה בכלי חדש

יש טעות נפוצה בעולם ה־QA.

חושבים שחדשנות משמעותה להכניס כלי חדש.

אבל כלי הוא רק כלי.

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

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

אפשר להקים תהליך CI/CD ועדיין לבצע בדיקות בצורה לא יעילה.

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

היא מתחילה בתרבות.

ביכולת של העובדים לשאול שאלות.

ביכולת של המנהל להקשיב.

בנכונות להודות שמשהו לא עובד.

בהשקעה באנשים.

ובאומץ לשנות תהליכים.

ISO/IEC/IEEE 29119 מגדיר תהליכי בדיקות שנועדו לסייע לארגונים לנהל וליישם בדיקות באופן שיטתי, ואילו ה־ISTQB מדגיש את הצד האנושי והניהולי של תפקיד מנהל הבדיקות. שני הצדדים חשובים: תהליך טוב בלי אנשים טובים לא מספיק, ואנשים טובים בלי תהליך מתאים מתקשים לייצר תוצאה עקבית.

---

אז מה באמת עושה מנהל בדיקות מצוין?

אם אני מרכז את הכול לחמש תכונות פשוטות:

הקשבה – לדעת לקבל מידע ולא רק להעביר הוראות.

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

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

פיתוח אנשים – להפוך את הצוות לטוב יותר משנה לשנה.

אומץ לשנות – לא להתבלבל בין "זה עובד" לבין "זה עדיין הדבר הנכון לעשות".

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

הוא נמדד גם במה שקורה לצוות לאורך זמן.

האם האנשים שלו מתפתחים?

האם הם מעזים להציע רעיונות?

האם הם מדברים כשהם מזהים סיכון?

האם הם מסוגלים להתמודד עם טכנולוגיות חדשות?

האם הם מרגישים שהמנהל שלהם מקשיב להם?

והכי חשוב בעיניי:

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

אם התשובה היא כן, כנראה שהמנהל עושה משהו נכון.

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

זה קודם כול ניהול של האנשים שמייצרים את האיכות הזאת.

מקורות רשמיים של המאמר

• ISTQB – Managing the Test Team
• ISTQB – Expert Level Test Management Syllabus
• ISTQB – Code of Ethics
• ISO – ISO/IEC/IEEE 29119-2:2021, Test Processes
• ISO – ISO/IEC/IEEE 29119-6:2021, Agile Testing Guidelines
• ISO/IEC JTC 1/SC 7 – ISO/IEC/IEEE 29119 Series

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

קורס לבדיקות תוכנה מדויק

לעבוד מהבית כבודק תוכנה עם FIVERR >> לחץ כאן