בחירה של טכניקת בדיקה
פרקי ההרצאה: בחירה של טכניקת בדיקה
תמלול ההרצאה: בחירה של טכניקת בדיקה
הטקסט המלא של הדקות הראשונות בהרצאה «בחירה של טכניקת בדיקה» בקורס הווידאו של PracticU – כתוביות בעברית עם זמן התחלה לכל פסקה. כך תוכלו לקרוא ולחפש את הנושאים לפני שמתחילים ללמוד.
בסרטון זה נמשיך לעבור על פרק 4 בחומר ההסמכה של ה-STQB. הכרנו את המושגים שבהם אנחנו נכיר או נתעסק במהלך הפרק ועכשיו אנחנו מדברים על קטגוריות של טכניקות בדיקה, זאת אומרת מהי קטגוריה ומתי אנחנו בוחרים בקטגוריה מסוימת על פני אחרת.
אז מה המטרה בעצם של החלוקה של שיטות הבדיקה לטכניקות או מה המטרה של טכניקת הבדיקה? טכניקת בדיקה היא בעצם, המטרה שלה היא לסייע בזיהוי המצבי בדיקה, מקרי בדיקה ונתוני בדיקה, כלומר לסייע לנו בעצם להתמודד עם האתגר של לכתוב מערכת בדיקות או סט של בדיקות למערכת שאותה אנחנו רוצים לבדוק, להסביר את האסטרטגיה שלנו,
להסביר את ההיערכות שלנו ואיך אנחנו הולכים להתמודד בעצם ולכתוב את הטסטים על מנת לתת את הביטחון הנדרש לארגון, שאכן בדקנו את המערכת בכל המצבים ובכל הדרישות ובכל הקונפיגורציות, ולצורך זה אנחנו נשתמש בידע התיאורטי של טכניקות בדיקה.
איך נבחר את טכניקת הבדיקה המתאימה לנו? נקרא טכניקת בדיקה, תלויה במספר גורמים שאנחנו נוכל להכיר ועל ידי כך בעצם לדעת איך לבחור איזו טכניקה עדיפה.
אז סוג הרכיב או המערכת, אותה אנחנו בודקים. האם סוג הרכיב או המערכת היא מיועדת לקהל הרחב? האם היא מערכת ניהול, מה שנקרא Backoffice או קונפיגורציה, שמי שבודק אותה הם אנשי הארגון, אנשים שמכירים את המערכת?
זה שני סוגים בעצם. אם אנחנו בודקים מערכת שהיא לקהל הרחב, אנחנו צריכים מאוד להקפיד על ה-user experience, על הוויזואליות, על הבהירות של כל חלק וחלק במערכת למשתמש הקצה.
אם אנחנו בודקים מערכת שהיא מערכת Back-Office או מערכת שמיועדת לאנשי אדמיניסטרציה או מערכת פנימית למשתמשי אדמין מקומיים או מעטים שיכירו את המערכת על בוריה ואין צורך יותר מדי להתמקד בבדיקות שהן User Experience או End User, יש את ההבדל הזה בין מי הם המשתמשים, משתמשי קצה כלליים לקהל
הרחב או משתמשים מומחים מתוך הארגון. מורכבות המערכת, כן, או הקומפוננטה שאותה אנחנו בודקים, האם הקומפוננטה היא מאוד מאוד ברורה או שהיא מבוססת על ידע רב ועל משתמשים שהם עם ידע עצום במערכת והמערכת היא מאוד מורכבת, אז אנחנו נצטרך לראות איך אנחנו נערכים לזה.
לעומת זאת, אם אנחנו בודקים אפליקציה שמיועדת לקהל הרחב, אז אנחנו צריכים להיות מאוד straight forward עם תהליכים מאוד מובנים, מאוד ברורים של סיפורים, ככה שזה גם משפיע על הטכניקה.
קנים רגולטוריים, אם אנחנו בודקים מערכת שהיא תחת תקן, אז אנחנו בעצם חייבים להכיר את התקן ולכתוב את הטסטים בהתאם להנחיות, בהתאם לדרישות, כל חלק וחלק שיפותח, מוגדר האם הוא חלק שהוא קריטי, האם הוא חלק שהוא לא קריטי, איזה רמה של בדיקה,
מהם תנאי הקבלה, תנאי המסירה וכדומה, להכיר את המושגים האלה. האם דרישות לקוח הועברו? גם זה חלק מהמשפיעים על הבחירת טכניקה או על הצורה שבה נכתוב את הטסטים שלנו.
האם יש דרישות חוזיות שדורשות מאיתנו לפרט את הסיפורי משתמש או כדומה, אז גם זה דבר שישפיע. רמות הסיכון, מערכות עם סיכון גבוה כמו מערכות מצילות חיים, מערכות רפואיות או מערכות בידור, מערכות פנאי, שגם הן חשובות מאוד ללקוח, יש בהם רמה אחרת של סיכון מבחינת הבדיקות.
סוגי הסיכון, כן, האם זה הפסד כסף גדול בפעילות מסוימת של אפליקציה מסוימת, לדוגמה אפליקציית מכירה, אז מבחינת הלקוח סוגי הסיכון מתחלקים להאם חוויית המשתמש תיפגע או האם ההפסד יהיה כספי, אז זה ישפיע גם כן על טכניקת הבדיקה ועל הצורה בה נכתוב את הטסטים.
מטרות הבדיקה, האם הן מטרות פנימיות או מטרות לצורך הצגה ללקוח או מטרות רגולטוריות? האם יש תיעוד זמין למערכת או מבוססת על ניסיון של בודקים, ניסיון של משתמשי המערכת?
ידע וכישורי הבודק, האם הבודק מנוסה, האם הוא בדק כבר את המערכת בעבר או מערכת דומה?