יום רביעי, 22 בפברואר 2012

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

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

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

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

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

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

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

יום שלישי, 14 בפברואר 2012

Exit Criteria

אחד מהדברים היותר חשובים ומהיותר נזנחים הוא מסמך ה-exit criteria (כאן הכוונה היא למסמך של גרסה, ולאלמשל מסמך תנאי יציאה של המוצר מהפיתוח). מה זה בעצם אומר? אילו תנאים צריכים להתמלא בכדי שאוכל לשחרר את הגרסה הזו ללקוח. ו-כן, נכון: זה לא משהו שעושים בתום הבדיקות אלא יחד עם תכנית הבדיקות.
מדוע זה חשוב?
1. כיוון שבסוף הגרסה לפעמים אנו מוטים ונראה לנו שכבר אפשר לשחרר אותה, והגרסה הבאה כבר בפתח... ואז אנו יכולים לטעות.
2. אם יש לנו מטרה ברורה יותר קל לנו (בדיקות, פיתוח, מנהלי פרוייקטים וכו') להתמקד.
3. מסמך שחשוב להראות ללקוח או לנציגיו.
4. אם יש בעיה חוזרת זה המקום להכניס אותה, למשל כיסוי מלא של סט הבדיקות. כאמור, מה שנמדד זה מה שמטופל.
בסופו של יום זה גם עוד כלי לעלות את רמת הבדיקות.
נובע מהאמור שזהו מסמך שיש לתחזק לאורך כל חיי הגרסה. לא מגיעים לסוף הגרסה בכדי לגלות שמספר הבאגים החמורים אינו תואם את ה-exit criteria.

מה מכיל מסמך זה? כמובן שזה תלוי בארגון. מה שהייתי מכניס מחולק לכמה סעיפים:
ביצועים:
1. המוצר עומד בעומס של X פניות במשך Y ימים עם תגובה ממוצעת של Z שניות לפנייה.
2. כמה downtime היה.
3. הזמן הדרוש ל-Quick Recovery
איכות כללית:
1. אין באגים פתוחים בדרגת חומרה של major ומעלה.
2. כיסוי הבדיקות היה מלא.
3. 95% מסך הבדיקות עברו בהצלחה.
4. במידה והיו שינויים מרחיקי לכת בתשתית, האם התבצאו מספיק בדירות בעקבות תיקון זה?
מסמכים:
1. כל המסמכים אושרו (אני כמובן רושם סקיצה כללית בהיי לבל, בפועל יש למלא את המסמכים הרלוונטים)
2. כל המסמכים נמצאים במקום מוסכם.

רשומות פופולריות