
הטקסט המלא של הדקות הראשונות בהרצאה «באגים - Bugs» בקורס הווידאו של PracticU – כתוביות בעברית עם זמן התחלה לכל פסקה. כך תוכלו לקרוא ולחפש את הנושאים לפני שמתחילים ללמוד.
באגס אין ריפורטינג באגס בשיעור הזה אנחנו נדבר על נושא של באגים ועל דיווח נכון של באגים זה אחד הנושאים הכי כאובים בעולם הבדיקות ובאינטגרציה ובעבודה מול מפתחים חשוב מאוד שכשאנחנו מוצאים באג אנחנו נבין איך לכתוב אותו נכון על מנת שמתכנת יוכל להבין אותו ויוכל לעשות עם זה את הדברים שהוא צריך לעשות כדי לתקן אותו הדבר שהכי מבזבז זמן והכי שנוא
גם על מתכנתים וגם הרבה פעמים על בודקים זה שאתה כותב באג, מדווח אותו, אבל אתה לא מדווח אותו מספיק טוב ואז המתכנת בא אליך עם שאלות ושואל וזה מתחיל להיות איזשהו פינג פונג כזה והמתכנת אז הולך וטוען שאתה לא מבין את המערכת ואתה טוען שהמתכנת הוא לא מבין את המערכת וזה מתחיל להיות ריבים מיותרים שאפשר היה לחסוך אותם פשוט על ידי כתיבה נכונה ומסודרת של הבאג.
lesson objectives מטרות השיעור what is a bug נדבר מה זה באג Bugs exist because נדבר למה קורים באגים בכלל, מה גורם לבאגים. Reporting Bugs Correctly נדבר על איך לדווח באג בצורה נכונה.
Bugs Priority and Severity נדבר על תיעדוף של באגים ועל חומה של באגים. Bugs Life נתאר בתיאור סכמטי את אורך החיים, את מחזור החיים של באג. Maintaining the Bug Database נדבר על תחזוקה של דאטה בבסיס הנתונים שבו אנחנו מנהלים את רשימת הבאגים שמצאנו והסטטוס שלהם.
מהו באג? Unexpected behavior, the software does something and you don't think it is right. Users don't like bugs.
אז באג זה איזושהי התנהגות בלתי צפויה של המערכת. כלומר למרות שאנחנו יודעים שהמערכת צריכה לעשות א', ב', ג', היא פתאום עושה ד'. או שכשאתה מצפה שהמערכת תעשה משהו היא לא עושה אותו בכלל.
היא עפה, היא בכלל לא מבצעת אותו, הכפתור בכלל לא עובד, המסך שאמור להיפתח לא נפתח וכדומה. The software does something and you don't think it is right.
פה מגיעה היכולת שיקול של איש הבדיקות. כי הרבה פעמים המערכת יכול להיות שהיא עושה, אבל היא לא עושה את הדבר הכי נכון. ואתם, שאתם יושבים ורואים את המסמכים ומבינים את המערכת בכללותה ומבינים את הדרישות של הלקוח, יכולים לבוא ולהצביע איפה המקומות שבהם היא לא בדיוק עושה את מה שהיא אמורה לעשות.
שזה לאו דווקא תמיד חושבים שזה באג. ואחרי זה זה מגיע ללקוח והלקוח אומר שזה לא מה שהוא רצה. וכמובן אף אחד לא אוהב באגים, אף אחד לא אוהב שהתוכנה עפה לו באמצע העבודה שהיא נתקעת, שהיא מסורבלת מדי, שכואב לו הראש מלהסתכל על המסך במשך שתי דקות ועוד כאלה וכאלה סיבות.
Other names for bugs: Fault, Fail or Defect. יש עוד שלוש שמות שמשתמשים לבאגים אחד מהם זה Fault, Fail or Defect.
Implied series condition צריך לשים לב ש-Fault או פיילור או דיפקט המשמעות שלהם היא כמו באג אבל בקונטקסט באנגלית המשמעות שלהם היא הרבה יותר חמורה פיילור זה כישלון והמערכת נכשלת זה לא שיש לה באג דיפקט זה שיש לה מערכת פגם ולכן רצוי בדרך כלל תמיד להשתמש במונח באג ולא להיכנס לכל מיני מינוחים כמו פולט פיילור או דיפקט
שעלולים לגרום למישהו להיפגע או להיעלב או לא יודע מה באג זה כולם יודעים יש באג שהוא חמור באג שהוא פחות חמור באג שהוא לא חמור באג שהוא לא חמור בכלל אבל עדיין באג זה משהו שלא אמור להיות במערכת באג אקזמפלס דוגמאות לבאגים words misspelled spelling לא נכון של מילים כלומר שמות השדות לא מאויתים כמו שצריך קריאות כתיב משפט לא
נכון תחבירית וכדומה ignoring unexpected states שהגדירו את המערכת לא הגדירו מצבים או איך המערכת תתנהג במצבים בלתי צפויים. אז בא איש הבדיקות הכניס איזשהו תסריט שהוא לא צפוי, המערכת לא יודעת איך להתנהג וכתוצאה מכך או שלא קורה כלום או שקורה משהו שלא אמור לקרות.
Crash of an application, הבאגים הכי חמורים זה כאשר המערכת קורסת או מאבדת מידע. Bugs exist because, למה למעשה קיימים באגים?
Unfinished requirements, באגים קורים כשהדרישות לא גמורות, כלומר לא סגרו את מסמך הדרישות מכל הכיוונים ויש כל מיני פינות פתוחות או פינות שלא התייחסו אליהם ואז גם המתכנתים לא התייחסו אליהם כי המסמכים שהמתכנתים מסתכלים נגזרים ממסמך הדרישות וזה גורר שרשרת
של מסמכים לא גמורים עד שהתוצאה היא עבודה לא גמורה. Requirements with not enough details הרבה פעמים קורה שהלקוח כותב דרישות אבל הדרישות לא כתובות מספיק עם מספיק נתונים ואז כשלוקחים את מסמך דרישות ומתרגמים אותם למסמך איפיון מערכת, נכנס כל מיני השלמות של מי שכותב את המסמכים
או חוסר השלמות, לא הכל ברור ואז זה יוצר באגים או חוסר שלמויות במערכת. Requirements with multiple meanings באג דרישות שיש להם משמעות כפולה ואז המתכנת יכול להבין משמעות אחת, איש הבדיקות יבין משמעות אחרת.
הבאג הוא איפשהו ברמת הדרישה אבל כבר נכתבה המערכת ולכן צריך לתקן את כל התהליך. Logic errors in the design documents כל מיני טעויות לוגיות של טעויות לוגיות עסקיות שנכתבו במהלך מסמך האפיון והמתכנתים אחר כך יושבים ובונים לפי את התוכנה לפי מסמך האפיון הם עושים הם בונים את הטעות הם
מבחינתם לא אמורים לדעת שזה טעות כי מסמך האפיון אמר להם שזה מה שצריך להיות והאיש הבדיקות אמור לעלות או עולה על זה שזה בא כי הוא משווה את המסמך הזה בסופו של דבר לדרישות העסקיות של התוכנה code errors טעויות בקוד תוכנה שלא מתקמפלת ועוד כהנה וכהנה testing not sufficient enough הבדיקות לא מספיקות זאת אומרת כתבתם את הבדיקות אבל לא כתבו אותה
מספיק לא היה מספיק זמן לכתוב את כל התסריטי בדיקות הרלוונטיים לא השתמשתם בכל מיני שיטות לצמצום הבדיקות ועל מנת לעדיין למצוא מקסימום באגים גורם לזה שבסופו של דבר יש באגים במערכת למה כי זה באגים שלא הספקתם לגלות אותם שאם היו נותנים לכם עוד זמן הייתם יכולים להריץ את התסריט הזה
שכבר כתבתם אותו ולמצוא את הבאג הזה. או באגים שקרו כי אי אפשר לחשוב על הכל. Misunderstude of the user needs. באגים שהם כתוצאה מזה שלא הבנו מה הלקוח רוצה.
פשוט לא הבנו. למרות שהוא כתב, למרות שהוא הגדיר, למרות שהתדיינו, לא הבנו את מה שהוא רוצה. והסיבה הנוספת, Lake of Documentation, מחסור במסמכים.
אין מסמך דרישות, המסמך אפיון לא מעודכן, ה-STD לא מעודכן, ועוד כהנה וכהנה ריפורטינג באגס קורקטלי דיווח נכון של באגים איך איך מדווחים נכון באג קודם כל search the bug in the bug tracking