בדיקות והבטחת איכותMenu

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

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

תסריטי בדיקה

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

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

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

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

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

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

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

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

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

לדוגמה- יש לנו מאות בדיקות ורק שבוע אחד להריץ אותן.

נערוך סינון שקול ומנומק לסט ריצות אפשרי בלו"ז הנתון:

 -בזמן ובתקציב הנתון נריץ X

 -נכתוב ונעדכן Z בדיקות, תוך שיוך מיידי לדרישות החדשות

 -גורמי הסיכון הם …. ולכן נשים דגש על הנושאים הבאים:.....

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


ניהול תקלות

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

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

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

 

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

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

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

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

עוד בנושא...

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