אכן שם מפוצץ, מאתגר ואולי מפחיד משהו. אבל אפשר וחובה עלינו להפריט את המשמעויות של הביטוי הזה ל"אובייקטים" קטנים ונהילים בכדי שנוכל לארגן את הדרכים שבהן עלינו לפסוע, לחלק קדימויות וכד'.
יש שאלות ספציפיות שקשורות בכמה אנשים בצוות, סוג המעבדות וכד' שלא אכנס אליהן כאן. בסה"כ אני רוצה להעלות נקודות לחשיבה בכדי שהקורא המעוניין קודם כל יארגן את האסטרטגיה ואח"כ את הטקטיקה ויבוא מראש עם מענה לחלק גדול מהבעיות / הסוגיות שעלולות / עשויות לצוץ.
דברים לחשיבה לפני תחילת התפקיד ובשלב הראשוני מאוד (ימים ראשונים בתפקיד). כמובן שכמה שאפשר ללמוד טרם הכניסה לתפקיד ככה יותר טוב:דבר ראשון: בררי מה חושב הארגון על בדיקות תוכנה. לכאורה אולי נראית נקודה ברורה מאליה ("עובדה הם רוצים להקים מערך - זה אומר שזה חשוב, לא?" תשובה: לא בהכרח. אולי המשקיעים רצו, הלקוחות דרשו ו"אין ברירה אלא להענות לרעה הזו").
חשוב בעיקר שהמנהלים יבינו את החשיבות של תחום בדיקות התוכנה, אבל גם שאר אנשי הארגון. אם הם לא מבינים - אל ייאוש: תסבירי להם. אם הפתרון הזה לא נראה לך - אולי לא קורצת מהחומר המתאים למנהלים. איך להסביר זה נושא כשלעצמו, אבל השורה התחתונה היא להראות להם שבסופו של דבר מערך הבדיקות יחסוך כסף ויביא רווחים עתידיים.
אם לא יהיה לך גב מההנהלה יהיה לך קשה בכל התחומים, כולל הטמעה ותקציב. כמובן שב"גב" הכוונה היא לא לרוץ להנהלה בכל פעם שמפתח אומר משהו. פשוט כשההנהלה מחוייבת זה בד"כ (במקום "נורמלי") מחלחל למטה.דבר שני: אמצעים. אם יש כסף אז אפשר לבחור כלים אוטומאטיים למשל, ויש לזה השלכות לגבי סוג הצוות שתגייסי, כסף קשור גם לסוג המעבדה שתבני ועוד.דבר שלישי: לימוד הארגון: יכולות הפיתוח, הפרוצדורות, הכח הניהולי, תרבות ארגונית וכד'. למשל ארגון "דמוקרטי" מידי עלול להיות מקום להזדמנות אבל גם מקום שקשה לחתור למטרה.
וכמובן על צוות הבדיקות: במה הוא טוב, במה פחות, מקצועיותו ככלל ויכולתו האישית של כל בודק ובודק.
תחילת העבודה:
1. יש לערוך פגישת היכרות עם הצוות, שמטרתה (פרט להיכרות כמובן) היא להבהיר להם שאמנם דברים ישונו אבל לא בצורה פראית, שבסופו של דבר הם גם ירוויחוו מזה, שיש עם מי לדבר וכד'. הרווח שלהם: מקצועיות שתעזור גם בעתיד, הערכה (שבודאי אינה קיימת אם נכנסתם ל"ג'ונגל"), וכמובן שהצלחת הבדיקות יתרמו לחברה ואז אולי גם להם בחזרה.
בכל מקרה חשוב להכיר את הנשמות הפועלות, מי מקצועי יותר ומי לא, האם יש שם אנשים ממורמרים, אולי יש מי שרצה את התפקיד שקיבלת, מי יזרום עם השינויים ומי יעמוד בדרכם. עם הזמן, אולי תצטרכי לשנות את הרכב הצוות.
אבל חשוב להבין שלמרות שאת המנהלת וכולם צריכים לדעת את זה, בלי גיוס של העובדים את שווה לאפס.
2. שינויים. אל תשנו מהיום הראשון. תלמדו את הארגון, את התרבות האירגונית, כמה שיותר מהר אבל לא לצאת בשינויים מהותיים עד שברורה התמונה. הנזק בשינוי הפרוצדורה לאחת תחילת יישומה הוא אדיר - גם באמינות שלכם וגם בקושי של כולם להתחיל לזכור מה שונה ומתי.
לגבי הימים האלה של גיבוש הדרך (ובכלל לימוד המוצר) - פשוט תזרמו ורק תוודאו שאין טעויות גדולות, אני לא אומר שלא צריך לשפר גם אז, אבל רק בדברים שעלול להיות שם אסון כמו למשל וידוא שהבודקים מבינים את מושא הבדיקה וכד'.
לאחר שאתם בטוחים בדברים שיש לשנות, אחרי שישבתם בנושא עם מנהלים, גופים מתממשקים בארגון ועם הצוות
תוציאו מסמך תעדופים. מה שחשוב לי לומר זה שלא צריך להוציא חוברת נהלים בת 800 עמודים כי שום דבר לא יקרה - כלומר יימומש. צריך להתחיל מפרוצדורות בסיסיות מול הפיתוח, מול גופים אחרים וכן פרוצדורות פנימיות. את צריכה לראות את כל התמונה, אבל ל"שחרר" פרוצדורות שמתאים לך לשחרר.
הטוב ביותר לקחת את המסמך של הבעיות, נניח אקסל, ולמלא בו את הפרטים הבאים:
מס' הבעיה, קיצור הבעיה, המטרה (מדידה), אחריות, הדרך, תאריך התוכנית ותאריך סיום המימוש שלה.
נניח:
מס': 1. בעיה: 12% באגים מתגלים אחרי שלב הבדיקות. מטרה: 5%. אחריות: *, הדרך: א. הצלבת הדרישות והבדיקות, ב. בדיקה סופית מקיפה וכד', תוכנית מקיפה תהיה מוכנה ב1.6, תמומש ב1.7
* את האחריות לתוכנית הייתי מטיל על צוות של הבודקים + אנשים מקבוצות אחרות רלוונטיות.
אחרי שהמסמך מוכן, בוחרים 3 דברים מרכזיים וזהו. אחרי המימוש עוברים לשלשה הבאים.
