משימות בדיקה מראיונות עבודה - חלק ג'

בחלק השני של המאמר דנו בבדיקות של מוצר פשוט עם תלויות. בחלק זה - השלישי והאחרון למאמר, נעסוק בבדיקות של מוצר מולטי-מודולורי.

משימות בדיקה מראיונות עבודה - חלק ב'

בפוסט הקודם דנו במשימות בדיקה בסיסיות. עתה, נעבור לדון במשימות מורכבות מעט יותר.

משימות בדיקה מראיונות עבודה - חלק א'

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

אז למה לי רגרסיה עכשיו ?

כל בודק מתחיל יודע לדקלם מה זה בדיקות רגרסיה - הבדיקות שמבצעים אחרי שינויים בקוד.
אבל למה בדיוק צריך את הבדיקות האלה ? למה לא מספיק לעשות Sanity וזהו ? אילו בדיקות נכנסות לקטגוריה הזו ואילו לא ?
על כך נדון בפוסט הנ"ל.

איך להתראיין לתפקיד בודק ?

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

מהן התכונות של בודק טוב ?

בפוסט הזה נדון בתכונות שהופכות בודק מהשורה לבודק טוב. כמו בהרבה תחומים, חלק מהתכונות נדרשות וחלק נרכשות.

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

גם שוני בין מוצרים משפיע על האיכות הנדרשת מהבודקים. תכונות נדרשות מבודק של end product עשויות להיות שונות לגמרי מתכונות של low level product, כנ"ל גם בין בודק של GUI ובודק של תוכנה.

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

הסדר לאו דווקא מעיד על החשיבות.

מה זה Agile ?

כל מי שעבד בבדיקות או בפיתוח אי פעם שמע את המושג לפחות פעם אחת. בפוסט ננסה להסביר לא רק מה זה agile אלא גם מה האלטרנטיבה הנפוצה שלו (שיטת המפל - Waterfall) ואיך זה משפיע על הלך העבודה של הבודק בחברה בה הוא עובד.

הרצאה של ג'יימס באך על בדיקות תוכנה

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

באגים מההיסטוריה

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

המטרה היא להראות עד כמה ה- QA בכלל ובדיקות בפרט הן דבר קריטי וחשוב במיוחד כשמדובר במערכות אסטרטגיות שכשל בהן עלול לכל הפחות להביא לנזק כלכלי ובמקרה הגרוע לנזק גופני ו/או לאבידות בנפש.

מהיכן מתחילים לבדוק מוצר ?

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

קיצורים וביטויים מקצועיים

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

סט בדיקות

גם לאחר שהוחלט באיזו שיטה לבדוק את המוצר, עדיין קיימות קבוצות של בדיקות שיש לבחור מהן איזו לבצע.

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

שיטות שונות לבדיקה

לפני שניגש לתכנן את הבדיקות למוצר, יש לשאול את השאלות: כיצד המוצר בנוי, באיזה שלב של הפיתוח הוא נמצא ובאמצעות מה ניתן לבדוק אותו ? 

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

ככל שהמוצר סופי ובוגר יותר, כך סביר שהבדיקות של הטסטרים יהיו דומות לפעולות שיבצע ה- End User על המוצר וככל שהמוצר ראשוני יותר כך הבדיקות יהיו דומות יותר לפעולות שהמפתחים מבצעים על הקוד.

ניתן דוגמא כללית להמחשה.

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

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