בקרת צוות הבדיקות
פרקי ההרצאה: בקרת צוות הבדיקות
תמלול ההרצאה: בקרת צוות הבדיקות
הטקסט המלא של הדקות הראשונות בהרצאה «בקרת צוות הבדיקות» בקורס הווידאו של PracticU – כתוביות בעברית עם זמן התחלה לכל פסקה. כך תוכלו לקרוא ולחפש את הנושאים לפני שמתחילים ללמוד.
שלום, פרק 5.3 חומר ההסמכה מדבר על ניטור ובקרת בדיקות. המטרה של ניטור ובדיקות היא לאסוף מידע ולספק משוב ונהירות על פעילויות צוות הבדיקה.
אנחנו בעצם רוצים לתת כל הזמן שיקוף ושקיפות לאנשים שקשורים לצוות הבדיקות, אם זה מנהלי הפרויקט, מנהלי הגרסה, מנהלי המוצר, מנהלי הפיתוח, לגבי ההתקדמות של תהליך הבדיקות, בעצם coverage או איך אנחנו יכולים להגיד את הסטטוס של העבודה שאותה אנחנו עושים.
המידע המנוטר יכול להיאסף ידנית, זה קצת מיושן, או בצורה אוטומטית בעזרת המערכת שמתעדת את התקלות ואת הבאגים. בעצם משמש להערכת התקדמות הבדיקות ולמדידה אם הושג קריטריון היציאה מבדיקות.
שימו לב, המושג יציאה מבדיקות אומר, נקודה שבה הארגון יכול להגיד שהוא שלם מבחינת הסיכונים עם קבלת העברת המוצר ללקוח. פה הושגה נקודת הסיום במטלות הבדיקה של פרויקט הג'ילי, אם זה לא סבב מלא אלא סבב איטרציה מוקדמת לפני סבב מלא של המערכת.
השגת המטרה של כיסוי סיכוני המוצר, דרישות או קריטריון קבלה הן דוגמאות לקריטריונים כאלה. מכרת בדיקות כוללת כל פעולת הנחיה או תיקון המבוצעות כתוצאה מהמידע והמדדים שנאספו או דווחו פעולות אלה, עשויות להיות קשורות לכל פעילויות הבדיקה ולעיתים גם להשפיע על פעילויות בדיקות אחרות.
בואו נראה דוגמאות שיסבירו את המשפט הקודם. תעדוף מחדש של בדיקות כאשר סיכון של זרועה אכן מתרחש. זאת אומרת, אם פתאום מתגלה איזושהי תקלה משמעותית שמגדילה את הסיכון של העברת התוכנה למשתמש הקצה, החברה הלקוחה או לציבור אז אנחנו בעצם מעדכנים את כל מי שקשור
לתקלה הזאת ובעצם זה עלול או עשוי לגרום לשינויים בתוכניות עבודה של צוותים נוספים. שינוי לוח זמנים של בדיקות בשל זמינות או אי-זמינות של סביבת בדיקות או משאבים אחרים, זאת אומרת אנחנו רוצים לדווח האם העבודה והתנאים של צוות הבדיקות הם קיימים והצוות בדיקות יכול לבצע את העבודה שלו ללא הפרעה.
הרבה פעמים קורה שמכל מיני סיבות טכניות כמו אי תקינות של חומרה או מערכות או אי תקינות של דאטה בייס או אי עמידה בזמנים של צוות הפיתוח בעצם מתעכבת גם העבודה של צוותי הבדיקות.
הערכה מחדש האם פריט בדיקות שעבר שינוי עומד בקריטריון ההצייה או הכניסה? האם צוות הבדיקות בעצם מעלה את התוצרים של הבדיקות לדיון? האם מבחינת הארגון, מבחינת צוות הפיתוח, מבחינת צוות המוצר, מנהלי הפרויקט, האם באמת הבדיקות עשו כיסוי מספיק מבחינת תהליך העבודה.
מדדים שנעשה בהם שימוש התקדמות עבודה, התקדמות coverage, התקדמות ביצוע טסט קייסים אל מול לוח הזמנים והתקציב המתוכננים, האיכות הנוכחית של פריט הבדיקות, זאת אומרת מספר תקלות, מה מצב התקלות, תורת התקלות בגרסה או בפיצ'ר או במודל מסוים של המערכת שאותה אנחנו בודקים.
התאמת גישת הבדיקות לפריט הנבדק, האם הבדיקה היא נכונה, האם צריך לשנות גישה. לדוגמה, גישה של בדיקות גוי לעומת בדיקה של בדיקות נון גוי. יעילות פעילויות הבדיקה ביחס למטרות הבדיקה, האם אנחנו מתרכזים מבחינתנו במקומות הנכונים, האם אנחנו צריכים לשים דגש על מקומות אחרים אולי מבחינת המערכת הנבדקת.
מדדי בדיקות נפוצים כוללים אחוז העבודה שנעשתה בהכנת מקרה הבדיקה אל מול התכנון,