כמעט כל מפתח תוכנה מודרני משתלב בשלב כזה או אחר בחייו המקצועיים בתהליך בדיקות איכות (QA) של התוכנה שהוא כתב. לפי החיוכים והתנודות בראש אני מניח שאתם בטח יודעים על מה אני מדבר (בעיקר המנהלים בתחום). לרגישים שביניכם, אני מניח שזה מוריד שנה מהחיים בכל פעם.
תהליך פיתוח תוכנה מתחיל בהגדרת דרישות על ידי הלקוח, כתיבת מסמכי אפיון, קידוד ופיתוח התוכנה. עד כאן, כיף וחיוכים, ברוב המקרים מדובר בעבודה יצירתית של התוכניתן ומנתח המערכות, מפגש פורה ומהנה עם הלקוח, רגעים קטנים של אושר בעולם התובעני של פיתוח תוכנה. הכל טוב ויפה עד לנקודה בה משתלב צוות ה – QA.
מאיזו שהיא סיבה (אחת או יותר) מעטים הם אנשי הפיתוח שמחייכים כאשר אומרים להם לייצור קשר עם ראש צוות הבדיקות כדי לתאם בדיקות QA. גם מנהלי הפרוייקטים וראשי הצוותים לא ששים לקחת חלק בתענוג המפוקפק, לעיתים נראה כי חלקם יעדיפו טיפול שיניים בלי הרדמה לפני שישקעו בסבך הביקורוקרטי של בדיקות האיכות או הסתבכות אומללה עם חוסר רגישות מקצועית ,עסקית וניהולית שפרוייקטים רבים מעוכבים בו בשלב הבדיקות.
התקלה הראשונה או ההיתקלות הראשונה (תלוי איך מסתכלים על זה) מתרחשת כבר \"בישיבת הההתנעה\" של הפרוייקט, אותה פגישה ראשונה רבת משתתפים שבה בעצם מספרים לכל מי שנוגע לעניין את מהות הפרוייקט או הפיתוח, מגבשים את צוות העבודה ,מגדירים את לוח הזמנים וקובעים את מסגרת התקציב. מאיזו שהיא סיבה עלומה ,לא מעטות הן הפעמים שבהן שוכחים ולא מזמנים לפגישת ההתנעה את איש בדיקות ה – QA של החברה.
אולי בקרוב יקום איש מדעי החברה שיבצע מחקר על התופעה אך עד אז אפשר להתייחס לזה כעובדה מוגמרת שעבודת בדיקת האיכות נתפסת עדיין כקופסא שחורה בארגון שמעטים מצליחים לעמוד על טיבה, מבינים את מהותה וערכה או בכלל מסכימים על חיוניותה לתהליך פיתוח התוכנה.
אז עכשיו לאחר שהבנתם את העובדה הזו, דמיינו איש QA בעל רגשות נחיתות, פתיל קצר וצורך עז להוכיח את נחיצותו לארגון, עושה שמות בתוכנית הפרוייקט בלי להתחשב בלוח הזמנים, מגבלות תקציב ,מתחרים או לקוחות שמזנבים אחר מנהל הפרוייקט האומלל שנמצא תחת מכבש לחצים עצום. זה נשמע לכם כמו כיף?
צר לי, אך אם היה לי שקל אחד עבור כל פעם שמצאתי עצמי במצב הנ"ל.... בקיצור, אני מניח שהבנתם.
לדעתי, העניין מתחיל מכך שיחסית למשימות אחרות שמתבצעות בארגון , עבודת ה – QA אינה מדידה, או לפחות יש קושי למדוד אותה. קשה למדוד את הזמן הדרוש לביצוע המשימה, קשה למדוד את התוצרים ואיכותם ואף קשה להחליט מהם הכישורים הדרושים לביצוע המשימה.
אני אנסה להסביר על ידי הקבלה למשרה אחרת בארגון.
ניקח לדוגמא משימת פיתוח של מסך חדש כחלק ממערכת תוכנה קיימת. מנהל הפיתוח או ראש צוות הפיתוח, לאחר שראה את מסמך הדרישות של הלקוח, יכול בקלות יחסית להעריך את כמות ההשקעה הנדרשת לפיתוח המסך (לעיתים אפילו \"הרמת אצבע\" מול הרוח יכולה להספיק), לבחור את דרגת המקצועיות של התוכניתן (מתחיל, בינוני או בכיר) הדרוש לביצוע המשימה ואף למדוד אותו במונחים של זמן, איכות קוד (על ידי סקר קוד) ואף מספר שורות קוד אם צריך (למרות שזה מדד מפוקפק למדי).
לא כך הדבר לגבי עבודת איש ה - QA. אם תעשו סקר בין ראשי הצוותים סביבכם לא אתפלא אם רובם לא מבינים מה בדיוק עושה איש ה – QA? למה לעזאזל זה לוקח לו כל כך הרבה זמן? ובכלל איך מודדים את איש ה – QA? ואיך יודעים מתי הוא מתמהמה בעבודתו או אם הוא עושה אותה ברמה טובה?
שאלות טובות. נכון?
זה לא מפליא בכלל להתקל בשאלות כאלו או ביחס מזלזל כאשר המקצוע הזה סובל מיחסי ציבור ארגוניים גרועים או בעצם, העדר יחסי ציבור בכלל. אחר כך מתפלאים שמנהל הפרוייקט שכח להזמין את ראש צוות הפרוייקט לישיבת ההתנעה. מעבר לזה, תנסו להבין את אנשי הפיתוח ומנהלי הפרוייקטים שבמידה מסויימת כל מה שהם רואים מול עיניהם דפי בדיקות עמוסים שמכילים בעיקר ביקורת דקדקנית ובלתי מתפשרת על עבודתם. תראו לי תוכניתן בריא בנפשו שלא יפתח אנטיגוניזם כרוני כלפי מישהו שמעביר ביקורת כלפי יצירת הפאר שזה עתה יצאה אל מתחת לידיו החמות.
אני ארחיב ואגיד שחלק לא מבוטל רואה בממצאי ה – QA רשימות קטנוניות. מעטות הפעמים שבהם שמעתי איש פיתוח המשבח את איש ה – QA על באג קריטי שנמצא תוך כדי בדיקות ה – QA. גם כשהמצב הזה קורה ברוב הפעמים התגובה היא כעס כלפי איש ה- QA ולא הכרת תודה. קשה להתאפק ולא להשוות את לרופא שיניים. כמה פעמים חיבקתם את רופא השיניים שלכם אחרי שחיטט לכם עמוק במהלך טיפול שורש? אפס. כמה צפוי.
מנקודת המבט של התוכניתן, בעיקר בצוותי פיתוח קלאסיים, רואים בכך אוסף של תקלות ,הערות וביקורת קטנונית שרק מוסיפות על עבודתו ומונעות ממנו לעבור להרפתקאה התיכנותית המעניינת הבאה.
אם ננסה להעמיק ולהבין את שורש הבעייה, לדעתי מקור הבעיה אינו מקצועי או טכנולוגי אלא תלוי בגורם אנושי. מדובר בבני אדם ופה מתחילה ונגמרת הבעייה.
בחברה בה צצות התופעות המתוארות לעיל נדרש טיפול בכמה רמות שונות.
ראשית, עבודה עם אנשי בדיקות האיכות לשילובם בצורה מיטבית בתהליך פיתוח התוכנה ובעיקר חיבורם לתהליכים עסקיים שקורים בחברה. לא ייתכן שיישב איש QA וייבצע בדיקות מקיפות למוצר בלי שאף אחד ייתן את הדעת בשעה שפרוייקט שלם מעוכב ללקוח. אחד הטענות המרכזיות בעולם התוכנה היא שאנשי המקצוע אינם מחוברים לשטח וללקוחות וצפים להם בעולם דמיוני של שורות קוד ורשימות באגים בלי שיבינו שמאחורה עומדים המשתמשים ולוחצים. ובכן, אפשר להגיד שאנשי הפיתוח כבר עברו את התהליך ועכשיו תורם של אנשי הבדיקות להתחבר לעסק ולתהליכים העסקיים או שיישארו מאחור כנטע זר ומבודד בחברה.
חיבור לעסק, לתהליך העסקי ויחסי ציבור פנים ארגוניים יכולים להוציא את אנשי בדיקות ה – QA מהקובייה הבעייתית, לחבר אותם לתהליך העסקי ולהפחית את מידת האנטיגוניזם שנוצרה מצד גורמים אחרים בחברה. יש לזנוח סימפטומים של אגו וחשיבות עצמית ולבצע פעולת שיווק פנים ארגונית בכדי להעביר לארגון את מידת התרומה שיש לבדיקות האיכות בתהליך. צר לי אך מי שחושב שהעניין ברור מאליו. טועה.בהרבה ארגונים עדיין לא תופסים את צוות בדיקות האיכות כיחידה יצרנית. ההפך הוא הנכון.
תוכניתן לא ברור מה הוא מקבל מאיש בדיקות ה – QA. חייבים להבין שלעיתים בדיקות האיכות ותוצאותיהן נראות כנטל וקל בשעת דוחק להמעיט בחשיבותן בהינף יד. חובת ההוכחה חלה על איש בדיקות האיכות. להסביר את עבודתו. את חשיבותה. את יעילותה. פעילות הסברה. וכמו שזה נראה היום הדרך עוד ארוכה.
המצב המתואר חריף בעיני עד שאנחנו עדים למצבים מגוחכים לגמרי שבהם תוכניתן לא מבין מדוע הוא מתעסק בבאגים שקשורים לגודל הפונט במסך התוכנה שעה לפני סגירת התוכנה והתקנתה אצל הלקוח. בנקודה הזו יש לדעתי, כשל של איש הבדיקות ושל המנהל האחראי על התהליך. כן. ידידי... תוכניתן שיושב מול איש QA לא תמיד מבין מה הוא מרוויח משיתוף פעולה. גם אם המנהל או הלקוח רואים את הערך המוסף של מוצר שבוצעה עבורו בדיקת איכות, עבור התוכניתן זה לא תמיד ברור מאליו. ומי שלא בטוח בכך שיבקש להיות \"זבוב על הקיר\" בשיחות בין שני תוכניתנים בעמדת הקפה.
כדי להפחית את רמת ההתנגדות צריך למסד שפה משותפת ותהליך מובנה בין צוות בדיקות האיכות לגורמים האחרים. שפה משותפת ברורה ובהירה, טכנוקרטית ונטולת נסיונות להוכחה עצמית בעיקר להגביר את הפיקוח הניהולי על התהליך.
השפה המשותפת והתהליך צריכים לבוא לידי ביטוי בראש ובראשונה על ידי הגדרת הנקודות בתהליך פיתוח התוכנה בהן צוות הבדיקות נכנס לתמונה והכלים שדרכם מתקשר צוות הבדיקות בכדי להציג את פירות עבודתו. ניהול מערך בדיקות עם מערכת תומכת טובה הוא הכרחי אך אינה תחליף לפיקוח ניהולי ומגע אנושי בכדי לצמצם את הסיכויים לדחיית תוצאות הבדיקה על ידי הארגון.
הקובייה המשמעותית ביותר לדעתי בתהליך היא הניהול של בדיקות האיכות. וכאן באיזור קריטי זה פרוייקטים רבים נתקלים בקשיים, בדרך כלל מכיוון שבוחרים בהתנהלות ולא בניהול.
מנהל הפרוייקט שלעיתים אינו איש מקצוע לא בא בתווך בין התוכניתן לבין איש הבדיקות ולא מבצע ביקורת על תוצאות הבדיקה ואיכותה. נשאלה השאלה, מי בודק את איש הבדיקות? והאם בכלל צריך לבדוק אותו?
ולדעתי, התשובה היא כן. חד משמעית.יש לבצע ביקורת על תוצרי מחלקת הבדיקות בדיוק כמו על כל תוצר אחר.
כחלק מתהליך הבדיקות יש לעבור על מסמכי הבדיקות, רשימות הבאגים (אחד אחד) לבחון את המשמעות, להבין את איכות הקוד שנכתב ואת איכות הבדיקה שבוצעה ולקבל החלטה. אחת הטעויות הנפוצות לדעתי היא שאת ההחלטה לגבי איכות הגירסא מקבל איש הבדיקות ולא המנהל.
הדרך הנכונה ,לדעתי, היא אחרת, איש הבדיקות צריך להתנהג בראש ובראשונה כסמכות מקצועית. לספק חוות דעת נהירה והמלצות קונקרטיות אך להשאיר את ההחלטה בידי מנהל ה תהליך לאור העובדה שההחלטה הסופית כוללת בתוכה הרבה יותר מאחר עניינים טכנולוגיים פרופר.
בתור מנהל פיתוח או מנהל פרוייקט אני מצפה לקבל רשימות (אנשי הבדיקות בדרך כלל טובים בזה) מתגלגלות של ממצאים (באגים,הערות וכו...) ממויינים לפי מידת קריטיות, סוג תקלה (עומסים, פונקציונלית, עיצוב...) בצירוף חוות דעת מקצועית נטולת אגו בנוגע לאיכות המוצר. מנסיון, מנהל פיתוח טוב יודע מה לעשות עם הממצאים, את מה חייבים לתקן ומה יכול לחכות.
אין זה אומר בשום מקרה שממצאי הבדיקות נדחים או מקבלים חשיבות משנית. יש לזכור שאסור להגרר לצד השני לעשות את החיים קלים \"לתוכניתן\". הנסיון גם מלמד שבאג שהוזנח \"יחכה לך בסיבוב\" על שרת הייצור של הלקוח.
אם הייתי צריך להגדיר את הבעייה או הגורם לאתגרים ומתיחות שבין איש הבדיקות לתוכניתן או לתהליך הפיתוח. הייתי מכוון את הזרקור אל \"תסמונת האגו הישראלית\" שטרם הוכחה מחקרית מידת הנזק שהיא מסבה בעת הפגיעה אך אני לא מכיר איש מקצוע שלא נפגע מרסיסיה במהלך פרוייקט אחד או יותר. ובדיוק כאן צריכה להכנס לפעולה מיומנותו של מנהל פיתוח שיהיה רגיש לעוצמות אגו מתפרצות של שני הצדדים (פיתוח ובדיקות) ולייצור מומנטום של שיתוף פעולה ועזרה הדדית על פני רשימות באגים שמשמשות כלי ניגוח בין מחלקות יריבות.
ובכלל.... עצה לישראלים... שימו את ענייני האגו בצד. אגו מפריע לעסקים... ככל שיקדימו להבין זאת אנשי הצוות כך יותר טוב. וכאן לצערי, הנסיון רב מדי והדרך עוד ארוכה. אגב ,יש שיטות טובות ומוכחות לאיחוד כוחות בין צוות הפיתוח לצוות הבדיקות, ובכלל כגיבוש למי שלוקח חלק בתהליך הפיתוח. נדבר על זה פעם....
בינתיים, בדיקות נעימות...
איציק
:-)
חברת smartApps software solutions הינה חברה המתמחה בתחום פיתוח מערכות תוכנה ואינטרנט ומעניקה את שירותיה לחברות לקוחות מובילות במשק הישראלי. צוות המומחים שלנו הינו בעל ידע מקצועי נרחב בפיתוח מערכות תוכנה מורכבות ובטכנולוגיות ניהול מידע ותוכן, אנו נשמח להעמיד לרשותך את הניסיון הרב שצברנו לרבות פתרון תקלות ותחזוקה שוטפת.
בקרו אותנו באתר www.smart-apps.co.il או בדף ה - facebook שלנו.
תהליך פיתוח תוכנה מתחיל בהגדרת דרישות על ידי הלקוח, כתיבת מסמכי אפיון, קידוד ופיתוח התוכנה. עד כאן, כיף וחיוכים, ברוב המקרים מדובר בעבודה יצירתית של התוכניתן ומנתח המערכות, מפגש פורה ומהנה עם הלקוח, רגעים קטנים של אושר בעולם התובעני של פיתוח תוכנה. הכל טוב ויפה עד לנקודה בה משתלב צוות ה – QA.
מאיזו שהיא סיבה (אחת או יותר) מעטים הם אנשי הפיתוח שמחייכים כאשר אומרים להם לייצור קשר עם ראש צוות הבדיקות כדי לתאם בדיקות QA. גם מנהלי הפרוייקטים וראשי הצוותים לא ששים לקחת חלק בתענוג המפוקפק, לעיתים נראה כי חלקם יעדיפו טיפול שיניים בלי הרדמה לפני שישקעו בסבך הביקורוקרטי של בדיקות האיכות או הסתבכות אומללה עם חוסר רגישות מקצועית ,עסקית וניהולית שפרוייקטים רבים מעוכבים בו בשלב הבדיקות.
התקלה הראשונה או ההיתקלות הראשונה (תלוי איך מסתכלים על זה) מתרחשת כבר \"בישיבת הההתנעה\" של הפרוייקט, אותה פגישה ראשונה רבת משתתפים שבה בעצם מספרים לכל מי שנוגע לעניין את מהות הפרוייקט או הפיתוח, מגבשים את צוות העבודה ,מגדירים את לוח הזמנים וקובעים את מסגרת התקציב. מאיזו שהיא סיבה עלומה ,לא מעטות הן הפעמים שבהן שוכחים ולא מזמנים לפגישת ההתנעה את איש בדיקות ה – QA של החברה.
אולי בקרוב יקום איש מדעי החברה שיבצע מחקר על התופעה אך עד אז אפשר להתייחס לזה כעובדה מוגמרת שעבודת בדיקת האיכות נתפסת עדיין כקופסא שחורה בארגון שמעטים מצליחים לעמוד על טיבה, מבינים את מהותה וערכה או בכלל מסכימים על חיוניותה לתהליך פיתוח התוכנה.
אז עכשיו לאחר שהבנתם את העובדה הזו, דמיינו איש QA בעל רגשות נחיתות, פתיל קצר וצורך עז להוכיח את נחיצותו לארגון, עושה שמות בתוכנית הפרוייקט בלי להתחשב בלוח הזמנים, מגבלות תקציב ,מתחרים או לקוחות שמזנבים אחר מנהל הפרוייקט האומלל שנמצא תחת מכבש לחצים עצום. זה נשמע לכם כמו כיף?
צר לי, אך אם היה לי שקל אחד עבור כל פעם שמצאתי עצמי במצב הנ"ל.... בקיצור, אני מניח שהבנתם.
לדעתי, העניין מתחיל מכך שיחסית למשימות אחרות שמתבצעות בארגון , עבודת ה – QA אינה מדידה, או לפחות יש קושי למדוד אותה. קשה למדוד את הזמן הדרוש לביצוע המשימה, קשה למדוד את התוצרים ואיכותם ואף קשה להחליט מהם הכישורים הדרושים לביצוע המשימה.
אני אנסה להסביר על ידי הקבלה למשרה אחרת בארגון.
ניקח לדוגמא משימת פיתוח של מסך חדש כחלק ממערכת תוכנה קיימת. מנהל הפיתוח או ראש צוות הפיתוח, לאחר שראה את מסמך הדרישות של הלקוח, יכול בקלות יחסית להעריך את כמות ההשקעה הנדרשת לפיתוח המסך (לעיתים אפילו \"הרמת אצבע\" מול הרוח יכולה להספיק), לבחור את דרגת המקצועיות של התוכניתן (מתחיל, בינוני או בכיר) הדרוש לביצוע המשימה ואף למדוד אותו במונחים של זמן, איכות קוד (על ידי סקר קוד) ואף מספר שורות קוד אם צריך (למרות שזה מדד מפוקפק למדי).
לא כך הדבר לגבי עבודת איש ה - QA. אם תעשו סקר בין ראשי הצוותים סביבכם לא אתפלא אם רובם לא מבינים מה בדיוק עושה איש ה – QA? למה לעזאזל זה לוקח לו כל כך הרבה זמן? ובכלל איך מודדים את איש ה – QA? ואיך יודעים מתי הוא מתמהמה בעבודתו או אם הוא עושה אותה ברמה טובה?
שאלות טובות. נכון?
זה לא מפליא בכלל להתקל בשאלות כאלו או ביחס מזלזל כאשר המקצוע הזה סובל מיחסי ציבור ארגוניים גרועים או בעצם, העדר יחסי ציבור בכלל. אחר כך מתפלאים שמנהל הפרוייקט שכח להזמין את ראש צוות הפרוייקט לישיבת ההתנעה. מעבר לזה, תנסו להבין את אנשי הפיתוח ומנהלי הפרוייקטים שבמידה מסויימת כל מה שהם רואים מול עיניהם דפי בדיקות עמוסים שמכילים בעיקר ביקורת דקדקנית ובלתי מתפשרת על עבודתם. תראו לי תוכניתן בריא בנפשו שלא יפתח אנטיגוניזם כרוני כלפי מישהו שמעביר ביקורת כלפי יצירת הפאר שזה עתה יצאה אל מתחת לידיו החמות.
אני ארחיב ואגיד שחלק לא מבוטל רואה בממצאי ה – QA רשימות קטנוניות. מעטות הפעמים שבהם שמעתי איש פיתוח המשבח את איש ה – QA על באג קריטי שנמצא תוך כדי בדיקות ה – QA. גם כשהמצב הזה קורה ברוב הפעמים התגובה היא כעס כלפי איש ה- QA ולא הכרת תודה. קשה להתאפק ולא להשוות את לרופא שיניים. כמה פעמים חיבקתם את רופא השיניים שלכם אחרי שחיטט לכם עמוק במהלך טיפול שורש? אפס. כמה צפוי.
מנקודת המבט של התוכניתן, בעיקר בצוותי פיתוח קלאסיים, רואים בכך אוסף של תקלות ,הערות וביקורת קטנונית שרק מוסיפות על עבודתו ומונעות ממנו לעבור להרפתקאה התיכנותית המעניינת הבאה.
אם ננסה להעמיק ולהבין את שורש הבעייה, לדעתי מקור הבעיה אינו מקצועי או טכנולוגי אלא תלוי בגורם אנושי. מדובר בבני אדם ופה מתחילה ונגמרת הבעייה.
בחברה בה צצות התופעות המתוארות לעיל נדרש טיפול בכמה רמות שונות.
ראשית, עבודה עם אנשי בדיקות האיכות לשילובם בצורה מיטבית בתהליך פיתוח התוכנה ובעיקר חיבורם לתהליכים עסקיים שקורים בחברה. לא ייתכן שיישב איש QA וייבצע בדיקות מקיפות למוצר בלי שאף אחד ייתן את הדעת בשעה שפרוייקט שלם מעוכב ללקוח. אחד הטענות המרכזיות בעולם התוכנה היא שאנשי המקצוע אינם מחוברים לשטח וללקוחות וצפים להם בעולם דמיוני של שורות קוד ורשימות באגים בלי שיבינו שמאחורה עומדים המשתמשים ולוחצים. ובכן, אפשר להגיד שאנשי הפיתוח כבר עברו את התהליך ועכשיו תורם של אנשי הבדיקות להתחבר לעסק ולתהליכים העסקיים או שיישארו מאחור כנטע זר ומבודד בחברה.
חיבור לעסק, לתהליך העסקי ויחסי ציבור פנים ארגוניים יכולים להוציא את אנשי בדיקות ה – QA מהקובייה הבעייתית, לחבר אותם לתהליך העסקי ולהפחית את מידת האנטיגוניזם שנוצרה מצד גורמים אחרים בחברה. יש לזנוח סימפטומים של אגו וחשיבות עצמית ולבצע פעולת שיווק פנים ארגונית בכדי להעביר לארגון את מידת התרומה שיש לבדיקות האיכות בתהליך. צר לי אך מי שחושב שהעניין ברור מאליו. טועה.בהרבה ארגונים עדיין לא תופסים את צוות בדיקות האיכות כיחידה יצרנית. ההפך הוא הנכון.
תוכניתן לא ברור מה הוא מקבל מאיש בדיקות ה – QA. חייבים להבין שלעיתים בדיקות האיכות ותוצאותיהן נראות כנטל וקל בשעת דוחק להמעיט בחשיבותן בהינף יד. חובת ההוכחה חלה על איש בדיקות האיכות. להסביר את עבודתו. את חשיבותה. את יעילותה. פעילות הסברה. וכמו שזה נראה היום הדרך עוד ארוכה.
המצב המתואר חריף בעיני עד שאנחנו עדים למצבים מגוחכים לגמרי שבהם תוכניתן לא מבין מדוע הוא מתעסק בבאגים שקשורים לגודל הפונט במסך התוכנה שעה לפני סגירת התוכנה והתקנתה אצל הלקוח. בנקודה הזו יש לדעתי, כשל של איש הבדיקות ושל המנהל האחראי על התהליך. כן. ידידי... תוכניתן שיושב מול איש QA לא תמיד מבין מה הוא מרוויח משיתוף פעולה. גם אם המנהל או הלקוח רואים את הערך המוסף של מוצר שבוצעה עבורו בדיקת איכות, עבור התוכניתן זה לא תמיד ברור מאליו. ומי שלא בטוח בכך שיבקש להיות \"זבוב על הקיר\" בשיחות בין שני תוכניתנים בעמדת הקפה.
כדי להפחית את רמת ההתנגדות צריך למסד שפה משותפת ותהליך מובנה בין צוות בדיקות האיכות לגורמים האחרים. שפה משותפת ברורה ובהירה, טכנוקרטית ונטולת נסיונות להוכחה עצמית בעיקר להגביר את הפיקוח הניהולי על התהליך.
השפה המשותפת והתהליך צריכים לבוא לידי ביטוי בראש ובראשונה על ידי הגדרת הנקודות בתהליך פיתוח התוכנה בהן צוות הבדיקות נכנס לתמונה והכלים שדרכם מתקשר צוות הבדיקות בכדי להציג את פירות עבודתו. ניהול מערך בדיקות עם מערכת תומכת טובה הוא הכרחי אך אינה תחליף לפיקוח ניהולי ומגע אנושי בכדי לצמצם את הסיכויים לדחיית תוצאות הבדיקה על ידי הארגון.
הקובייה המשמעותית ביותר לדעתי בתהליך היא הניהול של בדיקות האיכות. וכאן באיזור קריטי זה פרוייקטים רבים נתקלים בקשיים, בדרך כלל מכיוון שבוחרים בהתנהלות ולא בניהול.
מנהל הפרוייקט שלעיתים אינו איש מקצוע לא בא בתווך בין התוכניתן לבין איש הבדיקות ולא מבצע ביקורת על תוצאות הבדיקה ואיכותה. נשאלה השאלה, מי בודק את איש הבדיקות? והאם בכלל צריך לבדוק אותו?
ולדעתי, התשובה היא כן. חד משמעית.יש לבצע ביקורת על תוצרי מחלקת הבדיקות בדיוק כמו על כל תוצר אחר.
כחלק מתהליך הבדיקות יש לעבור על מסמכי הבדיקות, רשימות הבאגים (אחד אחד) לבחון את המשמעות, להבין את איכות הקוד שנכתב ואת איכות הבדיקה שבוצעה ולקבל החלטה. אחת הטעויות הנפוצות לדעתי היא שאת ההחלטה לגבי איכות הגירסא מקבל איש הבדיקות ולא המנהל.
הדרך הנכונה ,לדעתי, היא אחרת, איש הבדיקות צריך להתנהג בראש ובראשונה כסמכות מקצועית. לספק חוות דעת נהירה והמלצות קונקרטיות אך להשאיר את ההחלטה בידי מנהל ה תהליך לאור העובדה שההחלטה הסופית כוללת בתוכה הרבה יותר מאחר עניינים טכנולוגיים פרופר.
בתור מנהל פיתוח או מנהל פרוייקט אני מצפה לקבל רשימות (אנשי הבדיקות בדרך כלל טובים בזה) מתגלגלות של ממצאים (באגים,הערות וכו...) ממויינים לפי מידת קריטיות, סוג תקלה (עומסים, פונקציונלית, עיצוב...) בצירוף חוות דעת מקצועית נטולת אגו בנוגע לאיכות המוצר. מנסיון, מנהל פיתוח טוב יודע מה לעשות עם הממצאים, את מה חייבים לתקן ומה יכול לחכות.
אין זה אומר בשום מקרה שממצאי הבדיקות נדחים או מקבלים חשיבות משנית. יש לזכור שאסור להגרר לצד השני לעשות את החיים קלים \"לתוכניתן\". הנסיון גם מלמד שבאג שהוזנח \"יחכה לך בסיבוב\" על שרת הייצור של הלקוח.
אם הייתי צריך להגדיר את הבעייה או הגורם לאתגרים ומתיחות שבין איש הבדיקות לתוכניתן או לתהליך הפיתוח. הייתי מכוון את הזרקור אל \"תסמונת האגו הישראלית\" שטרם הוכחה מחקרית מידת הנזק שהיא מסבה בעת הפגיעה אך אני לא מכיר איש מקצוע שלא נפגע מרסיסיה במהלך פרוייקט אחד או יותר. ובדיוק כאן צריכה להכנס לפעולה מיומנותו של מנהל פיתוח שיהיה רגיש לעוצמות אגו מתפרצות של שני הצדדים (פיתוח ובדיקות) ולייצור מומנטום של שיתוף פעולה ועזרה הדדית על פני רשימות באגים שמשמשות כלי ניגוח בין מחלקות יריבות.
ובכלל.... עצה לישראלים... שימו את ענייני האגו בצד. אגו מפריע לעסקים... ככל שיקדימו להבין זאת אנשי הצוות כך יותר טוב. וכאן לצערי, הנסיון רב מדי והדרך עוד ארוכה. אגב ,יש שיטות טובות ומוכחות לאיחוד כוחות בין צוות הפיתוח לצוות הבדיקות, ובכלל כגיבוש למי שלוקח חלק בתהליך הפיתוח. נדבר על זה פעם....
בינתיים, בדיקות נעימות...
איציק
:-)
חברת smartApps software solutions הינה חברה המתמחה בתחום פיתוח מערכות תוכנה ואינטרנט ומעניקה את שירותיה לחברות לקוחות מובילות במשק הישראלי. צוות המומחים שלנו הינו בעל ידע מקצועי נרחב בפיתוח מערכות תוכנה מורכבות ובטכנולוגיות ניהול מידע ותוכן, אנו נשמח להעמיד לרשותך את הניסיון הרב שצברנו לרבות פתרון תקלות ותחזוקה שוטפת.
בקרו אותנו באתר www.smart-apps.co.il או בדף ה - facebook שלנו.
