בחן את עצמך | טל פאר

בבודקים נתפשים לעיתים כאחראים לאיכות התוכנה ולכך שלא יהיו פגמים (defects, bugs) בתוכנה שנמסרת ללקוחות. בתחילת דרכי נשאלתי, עם סיום הבדיקות, האם מצאתי את כל הבאגים במערכת. עניתי בשאלה "כמה באגים הכנסת למערכת?".

כדי שהבדיקות יהיו יעילות ויחשפו את הכשלים והפגמים החשובים ביותר (למשל, הקריטיים ביותר), כמו גם את מספר הפגמים הרב ביותר, על צוות הבדיקות לעבוד לפי מספר עקרונות. הסילבוס של ISTQB® לרמת הבסיס (CTFL) מציג מספר עקרונות מנחים בסיסיים ואלה משותפים לכל סוגי הבחינות. עקרונות אלה הוצגו על ידי מספר אנשים לאורך השנים ו-ISTQB ריכז אותם לרשימה אחת. מחוץ לסילבוס אפשר ללמוד על עקרונות אלה בספרים כמו Software Testing Techniques של בוריס בייזר (Beizer) ו-The Art of Software Testing של גלנפורד מאיירס (Myers).

השאלה של היום מציגה איך להשתמש בעקרונות אלה.

(לשם הבהרה אומר שאני בוחר להשתמש במושג פגם, כמו שמופיע בסילבוס בעברית, למילה שבשפת היומיום אנחנו קוראים "באג" מאחר וה"באג" אותו אנו מוצאים בזמן הבדיקות הוא למעשה ה"כשל").

 

צוות הבדיקות שלך סיים את הרצת סבב הבדיקות האחרון שתוכנן והערכה היא שמצב איכות התוכנה הוא טוב וניתן לשחרר את המוצר. כשהצגת את דו"ח הבדיקות המסכם להנהלת הפרויקט, נשאלת אם קיימים בתוכנה פגמים (defects, bugs) שלא התגלו על ידי הבדיקות.

מה תהיה תשובתך, תוך הצדקה באחד משבעת עקרונות הבדיקה?

• אין בתוכנה פגמים נוספים מאחר צוות הבדיקות חזר על הבדיקות מספר פעמים ולא גילה פגמים חדשים.
• אין בתוכנה פגמים נוספים מאחר וצוות הבדיקות היה מעורב בתהליך הפיתוח משלב מוקדם.
• קיימים פגמים נוספים שצוות הבדיקות יוכל לגלות אם יתאפשר לו לבצע בדיקות ממצות (exhaustive testing).
• לא ניתן לדעת אם קיימים פגמים נוספים מאחר והבדיקות מגלות פגמים אך לא יכולות להוכיח שאין פגמים נוספים.

 

הפתרון לשאלה

נתחיל עם יעד הלימוד ורמת הידע הדרושה לנושא הזה. את יעדי הלימוד ניתן למצוא בעמוד הראשון בכל פרק. לכל יעד לימוד מוגדרת רמת הידע הדרושה לו (K-level).

יעד הלימוד שלו מתאימה שאלה זו היא FL-1.3.1 "הסבר את שבעת עקרונות הבדיקה" והיא ברמה K2. רמה זו אומרת שעל הנבחן להבין את התשובה הנכונה על פי הנושא הנלמד.

כאמור, עקרונות הבדיקה המוצגים בסילבוס הוגדרו על ידי מומחי בדיקות לאורך שנים, בהתבסס על ניסיון רב בתכנון וביצוע בדיקות. עקרונות אלה מראים, למשל, שככל שנקדים את תחילת הבדיקות (early testing) נגלה פגמים בשלב מוקדם יותר בתהליך הפיתוח (למשל, זיהוי פגמים בדרישות) וכך נחסוך זמן וכסף מאחר והפגמים יתוקנו עוד לפני כתיבת הקוד ולפני שהמערכת נמסרת לבדיקות.

עיקרון אחר מדגיש שגם אם ביצענו בדיקות כראוי ואנחנו (יחד עם צוות הפרויקט) מרגישים שהמערכת מוכנה למסירה, הרי שייתכן והמערכת לא באמת עונה על דרישות הלקוח.

הבה נבחן את התשובות:

• עיקרון 5 (פרדוקס ההדברה, pesticide paradox) מזהיר מחזרה על אותן בדיקות שוב ושוב. אם נבצע את אותן בדיקות שוב ושוב הן לא יגלו פגמים חדשים מאחר הבדיקה מצאה את כל הפגמים שהיא יכולה למצוא. כדי להימנע מכך וכדי למצוא פגמים חדשים יש לשנות את הבדיקה (לדוגמה, להשתמש בנתונים אחרים או לשנות את סדר הצעדים בבדיקה) או לכתוב בדיקות חדשות. זוהי אינה תשובה נכונה.
• שילוב הבודקים בשלב מוקדם בתהליך הפיתוח הוא צעד נכון, שכמו שהצגתי למעלה, עשוי לזהות פגמים בשלב מוקדם ולהביא לחיסכון בזמן וכסף. אולם זה לא אומר שבכך לא יוצגו פגמים במערכת או שזה יסייע במציאת כל הפגמים. זוהי אינה תשובה נכונה.
• סביר להניח שאם יתאפשר לצוות הבדיקות לבצע בדיקות ממצות (exhaustive testing) יימצאו במערכת פגמים נוספים שלא נמצאו עד כה, אולם זה בלתי אפשרי לבצע בדיקות ממצות ולכן תשובה זו אינה נכונה.
• כל זמן שצוות הבדיקות מבצע בדיקות הרי שבסבירות גבוהה (עד מאוד) יימצאו פגמים חדשים. מציאת פגמים מוכיחה שקיימים פגמים במערכת, אך גם מציאת פגמים רבים אינה יכולה להוכיח שבסיום התהליך אין פגמים נוספים במערכת. זהו העיקרון הראשון ברשימת העקרונות שבסילבוס "הבדיקות מצביעות על נוכחות של פגמים, לא על היעדרם" (presence of defects).

לפי ההסברים הנ"ל התשובה הנכונה היא תשובה ד'.

אם תרצו שאגיש שאלת דוגמה בנושא מסוים או אם יש לכם שאלות אנא פנו אלי באימייל [email protected]