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