שבעת עקרונות הבדיקה
פרקי ההרצאה: שבעת עקרונות הבדיקה
תמלול ההרצאה: שבעת עקרונות הבדיקה
הטקסט המלא של הדקות הראשונות בהרצאה «שבעת עקרונות הבדיקה» בקורס הווידאו של PracticU – כתוביות בעברית עם זמן התחלה לכל פסקה. כך תוכלו לקרוא ולחפש את הנושאים לפני שמתחילים ללמוד.
שלום בשיעור הקרוב נעבור על שבעת עקרונות הבדיקה פרק 1.3 בחומר ההסמכה של ה-STQB. במהלך חמישים השנים האחרונות הוצאו מספר עקרונות בדיקה שכללו עקרונות מנחים משותפים לכל סוגי הבדיקות.
אז בואו נעבור על שבע עקרונות הבדיקה. 1. הבדיקות מצביעות או יכולות להצביע על נוכחות של פגמים באגים, אך לא על היעדרם, מה הכוונה?
בדיקות יכולות להצביע על נוכחותם של באגים, אינן בהכרח מצביעות על היעדרם של באגים זאת אומרת אם אני מבצע בדיקות על מערכת מסוימת ולא מוצא תקלות במהלך זמן הבדיקות יכול להיות יומיים שלושה שבוע זה לא אומר שאין במערכת תקלות או באגים אלא שלא מצאתי יותר באגים ממה שדיווחתי מלכתחילה זאת אומרת אם לא דיווחתי תקלות זה לא אומר שהמערכת מושלמת.
יכולות להפחית את הסיכוי שיישארו פגמים חבויים בתוכנה, אך גם אם לא נמצאו פגמים, בדיקות אינן הוכחת תקינות. זאת אומרת, אנחנו לא יכולים להתבסס על עצם קיום הבדיקות ולהגיד שאין יותר פגים בתוכנה או באתר שאותו אנחנו בודקים. 2. בלתי אפשרי לבצע בדיקות ממצות אקסרזוטיב טסטינג is
impossible בדיקות ממצות אינן אפשריות מה הכוונה? בדיקה של כל צירופי הקלט והפלט וכל התנאים המוקדמים וכל התנאים שבהם ייבדקו או תעבוד התוכנה אינה בת ביצוע בוא נחשוב על מערכת ההפעלה אנדרואיד אם אנחנו נרצה לבצע בדיקות על מערכת ההפעלה אנדרואיד הרי לא ייתכן שנבצע את כל הבדיקות על כל המכשירים האפשריים שיהיו או היו והשתמשו באנדרואיד פשוט בלתי
אפשרי זאת אומרת אנדרואיד זו מערכת הפעלה אומנם זה לא תוכנה אבל לצורך העניין גם היא ברת בדיקה, זאת אומרת גם היא יכולה להיבדק וכשאנחנו בודקים מערכת גדולה כמו אנדרואיד אז אנחנו יכולים להניח בהכרח שלא נבדוק את כל המצבים שבהם היא תעבוד, את כל החומרה, את כל הקשוחה שהיא יכולה לעבוד
עליה, על כל ה-hardware, את כל ה-devices שהיא תעבוד עליהם ולכן אנחנו יכולים להגיד שלא בדקנו אותה בכל התנאים. במקום לנסות לבצע בדיקות ממצות יש לעשות שימוש בניתוח סיכונים ריסק אנליסיס ובטכניקה לעיצוב בדיקות ולהעמיד סדרי עדיפויות על מנת למקד את המאמץ
אם אנחנו יוצאים מתוך הנחה שאנחנו לא יכולים לכסות את כל המצבים ואת כל דרישות הקדם והתנאים של המערכת שלנו אנחנו צריכים לבנות איזושהי מטריצה שבה אנחנו נציע איך כן לבדוק את המערכת שלנו על כמה שיותר דיווייסים על כמה שיותר תנאים על מנת להקטין את הסיכונים אנחנו יוצאים מתוך הנחה
שאף פעם לא נוכל לבצע את כל הבדיקות האפשריות תמיד יהיו עוד בדיקות על עוד תנאים על עוד בראוזרים על עוד מערכות הפעלה עם עוד סוגי משתמשים אבל אנחנו יכולים לצאת מתוך הנחה שאם אנחנו בודקים את המערכת שלנו לדוגמה יש לנו אתר שאותו אנחנו רוצים לבדוק אתר כלשהו למכר אלקטרוני אז אנחנו בודקים אותו על
דפדפנים אינטרנט אקספורר וכרום אז אנחנו יוצאים מתוך הנחה שכיסינו את רוב המצבים או את רוב הדפדפנים שאיתם ינסו הלקוחות שלנו להיכנס לאתר.
זה Risk Analysis. אז אנחנו לא בודקים את כל הדפדפנים בשוק, אבל אנחנו כן נבדוק את הדפדפנים העיקריים. בלתי אפשרי לבצע בדיקות ממצות, בדיקות מלאות, אלא אם זו מערכת מאוד פשוטה, לדוגמה מחשבון או משהו כזה פשוט.
3. בדיקות מקדימות חוסכות זמן וכסף. על מנת להקדים ולמצוא באגים, להתחיל פעילות בדיקות דינמיות וגם סטטיות מוקדם ככל האפשר במחזור חיי התוכנה.
זאת אומרת, אנחנו יודעים שמחזור חיי תוכנה, אם זה בצורת אג'ייל או בצורת ווטרפול רגילה, מתחיל שלב האיפיון, שלב כתיבת הדרישות, שלב ה-Business Story.
ככל שנקדים ונכניס את תהליך אבטחת האיכות מוקדם יותר, את הבודקים, את הטסטרים, את המערכת שמבקרת, את האנשי פיתוח, אותם מאפיינים, כך נעלה על תקלות מהר יותר.
בדיקות מוקדמות נקראות לעיתים הזזה לשמאל שיפט לפט, שילוב הבדיקות מוקדם ככל האפשר במחזור חיי התוכנה עוזר להפחית ואף למנוע שינויים באגים יקרים. ראינו את הסכמה שאומרת שככל שבאג נמצא בשלב מאוחר יותר בלייב סייקל של הפיתוח העלות של התיקון שלו עולה.
אנחנו יכולים לראות באתר טריי QA את הגרף הזה שמסביר ככל שהבאג נמצא מאוחר יותר בתהליך הפיתוח, התיקון שלו, המחיר עולה ביחס ישיר.
כל הזמן יהיו לו עלויות של עבודה, עלויות של תחלופה, עלויות של מוניטין, עלויות של כוח אדם גבוהות יותר ככל שנעשה את זה רחוק יותר בתהליך הפיתוח, תהליך העבודה.
עקרון 7 מתוך 7 עקרונות הבדיקה