טכניקות לאומדן בדיקות
פרקי ההרצאה: טכניקות לאומדן בדיקות
תמלול ההרצאה: טכניקות לאומדן בדיקות
הטקסט המלא של הדקות הראשונות בהרצאה «טכניקות לאומדן בדיקות» בקורס הווידאו של PracticU – כתוביות בעברית עם זמן התחלה לכל פסקה. כך תוכלו לקרוא ולחפש את הנושאים לפני שמתחילים ללמוד.
שלום. בפרק 5.2.6 בחומר ההסמכה של ה-STQB מדברים על טכניקות לאומדן בדיקות. בתחילת כל סבב בדיקה, ברגע שמגיע הזמן שבו צוות הבדיקות צריך לתת חוות דעת בעקבות הרצת בדיקות, נדרשים אנשי הצוות, מנהלי הצוות, לתת הארכת זמן לגבי הזמן שייקח להם לבצע את משימות הבדיקה,
את סבבי הבדיקה. יש מספר טכניקות לאומדן המשמשות לקביעת המאמץ הנדרש, המאמץ זה אומר גם דמות האנשים וגם הזמן שייקח לתת את התוצאות, להעברת תוצאות מספקות מבחינת הגרסה שמועברת לבדיקות.
זאת אומרת, צוות הפיתוח סיים לפתח חלקים מהאפליקציה או כמה מודולים באפליקציה, וצוות הבדיקות אמור לבדוק אותם והוא צריך לתת הערכה, כמה זמן זה ייקח שתיים מהטכניקות הנפוצות ביותר לאומדן בדיקות לתת הארכת זמן הם אחת טכניקה מבוססת מדדים אומדן מאמץ הבדיקות
מתבסס על מדדים של פרויקט דומה קודם או מתבסס מתבסס על ערכים מקובלים זאת אומרת איזשהו אומדן של זמן לפי דוגמה של פרויקט דומה שעבר או גרסה קודמת של אותה מערכת שנבדקה. אם הגרסה הקודמת של האפליקציה לקחה שבועיים וחצי, אז כנראה שטווח הזמן שיינתן הוא טווח דומה.
טכניקה שנייה למתן אומדן זמן היא טכניקה מבוססת מומחים. אומדן מאמץ הבדיקות מתבסס על ניסיונות של המעורבים במשימות הבדיקה או של מומחים, גם זה סוג של התבססות על מקרה עבר.
אנחנו בעצם רוצים להעריך מה החלקים שפותחו, מה המורכבות של החלקים שפותחו, ולתת הערכה כמה זמן ייקח לנו לבדוק את זה. תוך כדי, ניקחה בחשבון של מספר התקלות שיש, מספר הטסטים שיש להעריץ, מספר התסריטים, הסיפורי משתמש, סיפורי לקוח שצריך לבצע, כל אלה יחד עם הערכה של פרויקטים דומים או גרסאות קודמות,
כמה זמן זה לקח, זה בעצם ייתן לנו אומדן פחות או יותר סביר לגבי ההערכה של הזמן העתידי, כמה ייקח הבדיקה. פה בחומר הלימודים יש דוגמה של פיתוח אג'ילי, פיתוח מואץ של תרשימי התקדמות, זאת אומרת burn-down chart, זה איזושהי שיטת עבודה במחזור חיים של פיתוח תוכנה בשיטת אג'ייל,
דוגמה לגישה מבוססת מדדים שבה המאמץ מתועד ומדווח ואז מחושב לקביעת כמות העבודה שהצוות יכול לבצע במחזור הפיתוח הבא. זאת אומרת, להתבסס על סבבים קודמים על מנת להסיק לסבבים העתידיים.
אם סבב קודם לקח לנו שלושה עד חמישה ימי עבודה לתת תוצאות בדיקות של צוות הבדיקות, אז אנחנו נמצא מתוך הנחה שיהיה גם בהמשך סדר גודל דומה, אם לא יהיה שינוי לדוגמה נפח או הכמות של הפיתוחים, או אם יהיה גידול בבדיקות האוטומטיות שעשוי להקטין את משך הזמן.
לעומת זאת, פוקר תכנון, שזה Planning Pocker, שזה גם סוג של שיטת עבודה בפיתוח רגילי, הוא דוגמה לגישה מבוססת מומחים, זאת אומרת, באים ושואלים את הטסטרים איך הם מעריכים, כמה זמן ייקח להם לתת את התוצאות להגיע למצב שהם נותנים אוקיי לגרסה, נותנים אישור יציאה.
בפרויקטים המשכיים, לדוגמה ווטרפול להסרת פגמים זאת אומרת לדיבאגינג לחיסול של באגים שנמצאו בתוכנה או על ידי המשתמשי הקצה או על ידי הבודקים בסבבים קודמים בעצם גישה דוגמאות לגישה שמבוססת מדדים שבה כמות הפגמים כמות הבאגים הפתוחים כמות התקלות הפתוחות והזמן הנדרש
להשיא אותם מתועדים ומדווחים ואז משמשים בסיס לאומדן פרויקטים עתידיים בעלי אופי דומה זאת אומרת אם אם אנחנו יוצאים מתוך