פתרון שאלות מתוך מבחן ISTQB - חלק 2
פרקי ההרצאה: פתרון שאלות מתוך מבחן ISTQB - חלק 2
תמלול ההרצאה: פתרון שאלות מתוך מבחן ISTQB - חלק 2
הטקסט המלא של הדקות הראשונות בהרצאה «פתרון שאלות מתוך מבחן ISTQB - חלק 2» בקורס הווידאו של PracticU – כתוביות בעברית עם זמן התחלה לכל פסקה. כך תוכלו לקרוא ולחפש את הנושאים לפני שמתחילים ללמוד.
שאלה 11 איזה מהבאים מהווה אירוע שבעקבותיו צריך לבצע בדיקות תחזוקה? מהאינטננס טסטינג נעשה שינוי ברכיב תוכנה שמהווה חלק מהמוצר ששוחרר כבר.
ב. התקבל תיקון למוצר שנמצא בשלבי פיתוח מתקדמים. התגלתה תקנת נסיגה רגרשן בסדרה של תיקונים שהגיעה מהמפתח.
ד. התקבלה דרישה חדשה לתוכנה שנמצאת בבדיקה וזו יכולה לגרום לשינוי מבנה המוצר. אנחנו צריכים לזכור שבדיקות תחזוקה מתבצעות כשהמוצר כבר נמצא אצל הלקוח, כבר יש שימוש מסחרי ויש שימוש חוזי במוצר ואז אנחנו מבצעים איזשהו עדכון, איזשהו שיפור של המוצר שכבר נמצא בשימוש.
תשובה נכונה במקרה הזה היא א', נעשה שינוי ברכיב תוכנה שמהווה חלק ממוצר ששוחרר כבר, זאת אומרת שהוא כבר נמצא אצל הלקוח.
תשובה ב' התקבל תיקון למוצר שנמצא בשלבי פיתוח, אנחנו כבר מבינים שזה לא נכון. התגלתה תקלת נסיגה regression בסדרה של תיקונים שהגיעה מהמקוותח, זאת אומרת לא מדובר פה על עדיין החלק של הלקוח.
התקבלה דרישה חדשה לתוכנה שנמצאת בבדיקה, זאת אומרת נמצאת בבדיקה ולא אצל הלקוח בייצוא. שאלה 12 כאשר עובדים לפי מחזור חיים ממודל V, מה צריכים הבודקים לעשות כאשר מסמכי הייצוב דיזיין מוכנים?
א', לכתוב קוד לבדיקות יחידה Unitest, ב', לכתוב בדיקות אינטגרציה, Integration Test Case, לבצע סקירה Review של מסמכי הדרישות, לכתוב בדיקות קבלת מערכת.
אז אנחנו זוכרים שבמודל V יש הקבלה בין שלבי מחזור החיים של פיתוח התוכנה לשלבי הבדיקות. כאשר מסמכי הייצור מוכנים, זאת אומרת הם הסתיימו, אנחנו כבר יכולים להתחיל לעבוד על כתיבת בדיקות המתקדמות יותר, על בסיס מסמכי העיצוב design, זאת אומרת הם כבר מוכנים.
ולכן אנחנו צריכים להתחיל לכתוב בדיקות אינטגרציה. א', לכתוב קוד לבדיקות יחידה זה לא התפקיד שלנו, זה יותר תפקיד של המפתחים עצמם לבדוק את הקוד שלהם, את הקוד של העמיתים שלהם, של הקולגות שלהם.
לכתוב בדיקות קבלה מערכת זה שלב מאוחר מדי, לפני כן אנחנו נרצה לעשות בדיקות אינטגרציה. ולכן התשובה היא ב', שאלה 13: לאיזה סוג של בדיקות שייכות בדיקות שימושיות Usability Testing?
כן, אנחנו מדברים על בדיקות שבהן אנחנו בעצם מרגישים את חוויית המשתמש, הקצה. אז א', פונקציונליות, ב' לא פונקציונליות, ג', מבניות, ד', מבוססות שינוי.
אז התשובה הנכונה היא, ב', כשאנחנו רוצים להרגיש איך המשתמש, את חוויית המשתמש, אנחנו לא בדיוק עושים בדיקה פונקציונלית של התפקידים של המערכת, זאת אומרת, יכול להיות שנעשה את זה תוך כדי, אבל המטרה של הביצוע היא לא לבדוק את התוצרים, אלא לבדוק את הבהירות של השימוש, את הנוחות של השימוש,
את המהירות של קבלת התשובה, ולכן זה סוג של בדיקות לא פונקציונליות, התשובה הנכונה תהיה "ב'". בדיקות שימושיות User Experience Usability Testing, שזה גם מתאים לבדיקות נגישות, בדיקות של בעלי מוגבלויות או אנשים עם מגבלה כלשהי, אז הן מתאימות לבדיקות לא פונקציונליות.
שאלה 14: בסקירה פורמלית, פורמל ריוויו, מי אחראי בדרך כלל לתיעוד הנושאים שנותרו פיתוחים? א. המתאם, ב. כותב המסמך, ג. הרשם, ד. המנהל אז זה שאלה שלקוחה מהעולם של האג'ייל קצת וצריך להכיר את הנושא התפקידים.
המתאם מודרטור הוא לא אחראי לתיעוד הנושאים שנותרו פתוחים. כותב המסמך הוא גם לא זה שאחראי על תיעוד הנושאים שנותרו פתוחים אבל הרשם הסקרייב הוא זה שבעצם מתעד את הדברים שנותרו פתוחים באותו טקס של סקירה פורמלית.
כלומר, זה יכול להשתנות, אבל ברמה הפורמלית התיאורטית הרשם הוא זה שאחראי על הניהול ותיעוד הנושאים שנותרו פתוחים מבחינת הסקירה.
המנהל הוא כמובן לא זה שאחראי על התיעוד, אלא הוא זה שצריך לקבל שירות מאחד מהאחרים, ובמקרה שלנו הרשם הוא זה שרושם מה חסר מבחינת את הסקירה הפורמלית לתיעוד הנושאים הפתוחים של ה-Review.
שאלה 15, איזה מהבעיות הבאות קלות לזיהוי בעזרת ניתוח סטטי, Static Analysis? זאת אומרת, לא דינמי. טעות בנוסחה, דליפת זיכרון, קטע קוד מת, קוד שלא טוען דרישות.
זאת אומרת, אנחנו רוצים לראות איזה מהבעיות שהועלו פה הוזכרו בתשובות, לזהות אותם ללא הרצת הקוד ממש, טעות בנוסחה.
טעות בנוסחה יהיה קשה לזהות, אפשרי, אבל קשה לזהות ללא קבלת התוצאה ולראות בעצם האם הייתה טעות או לא. זאת אומרת, אנחנו בדרך כלל נרצה לבדוק נוסחה על ידי הרצה שלה ולהשוות את התוצאה מול התוצאה שאנחנו מצפים לקבל.
בפרט זיכרון ממוריליק, בעצם יהיה לנו קשה לזהות את זה ללא הרצה, כי בעיית זיכרון זה משהו שקורה תוך כדי שימוש ולא מיד אז זה בטח לא דבר שקל לזהות ללא הרצה.
קטע קוד מת זה אומר קטע קוד שבעצם כתבו אותו אבל אין בו שימוש, הוא אף פעם לא התבצע. התרשים זרימה של הקוד בעצם אף פעם לא יהיה מצב שהוא יהיה בשימוש אותו קוד.
התשובה בדל"ת, קוד שלא תואם לדרישות זה גם קשה לנו לאבחן אותו ללא ריצה, ללא ביצוע בדיקה דינמית. הדבר הכי נכון מבחינתנו זה תשובה ג', קוד מת אמור להתגלות על ידי שימוש בכלי ניתוח סטטי, כלי בעצם שבודק את התקניות של הקוד שלנו, ולא על ידי הרצה וקמפול של הקוד.
תשובה ד' לא נכונה מאחר ואי-התאמה לדרישות תתגלה על ידי סקירת קוד בה אדם בודק את הקוד אל מול הדרישות. זה יכול להתגלות גם בשלב הבדיקות. שאלה 16 איזה טכניקת בדיקות תהיה היעילה ביותר להערכה התחזוקתיות מנטנביליטי של הקוד ושיפורה.
א', סקירת עמיתים, Peer Reviews, ב', ניתוח סטטי, Static Analysis, ג', בדיקות דינמיות, Dynamic Testing, ד', בדיקות יחידה, Unit Testing.
בשאלה הזאת בעצם שואלים אותנו איזה טכניקת בדיקות היא הנכונה ביותר להעריך את הצורך במיינטננס של הקוד ושיפורה. התשובה הנכונה ביותר היא ב' ניתוח סטטי, שבו אנחנו נעשה שימוש באמצעות כלים שמנטרים את הקוד ובודקים את הקומפילציה שלו, וכך נראה שבאמת הוא כתוב בסטנדרטים של כתיבת קוד נכונה.
אז כשאנחנו רוצים לבדוק הערכת תחזוקתיות ואינטנביליטי אנחנו מדברים על ניתוח סטטי. שאלה 17 אם אנחנו כותבים מקרה בדיקה test cases והתבסס על קריאה של הקוד, באיזה סוג של טכניקה תצאו בדיקות אנו משתמשים?
בעצם אנחנו מדברים על קריאה של הקוד ובדיקה של איך נכתב הקוד עצמו. אז איזו טכניקה, א. קופסה שחורה, ב. קופסה לבנה, ג. מבוסס על מפרט, ד. מבוסס התנהגות. אז בואו נחזור על המושגים.
קופסה שחורה בעצם בודקת את התוצאות של המערכת שאותה אנחנו בודקים. זה לא מתאים כי פה כתוב בפירוש שאנחנו מביא מקרה בדיקה בהתבסס על קריאה של הקוד עצמו, אז אנחנו לא מתייחסים לזה כקופסה שחורה.
קופסה לבנה, זאת אומרת קריאה של הקוד עצמו ובחינת אופן המימוש הקוד זה די מתאים. בואו נמשיך. מבוסס על מפרט, אנחנו קוראים את הקוד, המפרט הוא לפני כתיבת הקוד, זאת אומרת הקוד מבוסס על המפרט אבל זה לא בדיוק הקטע של לקרוא את הקוד אלא לקרוא את האפיון, אז ג' היא לא נכונה, ד',