כשהתחלתי את דרכי בעולם ההיי-טק, היה זה בקורס "הסבת אקדמאים לתכניתני מערכות מידע בסביבת שרת לקוח", שם מסחרי מאוד, של ג'ון ברייס. כל משתתפי הקורס רצו להיות תכניתנים מהוללים, מלאים בכסף ובתהילה. לא דיברנו על כך בקול רם, אבל ידענו גם ידענו שלא כולנו נגיע לאולימפוס, וכמו הייפייסטוס חלקנו ניפול לשאול תחתית. אלה, אמרו המבינים בלחש, מגיעים ל-אתם יודעים איפה. אפילו את המילה "בדיקות" פחדו להגות (טוב אני נסחף, אבל לא בהרבה).
במקום העבודה הראשון שלי, כן - בבדיקות, היה לי מנהל שהיה קודם סיסטם. הוא ידע דבר אחד - שיש לעבוד עם מכונות נקיות, וזהו. לא הייתה שיטה ולא דרך.
במקום השני שלי, אחרי שכבר הייתי ר"צ, עבדתי עם מפתחים שבחיים לא עבדו עם אנשי בדיקות ולא ממש הבינו למה זה מגיע להם. הייתי צריך להתווכח איתם על כל באג.
בקומברס, לעומת זאת, המצב היה אחר - הרבה יותר טוב. החשיבות הובנה, הפיתוח התייעץ איתנו ואנחנו איתו, וקל יותר היה להגיע להישגים. אבל בלי להכליל, היה הבדל מעמדות. לא היינו "בחבר'ה" של המקובלים, כלומר של הפיתוח.
והיום, מה המצב היום?
אני לא מתיימר להכיר את המצב לאשורו בארץ, ולכן סימן השאלה בכותרת. אבל אני יכול לדבר מניסיון.
אין ספק שהיום באמת כבר מוטמע בכל מפתח שהבודק הופך את הקוד שלו עצמו ליותר טוב, וחוסך לו עגמת נפש. יודעים שיש לעדכן אותנו, להתייעץ איתנו ובעצם אנו חלק אינטגרלי של הפיתוח ולא פחות או יותר טוב, גם בטכני וגם ברמה החברתית. מצויין. אז מה בכ"ז לא טוב? להלן התשובה
אני לא פגשתי יותר משניים שלשה לא רק מנהלי פיתוח, אלא גם מנהלי בדיקות, שמעניינת אותם המתודולוגיה. ישאלו אותי בראיון מה זה XML, מה זה session cookie וכד', שאלות אגב שמראות כמה מעט מצפים מאיתנו. אבל כמעט אף אחד לא שאל אותי: איך אתה מבצע את העברת המוצר מהפיתוח לבדיקות? איך אתה מוודא את איכות המוצר? מהם הקריטריונים להצלחה של חדר הבדיקות? בקיצור, אף שאלה על מתודולוגיה. ואת זה אני לא מבין!
יכול להיות מישהו שהוא עילוי טכני, האם זה יבטיח את איכות המוצר? ברור שלא. אם הוא לא מודע בכלל לבדיקות יוזביליות, סביר שהמשתמשים לא יהיו מרוצים. הוא עלול לבזבז ימים בריצה סביב זנבו כי הוא לא עשה בדיקות שפיות למוצר לפמני קבלתו לחדר הבדיקות ועוד.
לעומת זאת, אם יש טכנולוג שלא מכיר היטב את התחום הטכני שבו עוסקת החברה, אבל שהוא בעל ידע מתודולוגי טוב בתהליכי בדיקה, האם הוא לא יועיל מהיום הראשון (ועוד יותר כאשר הוא ילמד את הטכנולוגיה)? להיפך: ללמוד טכנולוגיה זה הרבה יותר קל ממתודולוגיה, בטח שלטכנולוג. לעומת זאת מתודולוגיה זה לא רק תהליך, זו הפנמה של רוח הדברים, לדעת מה טוב גם במקרים שלא היינו בהם בעבר, ועל איזה חלק המתהליך אפשר לוותר במקרה מסויים כזה או אחר, וזה, חברים, בא רק אחרי ניסיון של שנים.
לגבי, אני יודע שבתחום שלי יש לי ידע טכני, אבל אני יודע שלמשל אם מחר אני מתראיין לניהול בדיקות של מוצר נניח של עיבוד תמונה, הסיכוי שלי נמוך משל מישהו שהוא בדיוק קופי שלי, אבל במקום מתודולוגיה יש לו ניסיון בתחום עיבוד תמונות. וזה לא ההפסד שלי בלבד. זה ההפסד של כולנו, כולל המעסיקים.
ולמה זה קורה? כי מי שהוא מפתח עילוי ב.net אז זה מה שהוא. הוא יתרום מהר מאוד לחברה. אבל בודק, לא כל שכן מנהל בדיקות, לא צריך להימדד רק לפי זה.
ולמה זה קורה? כי למנהלי בדיקות ומנהלי פיתוח אין ולא גרגיר של מושג לגבי הנושא של בדיקות תוכנה.
וחבל שכך. ושכשאין תגמול לידע, הידע לא יירכש וזה ייפגע בתחום שלנו ככלל.
במקום העבודה הראשון שלי, כן - בבדיקות, היה לי מנהל שהיה קודם סיסטם. הוא ידע דבר אחד - שיש לעבוד עם מכונות נקיות, וזהו. לא הייתה שיטה ולא דרך.
במקום השני שלי, אחרי שכבר הייתי ר"צ, עבדתי עם מפתחים שבחיים לא עבדו עם אנשי בדיקות ולא ממש הבינו למה זה מגיע להם. הייתי צריך להתווכח איתם על כל באג.
בקומברס, לעומת זאת, המצב היה אחר - הרבה יותר טוב. החשיבות הובנה, הפיתוח התייעץ איתנו ואנחנו איתו, וקל יותר היה להגיע להישגים. אבל בלי להכליל, היה הבדל מעמדות. לא היינו "בחבר'ה" של המקובלים, כלומר של הפיתוח.
והיום, מה המצב היום?
אני לא מתיימר להכיר את המצב לאשורו בארץ, ולכן סימן השאלה בכותרת. אבל אני יכול לדבר מניסיון.
אין ספק שהיום באמת כבר מוטמע בכל מפתח שהבודק הופך את הקוד שלו עצמו ליותר טוב, וחוסך לו עגמת נפש. יודעים שיש לעדכן אותנו, להתייעץ איתנו ובעצם אנו חלק אינטגרלי של הפיתוח ולא פחות או יותר טוב, גם בטכני וגם ברמה החברתית. מצויין. אז מה בכ"ז לא טוב? להלן התשובה
אני לא פגשתי יותר משניים שלשה לא רק מנהלי פיתוח, אלא גם מנהלי בדיקות, שמעניינת אותם המתודולוגיה. ישאלו אותי בראיון מה זה XML, מה זה session cookie וכד', שאלות אגב שמראות כמה מעט מצפים מאיתנו. אבל כמעט אף אחד לא שאל אותי: איך אתה מבצע את העברת המוצר מהפיתוח לבדיקות? איך אתה מוודא את איכות המוצר? מהם הקריטריונים להצלחה של חדר הבדיקות? בקיצור, אף שאלה על מתודולוגיה. ואת זה אני לא מבין!
יכול להיות מישהו שהוא עילוי טכני, האם זה יבטיח את איכות המוצר? ברור שלא. אם הוא לא מודע בכלל לבדיקות יוזביליות, סביר שהמשתמשים לא יהיו מרוצים. הוא עלול לבזבז ימים בריצה סביב זנבו כי הוא לא עשה בדיקות שפיות למוצר לפמני קבלתו לחדר הבדיקות ועוד.
לעומת זאת, אם יש טכנולוג שלא מכיר היטב את התחום הטכני שבו עוסקת החברה, אבל שהוא בעל ידע מתודולוגי טוב בתהליכי בדיקה, האם הוא לא יועיל מהיום הראשון (ועוד יותר כאשר הוא ילמד את הטכנולוגיה)? להיפך: ללמוד טכנולוגיה זה הרבה יותר קל ממתודולוגיה, בטח שלטכנולוג. לעומת זאת מתודולוגיה זה לא רק תהליך, זו הפנמה של רוח הדברים, לדעת מה טוב גם במקרים שלא היינו בהם בעבר, ועל איזה חלק המתהליך אפשר לוותר במקרה מסויים כזה או אחר, וזה, חברים, בא רק אחרי ניסיון של שנים.
לגבי, אני יודע שבתחום שלי יש לי ידע טכני, אבל אני יודע שלמשל אם מחר אני מתראיין לניהול בדיקות של מוצר נניח של עיבוד תמונה, הסיכוי שלי נמוך משל מישהו שהוא בדיוק קופי שלי, אבל במקום מתודולוגיה יש לו ניסיון בתחום עיבוד תמונות. וזה לא ההפסד שלי בלבד. זה ההפסד של כולנו, כולל המעסיקים.
ולמה זה קורה? כי מי שהוא מפתח עילוי ב.net אז זה מה שהוא. הוא יתרום מהר מאוד לחברה. אבל בודק, לא כל שכן מנהל בדיקות, לא צריך להימדד רק לפי זה.
ולמה זה קורה? כי למנהלי בדיקות ומנהלי פיתוח אין ולא גרגיר של מושג לגבי הנושא של בדיקות תוכנה.
וחבל שכך. ושכשאין תגמול לידע, הידע לא יירכש וזה ייפגע בתחום שלנו ככלל.
איני בטוח כי ניתן להגיד כי מצב מקצוע הבדיקות אכן עגום - אך בהחלט הוא לא משתפר בקצב הראוי - וראייה לכך הינה רמת המשכורות ביחס לתפקידים אחרים - עם תקרת זכוכית נמוכה וקרובה מדיי לרמת המשכורת הראשונית.
השבמחקלגבי השאלה מה חשוב יותר, ומה קשה יותר ללמוד - הצד הטכני או המטודולוגי, זה כנראה דיי קשור לתחום הטכני בו מדובר.
בתחום התקשורת לדוגמא, מצאתי שיותר קל לי לקבל תפוקה מהירה וגם לאורך זמן מבעלי רקע טכני אותם לימדתי מתודולוגיית בדיקות, מאשר מבעלי ידע בבדיקות אותם לימדתי את הפן הטכני.
מאידך - יש לנו בעיה מהותית, שלא מספיק בודקים טורחים לשפר את הידע המטודולוגי, לקרוא מאמרים, בלוגים ולהשתתף בדיונים בפורומים בארץ ובעולם.
מעטים מאוד עושים זאת ברמה שבועית וכמעט אין מה לדבר על רמה יום-יומית.
בניגוד לכך מהצד הטכני אי אפשר להתחמק, ולא יעלה על הדעת שלא נלמד הרקע לתכונה אותה אנו בודקים.
ואכן, זה מוביל לחוסר יעילות.
לצערנו המנהלים סביבנו לא מבינים במה מדובר - אך חמור מכך, הם חושבים שהם כן מבינים, ולכן לא טורחים ללמוד.
זה מוביל למצב בו בהרבה חברות יושבים בודקים שלא למדו אפילו את הדברים הבסיסיים בבדיקות, שלא לדבר על השתתפות בלפחות קורס או כנס בנושא ברמה שנתית.
קובי הלפרין halperinko@
בעיקרון אין לי מה להוסיף למה שכתבת קובי, רק לחדד נקודה: הרשומה שלי כיוונה יותר לתפקידי ניהול. לתפקיד מהנדס (או מהנדסת) בדיקות ייתכן שאעדיף מישהו בעל ידע נקודתי טכני במה שהחברה עושה מאשר בעל ניסיון במתודולוגיות, וזאת אם נראה לי שהוא ישתלב בתהליכים. אבל לתפקיד של ר"צ בוודאי גם היכולות המתודולוגיות שלו חשובות, וודאי ובוודאי כשמדובר במנהל של ראשי צוותים. הבעייה היא, כאמור, שחוץ מקומץ אנשים בתחום, אנשים לא מבינים כמה מקצוע הבדיקות הוא עמוק ומורכב.
השבמחק