ניטור ובקרה של בדיקות
פרקי ההרצאה: ניטור ובקרה של בדיקות
תמלול ההרצאה: ניטור ובקרה של בדיקות
הטקסט המלא של הדקות הראשונות בהרצאה «ניטור ובקרה של בדיקות» בקורס הווידאו של PracticU – כתוביות בעברית עם זמן התחלה לכל פסקה. כך תוכלו לקרוא ולחפש את הנושאים לפני שמתחילים ללמוד.
שלום לכולם. בשיעור הקודם דיברנו באופן כללי על הפעילויות ומטלות צוות הבדיקות, סעיף 1.42 בחומר ההסמכה הרשמי של ה-STQB ועכשיו נתחיל לפרט למה הכוונה.
תכנון הבדיקות טסט פלנינג בעבר היה נהוג לכתוב מסמך טסט פלנינג, מסמך רשמי שמכיל תשובות לשאלות הבאות מה אנחנו הולכים לבדוק, מה ה-requirement שאנחנו מבקשים לכסות, כמה טסטים אנחנו הולכים לכתוב, איזו גישה של בדיקה אנחנו הולכים לאמץ, האם בדיקת רגרסיה, האם בדיקת שפיות, האם בדיקת
פונקציונליות, האם בדיקת רכיב, כמה זמן ייקח לנו לבדוק, מי האנשים שהולכים לבדוק, איזה משאבים אנחנו הולכים להשתמש בהם, על איזה מכונות, על איזה מערכות הפעלה אנחנו הולכים לעבוד, כמה כוח אדם נצטרך, מה ההכשרה של הכוח אדם.
כל השאלות האלה היו באות ומתייחסות בקובץ של ה-Test Plan. נטייה היום היא לעשות את הדברים יותר גמישים ופחות חד משמעיים, פחות סטטיים ומתוך הנחה שאנחנו נצטרך תמיד לעדכן ולרענן את ה-Test Plan של צוות הבדיקה.
זאת אומרת, אם אנחנו נצטרך לבדוק על עוד מערכות אנחנו נוכל להוסיף אותן בקלות, נצטרך לעדכן את זה באיזשהו מסמך רשמי או לעדכן את ההנהלה או את צוות הניהול של הפיתוח ושל הבדיקות.
אם אנחנו צריכים עוד כוח אדם, אם אנחנו צריכים לכתוב עוד טסטים, אם אנחנו צריכים לשנות מתודולוגיה של בדיקות, איזה מערכות יעזרו לנו לבדוק את האפליקציה שאותה אנחנו רוצים לבדוק.
כל אלה יופיעו בחלק הזה של טסט פלאנינג. מה שחשוב לי להגיד, שבעבר זה היה יותר סטטי, יותר פורמלי, קובץ מובנה שמכיל את התשובות לכל השאלות שציינתי קודם, היום הנטייה היא לעשות את זה יותר דינמי בצורה כזאת שגם אם יש מסמך, הוא יהיה מסמך שהוא יעודכן וישודרג כל הזמן.
האחריות על המענה לשאלות שציינו, מה לבדוק, איך לבדוק, כמה זמן, מה הסיכונים וכדומה, היא באחריות צוות הניהול של צוות הבדיקות, לפחות מנהל בדיקות או מנהל צוות הבודקים.
הבודק עצמו, הבודק שאיש ה-QA שאמור לבדוק או שאמור לבצע, פחות יתעסק בנושא התכנוני, הלוגיסטי, המינהלי או הניהולי הזה של טסט פלנינג. ניטור ובקרה של בדיקות טסט מוניטורינג אנד קונטרול.
אנחנו נרצה לשקף את ההתקדמות של צוות הבדיקות במערך הטסטים שהתחייבנו להריץ מול הארגון, מול הצוות הניהולי של הארגון. אנחנו נרצה לדווח למנהל המוצר, מנהל הגרסה, מנהל צוות הבדיקות, מנהל הפיתוח או כל דרג ניהולי אחר, את הקצב התקדמות שלנו על מנת להעריך את העמידה ביעדי הבדיקות.
הניטור הוא בקר של בדיקות, הוא המשך ישיר לנושא של תכנון הבדיקות. אנחנו מעריכים כמה זמן ייקח לנו לבדוק, אנחנו מתחייבים על לוחות זמנים, אנחנו בונים סט של טסטים שעונה לקוורט של דרישות, של requirement, ובעצם אנחנו רוצים לדווח על ההתקדמות שלנו ועל מצב תהליך הבדיקה.
יש לנו פה קריטריון יציאה שמוגדר כנקודת סיום, שבו אנחנו יכולים להגיד שביצענו את סבבי הבדיקות בצורה מספקת. אז הערכת קריטריון יציאה לביצוע בדיקות ברמת בדיקות נתונה עשוי לכלול בדיקת תוצאות הבדיקה והלוגים אל מול קריטריון הכיסוי.