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

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

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

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

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

מתחילים בשינוי

השלב הראשון בתהליך השינוי, שמהווה הבסיס לו, הוא ניהול הדרישות. הנה מספר טיפים בולטים הרלוונטיים לו:

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

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

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

•   ודאו שיש Single source בניהול הדרישות ובניהול הבדיקות – אין יותר שכפולים. אם הקוד משוכפל, ,הפסיקו אותם.

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

•    בצעו את הקישורים הנדרשים בין הדרישות על ידי הפקת דו"חות מ-Template. דו"חות המופקים מול בקרת איכות בלחיצת כפתור, מבלי עבודה ידנית, הם קלף מנצח בתהליך השכנוע.

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

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

•    אם אין סקר דרישות, תזמו פגישה לתכנון בדיקות ומול כל דרישה ציינו את פרטי המידע הבאים, בקצרה: מהי הדרישה, לפי הבנתכם? באילו תרחישים, סימולטורים וסביבות תבדקו אם הדרישה מכוסה? כמה זמן זה ייקח, בשעות עבודה, לפתח או לעדכן תסריטים ולהריץ אותם – ובכמה תסריטים מדובר?

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

•    בצעו ייצוא וייבוא בין כלי בקרת דרישות וכלי בקרת בדיקות, אם אין קישוריות, כחלק מהפיילוט, וכך תוכיחו שהתהליך עובד.

בשבוע הבא אעסוק בהמשך הובלת תהליך השינוי בקבוצות בדיקות – בחלק של תסריטי הבדיקות וניהול התקלות .

על הכותבת

עדנה כהנוביץ' היא מנתחת מערכות ומנהלת פיתוח ובדיקות בנס. לכהנוביץ' ניסיון רב בניהול צוותי בדיקות ופיתוח בחברות בינלאומיות, בעיקר במגזר הביטחוני, בתקשורת ופרויקטים אזרחיים  בתחומי ה-Security & Big Data ,Real time ,Medical. האני מאמין שלה הוא תהליכים, עבודה מסונכרנת וקידום מקצועי וניהולי של צוותים.