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

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

תסריטי בדיקה

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

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

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

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

•    נהגו בהגינות והריצו בדיקה באופן מסודר, כתבו מראש ועדכנו בכלי תכנון הבדיקות, ולא Free run. יש מקום גם ל-Free run, אבל לא יותר מ-10%-15% מכל העניין. הכינו סטים מוגדרים למול סטים של דרישות, השקיעו בזה זמן כדי להכיר היטב את המוצר וערכו סקר להראות כיסוי וכינוס – Single source in testing.

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

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

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

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

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

ניהול תקלות

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

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

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

על הכותבת

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