כיצד מובילים קבוצות בדיקות העובדות בשיטות מיושנות לעבודה שיטתית ויעילה-חלק א'

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

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

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

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

נתחיל עם שלב ניהול הדרישות שהוא הבסיס לתהליך השינוי:

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

• חפשו את המכנה המשותף של מספר פרויקטים בקבוצה שאיתה תרצו להתחיל כהוכחת יכולת (האחריות היא עליכם).

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

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

 גם אם הקוד משוכפל, הפסיקו שכפולים.

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

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

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

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

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

 מהי הדרישה לפי הבנתכם?

 באילו תרחישים, סימולטורים וסביבות תבדקו אם הדרישה מכוסה?

 כמה תסריטים וכמה זמן זה ייקח בשעות עבודה לפתח\לעדכן תסריטים ולהריץ אותם?

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

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

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


כותבת המאמר- עדנה כהנוביץ, מנתחת מערכות ומנהלת פיתוח ובדיקות בנס.

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

האני מאמין של עדנה הוא -

תהליכים, עבודה מסונכרנת וקידום מקצועי וניהולי של צוותים.

More In This Subject...

עוד פרסומים בנושא אשר עשויים לעניין אותך