‫טכניקת בדיקה – הינה מתכון‪ ,‬או‬ ‫מדדים שניתן לקבל באופן אוטומטי מ ‪LDRA‬‬ ‫‪FP - Function points‬‬ ‫מה

RA‬‬ ‫‪FP - Function points‬‬ ‫מה ניתן להבין כאשר מסתכלים על הקוד‬ ‫‪1‬המפץ הגדול‪-‬קודד ככל רכיב בנפרד‪,‬צרף הכל והרץ‬ ‫מחזור החיים של פיתוח התוכנה‬
‫מודל שמדריך אותנו בתהליך יצירת‬ ‫המושג הומצא על מנת לאפשר לארגון לזהות את מימדי התוכנה‬ ‫מספר שורות‪,‬מספר ההתפצלויות‪,‬מספר אובייקטים‪,‬מספר‬ ‫חוזקות‪ :‬פשוט להבנה‪ ,‬לא דורש תכנון‬
‫‪Static and Complexity Analysis Summary‬‬ ‫*ההיבט הניהולי ‪ - Governance‬מטרת ההיבט להבטיח שהתוכנה תספק צרכי‬
‫מקרי הבדיקה מיוחדים‪ ,‬להלן רשימה‬ ‫מחלקות‪,‬אובייקטים כלולים בכל קלאס מוצהר‪,‬משתנים במחלקות‪ .‬עליו לפתח במונחים של תפקוד ולא במונחים של שורות קוד (כי‬ ‫חולשות‪ :‬קשה לדיבוג‪ ,‬מקטין ערך של רכיבים חשובים‬
‫‪o Programming Standards Checking‬‬ ‫‪Water fall )2‬מפל המים‬ ‫הארגון שאליו נועדה הוכנה‪ .‬מתפרש לאורך כל מחזור החיים שלהתוכנה‪.‬‬
‫חלקית של טכניקות מוכרות‪:‬‬ ‫סיבוכיות‪ Looping depth,Reachability,Cyclomatic complexity ,:‬הרי זה יכול להיות שונה בכל שפה וטכנולוגיה (המימדים הנספרים‬ ‫*ההיבט הפיתוחי ‪ Development -‬ההיבט אחראי על פיתוח התוכנה‪ ,‬זה מתחיל‬
‫‪*Function testing‬‬
‫‪o Macro Expansion‬‬ ‫מתאים לסטנדרט‪,‬מובנה ‪,‬מכסה‪,‬תיעוד פנימי‬ ‫‪Requirement->design->code->Unit test->Integration test-‬‬
‫ומשקלם מייצגים גדלים ידועים לארגון אשר כבר בוצעו בעבר וניתן‬ ‫קצת אחרי הגאית הרעיון וממשיך בתחזוקה של התוכנה גם אחרי כניסתה‬
‫‪*Specification based testing‬‬
‫‪o Complexity Metrics‬‬ ‫‪>System test‬‬
‫לכמת את העבודה שהושקעה בהם בעבר‬ ‫מבנים בסיסים בתוכנה ‪Software primitives‬‬ ‫לשימוש‪ ,‬גרסאות חדשות‪ ,‬עדכונים‪.‬‬
‫‪*Domain testing‬‬ ‫‪o Structured Programming Verification‬‬ ‫תמיד בסדר הזה‪ ,‬מינימום חפיפה‪,‬אין דרך חזרה‬
‫תהליך צימצום – איתור יחידות פנימיות (פרימיטיבות) ‪ ,‬ייצוגן כאובייקט‬ ‫*ההיבט התפקודי ‪ Operations -‬ל יישום פעיל חייב להיות נתון לניטור ולניהול‪.‬‬
‫‪*Risk based testing‬‬ ‫‪o Static Flowgraph‬‬ ‫יותר מאוחר נממש תהליך בדיקה מהפנים החוצה וכך נכסה את הקוד‬
‫חוזקות‪ :‬ברור‪,‬ניתן להתאמן עמו‪,‬עונה על שלבי עבודה הכרחיים‬
‫היבט זה מתחיל קצת לפני שלב ה ‪ Deployment‬ומתפרש עד שלב המוות‪.‬‬
‫‪Scenario testing‬‬ ‫‪o Callgraph‬‬ ‫ללא מעבר הכרחי בכל הענפים‪.‬‬ ‫חולשות ‪:‬לא ניתן למימוש‪,‬מייאש בתהליך העבודה‬
‫‪( )3‬מפל המים עם ראיית איכות ) מודל ‪V‬‬ ‫הצד הפרקטי בתהליך חיי פרויקט התוכנה‬
‫‪*User testing‬‬ ‫‪Static Data Flow Analysis‬‬ ‫*פרק הקונספט – מגבלות‪ ,‬סיכונים‪ ,‬משתמשים‪ ,‬רשימת מכולת‬
‫‪*Data flow testing‬‬ ‫יתרונות‪:‬מכיל את כל השלבים‪,‬הדגמה טובה של הקשר בין פיתוח‬
‫‪The Data Flow Analyser produces four‬‬ ‫*פרק הדרישות – פרק המה מסמך דרישות (רשימת תוצרי הפרק‬
‫‪*Regression Testing‬‬ ‫לבדיקה‪ ,‬נוח לאימונים‬
‫‪types of information about the source file‬‬ ‫*פרק תכנון‪/‬עיצוב ‪ -‬פרק האיך (כולל ‪ (DFD‬נעשה בד"כ בשני שלבים או יותר – חסרונות‪:‬לא מציג עבודה חוזרת‪,‬פחות מוכר‬
‫‪*Device capability testing‬‬ ‫‪or system.‬‬ ‫חלק גדול מהקורס יוקדש לנושא‪.‬‬
‫‪ )4‬מודל הספיראלה בפיתוח תוכנה ‪( -‬איטרציה מעגלית )‬
‫‪*Testing to maximize statement‬‬ ‫‪o Procedure Call Information‬‬ ‫*פרק הקידוד – נעסוק רק באיך עושים את זה יותר טוב‪/‬נקי משגיאות‬
‫הספיראלה הוא מודל אב טיפוס מתפתח‬
‫‪and brunch coverage testing‬‬ ‫‪o Data Flow Anomalies‬‬ ‫*בדיקות בפיתוח ‪ -‬או ביידיש ‪ Unit test‬מי שמתחמק אומר יעשו זאת המפתחים יתרונות‪:‬מזהה קשיים‪,‬מציג עבודה חוזרת בהתחלה‪,‬עונה על צרכי ‪v(G) = e -n + p : Cyclomatic Complexity‬‬
‫‪*All pair combination testing‬‬ ‫‪o Procedure Parameter Analysis‬‬ ‫שלבי עבודה‬ ‫*אינטגרציה – הפרק הנעלם שלוקח חלק ענק מהמאמצים‬
‫‪*Stress testing‬‬ ‫‪o Global Variable Analysis‬‬ ‫חסרונות‪:‬לא מייצג את כל המצבים‪,‬לא מזהה עבודה חוזרת בזמן‬ ‫*בדיקות מערכת – מה שהארגון עושה על מנת שיוכל למכור את התוכנה‬
‫‪*High volume testing‬‬ ‫‪v=4‬‬ ‫‪v=3‬‬ ‫‪v=2‬‬ ‫‪v=1‬‬
‫‪RUP - Rational Unified Process ) 5‬‬ ‫*בדיקות קבלה – מה שהלקוח עושה על מנת לקנות את התוכנה‬
‫‪*State model based testing‬‬ ‫אנליזה דינמית כדאי לזכור‪ :‬אינסטרומנטציה– הרצה‪-‬ניתוח תוצאות‪.‬לצורך בדיקות דינמיות יש לבצע אינסטרומנטציה בקוד‬
‫במקום לעשות כל דבר בשלמותו בנפרד‪,‬הצוותים עושים קצת מכל‬ ‫*התקנה אצל לקוח – מה שהארגון והלקוח עושים בשביל לממש‬
‫טכניקות בדיקה – ההקשר הכולל‬ ‫בדיקות יחידה – ‪Unit Test‬‬ ‫דבר כל הזמן‬ ‫*תחזוקה ועדכונים – על זה עושים את הכסף‪.‬‬
‫בדיקות ברמת יחידת המערכת הקטנה ביותר ( מודול ) שמאמתות את פעילותה התקינה של‬ ‫‪ Agile - SCRUM) 6 1) Structured programming- programming paradigm aimed on improving‬מודל חיים מואץ‬
‫היחידה‪ .‬הבדיקות נערכות לרוב לאחר הכנת המודול או לאחר שבוצעו בו שינויים‪ ,‬אך קיימות גם‬ ‫‪* the clarity, quality, and development time of a computer program by‬סקראם מאפשר לנו בזריזות ובמחזוריות לבחון את התוכנה‬
‫שיטות בהן מורצות בדיקות יחידה בטרם הכנת המודול‪ .‬הרעיון הוא ליצור קבוצה של בדיקות‪ ,‬אשר‬ ‫‪ making extensive use of subroutines, block structures and for and while‬במצב עובד (כל שבועיים עד חודש)‬
‫תכסה את כל פעילות המודול‪ ,‬והצלחתה תוכיח בוודאות סבירה כי המודול תקין‪.‬‬ ‫‪* loops—in contrast to using simple tests and jumps such as‬הגוף העסקי מספק סדרי עדיפויות‪ .‬הצוותים מנהלים את עצמם‬
‫מתקרבים לקוד יתרונות של – ‪Unit Test‬‬ ‫‪CFG‬‬ ‫‪CFG‬‬ ‫‪ the goto statement which could lead to "spaghetti code" which is both‬על מנת להבין כיצד לספק בצורה הטובה ביותר את הדרישות‬
‫‪*A unit test is code that exercises a specific‬‬ ‫)‪if (x < y‬‬ ‫‪ difficult to follow and to maintain.‬בעלות העדיפות הגבוהה ביותר‬
‫‪x=0‬‬ ‫‪1‬‬
‫;‪x = 0‬‬ ‫{‬ ‫‪* 2)Procedural programing - Procedural programming can sometimes be‬קבוצת העבודה בסקראם מכילה מפתחים ‪ ,‬בודקים ובעלי מקצוע‬
‫‪portion of your codebase in a particular context.‬‬ ‫‪1‬‬
‫‪dummy node‬‬
‫)‪while (x < y‬‬ ‫;‪y = 0‬‬ ‫‪ used as a synonym for imperative programming (specifying the steps the‬אחרים ומנוהלת עצמאית באחריות משותפת‬
‫‪Unit tests prove that the code you are testing‬‬ ‫{‬
‫‪x<y‬‬ ‫‪x >= y‬‬ ‫;‪x = x + 1‬‬
‫‪2‬‬
‫‪y=0‬‬ ‫}‬ ‫‪* program must take to reach the desired state), but can also refer to‬בכל שבועיים עד חודש כל אחד יכול לראות תוכנה עובדת‬
‫‪does in fact do what you expect it to do.‬‬ ‫;)‪y = f (x, y‬‬ ‫‪x=x+1 2‬‬ ‫‪3 x=y‬‬
‫‪x<y‬‬ ‫‪x >= y‬‬
‫‪else‬‬ ‫ולהחליט לשחרר אותה או להמשיך לשפר אותה ספרינט נוסף‬
‫‪*One of the most valuable benefits of unit tests‬‬ ‫‪3‬‬ ‫‪4‬‬ ‫;‪x = x + 1‬‬ ‫{‬ ‫‪a programming paradigm, derived from structured programming, based‬‬
‫*אורך קבוע מסייע לקבלת קצב טוב יותר‪.‬‬
‫שימוש בטבלאות החלטה‬ ‫‪is that they give you confidence that your code‬‬ ‫)‪y =f(x,y‬‬ ‫;‪x = y‬‬ ‫‪upon the concept of the procedure call. Procedures, also known as‬‬
‫‪x=x+1‬‬
‫}‬ ‫‪4‬‬ ‫}‬ ‫*במהלך הספרינט המוצר עובר את כל שלבי הפיתוח‪ :‬עיצוב‪,‬‬
‫‪works as you expect it to work‬‬ ‫‪routines, subroutines, methods, or simply contain a series of‬‬
‫קידוד ובדיקות‬
‫‪C1‬‬ ‫‪rate < 30‬‬ ‫‪Y‬‬ ‫‪Y‬‬ ‫‪N‬‬ ‫‪N‬‬ ‫‪*Unit tests also save you time because unit tests‬‬ ‫‪computational steps to be carried out. Any given procedure might be‬‬
‫‪C2‬‬ ‫‪Hour <= 40‬‬ ‫‪Y‬‬ ‫‪N‬‬ ‫‪Y‬‬ ‫‪N‬‬
‫‪x=0‬‬ ‫‪1‬‬
‫‪1‬‬
‫)‪if (x < y‬‬ ‫‪ Project life cycle– W) 7‬מודל ה‬
‫‪help prevent regressions from being introduced‬‬ ‫‪called at any point during a program's execution, including by other‬‬
‫)‪for (x = 0; x < y; x++‬‬ ‫‪x<y‬‬ ‫{‬
‫‪and released. Once a bug is found, you can write‬‬ ‫‪2‬‬ ‫‪procedures or itself. Procedural programming is a list or set of instructions‬‬
‫‪A1‬‬ ‫‪Pay = Stright time‬‬ ‫‪X‬‬ ‫עמודה‬
‫‪a unit test for it, you can fix the bug, and the bug‬‬
‫‪x<y‬‬ ‫‪x >= y‬‬ ‫{‬ ‫‪y=0‬‬ ‫‪x >= y‬‬ ‫;‪y = 0‬‬ ‫‪telling a computer what to do step by step and how to perform from the‬‬
‫‪A2‬‬ ‫‪Pay = Over time‬‬ ‫‪X‬‬ ‫המגדירה‬ ‫)‪y = f (x, y‬‬ ‫‪3‬‬ ‫‪5‬‬ ‫‪x + 1 28,0 , 9,0‬‬
‫‪x =correct:‬‬
‫‪A3‬‬ ‫‪Pay = Professional‬‬ ‫‪X‬‬ ‫‪X‬‬ ‫התנהגות‬ ‫‪can never make it to production again because‬‬ ‫;)‪y = f (x, y‬‬ ‫;‪x = x + 1‬‬ ‫‪first code to the second code. Procedural programming languages‬‬
‫‪the unit tests will catch it in the future.‬‬ ‫‪4‬‬ ‫‪x=x+1‬‬ ‫}‬ ‫‪3‬‬ ‫}‬ ‫‪include C, C++, Fortran, Pascal, and BASIC.‬‬
‫שורה‬
‫המגדירה‬
‫‪*Another advantage is that unit tests provide‬‬ ‫‪ software life cycle‬תהליך חיי פרויקט התוכנה‬
‫אופן חישוב‬ ‫‪excellent implicit documentation because they‬‬ ‫;‪x = 0‬‬ ‫)‪if (x < y‬‬
‫‪1‬‬ ‫‪0=x‬‬ ‫‪do‬‬ ‫‪1‬‬
‫‪show exactly how the code is designed to be‬‬ ‫{‬ ‫{‬
‫‪x<y‬‬
‫‪used.‬‬ ‫;)‪y = f (x, y‬‬
‫‪x >= y‬‬
‫;‪return‬‬
‫‪)y ,x( f = y‬‬ ‫;‪x = x + 1‬‬ ‫‪return‬‬ ‫‪2‬‬
‫‪1 +x = x‬‬
‫‪2‬‬ ‫}‬
‫}‬
‫בדיקת יחידה תכיל‪:‬‬ ‫‪y => x‬‬ ‫;)‪while (x < y‬‬ ‫;)‪print (x‬‬
‫‪y<x‬‬
‫הכנת טבלת מקרי בדיקה ספציפיים המתארת מהלך בדיקה‬ ‫הכנת כל התנאים להרצת היחידה‪.‬‬ ‫)‪println (y‬‬ ‫‪3‬‬ ‫)‪print (x‬‬
‫‪3‬‬ ‫‪return‬‬ ‫;‪return‬‬
‫נתוני סימולציה‬ ‫תוצאות מצופות‬ ‫קריאה והפעלה ליחידה הנבדקת‬
‫מהלך‬ ‫שעות‬ ‫תעריף‬ ‫שכר מחושב‬
‫בדיקה ואימות שאכן הצליחה הפעלת היחידה‬
‫נקויי שטחי העבודה והכנת האזור להרצה חוזרת‬ ‫‪Seven Testing Principles‬‬ ‫‪TDD – ?What is TDD‬זה שיטה שבה קודם כל רושמים את ( ‪ test cases‬מקרי בדיקה) לפני‬
‫* ‪Testing shows presence of defects‬‬ ‫שממשים את הקוד‪ .‬הבדיקות מכתיבות את הקוד שמפתחים‪ .‬הכוונה‪:‬‬
‫מאפיינים עיקריים לסוגי הבדיקות‬
‫בדיקות מראות את מצב המערכת ואת נוכחותם של התקלות והבאגים‪:‬‬ ‫הבדיקות מספקים ספציפיקציה עבור מה קטע קוד מסוים אמור לעשות‪.‬‬
‫* בדיקות פונקציונאליות‪:‬בדוק כל תפקוד ופונקציה לחוד‪.‬‬
‫חשוב להבין‪ ,‬שהבדיקות אינן מעלות את רמת המערכת‪ ,‬אלא הן מראות‬ ‫חלק יכולים להתווכח עם האמירה "בדיקות הם חלק ממסמכי האפיון"‪.‬‬
‫כיצד להשתמש בטכניקת בדיקות על מנת לייצר ‪TEST Cases‬‬ ‫במספר‬ ‫תפקוד‬ ‫או‬ ‫תכונה‬ ‫כל‬ ‫וכסה‬ ‫‪,‬‬‫המוצר‬ ‫את‬ ‫סרוק‬
‫‪TDD Stages‬כתוב בדיקה אחת‪>- .‬תקמפל את הבדיקה‪ .‬אומנם זה לא אמור להתקמפל כי עדיין לא את הנוכחות של התקלות ואת הימצאותן‪ .‬כתוצאה מכך התקלות והבאגים‬
‫נתח את המצב‪,‬מדל את מרחב הבדיקות‪,‬בחר מה לכסות‪,‬קבע‬ ‫מספק של בדיקות על מנת לוודא מה הוא עושה והאם‬
‫נרשם המימוש של הקוד‪>- .‬תממש רק מעט קוד על מנת שהבדיקה תעבוד‪>- .‬תריץ את הבדיקה מתוקנים על ידי המפתחים ואיכות המערכת עולה‪.‬‬
‫את האורקל של הבדיקות‪,‬התקן את המערכת לבדיקה‪,‬הפעלת את‬ ‫כראוי‬ ‫עובד‬ ‫הוא‬
‫כמו כן עצם ביצוע הבדיקות מקטין את הסיכויים לכך שיש תקלות במערכת‬ ‫ותראה שהיא נכשלת‪( .‬אדום) ‪>-‬תפתח עוד קצת קוד על מנת שהבדיקה תעבור‪>- .‬תריץ את‬
‫מערך הבדיקות‪,‬בחן את התוצאות‪,‬הערך ושפוט את תוצאות‬ ‫* בדיקות מונחות ספציפיקציות‪ :‬בדוק כל אמירה‬
‫שלא נמצאו‪ .‬עם זאת‪ ,‬בדיקות לעולם אינן יכולות להוכיח כי אין תקלות‬ ‫הבדיקה שוב ותראה שהיא עוברת‪( .‬ירוק ‪>-‬תביא מחדש בחשבון את כל הכללים )‪ (refactor‬על‬
‫במערכת‪ ,‬מה שהן כן יכולות זה להוכיח כי בחלק הנבדק יש או אין תקלות המופיעה במסמכים המלווים את הפרויקט (כמו חוזים ההרצה‬
‫ומפרטים ) בדוק עד לרמה שהוכחת שכל הנאמר מולא‬ ‫מנת לבהר פעם אחת בלבד‪>- .‬חזור על השלבים‪.‬‬ ‫הגדרת הפרויקט‪:‬‬
‫עד למדרגה מסוימת בדיקה טובה יהיו לה התכונות הבאות‬ ‫בהתאם לבדיקות שנעשו‪ .‬יותר מזאת‪ ,‬אי מציאתן של תקלות אינה מעידה‬
‫ועובד כמובטח‬ ‫‪?Why TDD‬מתכנתים לא אוהבים קוד‪ .‬בדיקות נחשב לעבודה משעממת‪ .‬בדיקות בדר"כ נחשב‬ ‫משימה חד פעמית שיש לבצעה במסגרת לוח זמנים ותקציב מוגדרים‪.‬‬
‫עוצמה – כאשר הבעיה קיימת הבדיקה תחשוף אותה‬ ‫על מערכת מושלמת ועל כך שאין במערכת תקלות‬
‫* בדיקת אזורי תפקוד ויחידות‪ :‬תתמקד במשתנים כמו‬ ‫לעבודה של מחלקה אחרת או אדם אחר‪ TDD.‬מעודדת מתכנתים לשמור על סדרה מקיפה של‬ ‫משימה מוגדרת ומורכבת‪ ,‬הניתנת לביצוע בצורה מתוכננת ושיטתית‪.‬‬
‫נכונות ‪ -‬כאשר חושפת הבדיקה בעיה היא אכן בעיה אמיתית‬ ‫* ‪Exhaustive testing is impossible‬‬
‫( ‪ ) input, outputs, configuration or internal‬עבור כל‬ ‫בדיקות חוזרות‪ .‬ניתן להריץ את הבדיקות אחרי כל שינוי‪ .‬בדיקות הם חלק מהתכנות‪.‬‬ ‫אוסף מסודר של פעולות בעלות תלות הדדית‪ ,‬אשר השלמתן המוצלח תביא‬
‫ערך – חושף משהו שהלקוח היה רוצה לדעת על התוכנה או‬ ‫לא ניתן לבצע את כל הבדיקות והמקרים האפשריים‪.‬‬
‫משתנה שכזה או קומבינציה של כאלה בחן את מרחב‬ ‫יתרונות – כתיבת הקוד היא יותר איכותית‪ ,‬ישנה התחשבות רבה בדרישות הפונקציה‪ .‬חוסכת זמן‬ ‫להשגת יעדים ומטרות מוגדרים מראש‪.‬‬
‫המוצר‬ ‫תחשבו על מצב בו אתם רוצים לבדוק שדה אשר מקבל ערכים בין ‪ 0‬ל ‪-‬‬
‫האפשרויות של הערכים‪ .‬פשט את זה על ידי חלוקי‬ ‫‪ – Project Definition‬משולש אשר בקצוותיו ‪ scope,cost,time :‬ובאמצע ‪ quality‬תיקון‬
‫אמינות – הלקוח יחשוב שאכן סביר שהשימוש בתוכנה יהיה כמו‬ ‫‪ 100‬כמה בדיקות תעשו? אני לא מצפה לתשובה‪ ,‬אני רק מקווה שאתם‬
‫לתתי קבוצות‪ ,‬בחר מאפיינים לכל אחת מהקבוצות‪ .‬והרץ‬ ‫תכונות של פרויקט ‪ -‬מטרה מוגדרת היטב‪ ,‬משימה חד פעמית (לא שגרתית ולא חסרונות – נחשבת למיותרת כי גם ככה ‪ ,‬לאחר שלב הקידוד מגיע שלב הבדיקות‪ ,‬ושוב נבדקים‬
‫שבדקת אותו‬ ‫לא באמת חושבים שתנסו את כל האפשרויות בין ‪ 0‬ל ‪ ,100-‬בעצם גם את‬
‫בדיקות בהתאם‪.‬‬ ‫אותם דברים‪ .‬לוקחת זמן‬ ‫מחזורית‪ ,).‬משך זמן לסיום מוגדר ‪ ,‬משאבים מוגבלים ומתוקצבים (כסף וכוח‬
‫ייצוגי – הארוע או התהליך סביר שיתבצע בזמן השימוש בתוכנה‬ ‫אלו שלא בתחום‪ ...‬ביצוע כלל המקרים אינו אפשרי‪ ,‬יש המון מקרים ואי‬ ‫‪Colorful testing‬‬
‫* בדיקות מונחות סיכון‪ :‬כל תוכנית היא אוסף‬ ‫אדם‪ ,).‬פעולות מתוכננות מראש‪ .‬תוצאות ניתנות לאומדן במונחי כסף וזמן‪.‬‬
‫מאפיין – הבדיקה המסוימת מאפיינת קבוצת בדיקות גדולה‬ ‫אפשר לכסות את כולם‪.‬‬
‫ההזדמנויות של דברים שיכולים להתקלקל‪ .‬עבור כל‬ ‫‪ 5‬השלבים לפרויקט‪:‬‬
‫שמטפלת בסיכון המסוים‬ ‫* ‪Early testing‬‬
‫הזדמנות שאתה מסוגל לדמיין לנפילה שכזאת עצב‬ ‫‪---‬שלב הייזום והתנעה ‪ Initiate -‬השלב שבו נולד הפרויקט‪ ,‬מדובר על שלב שבו‬
‫מניע – הלקוח שלך אכן ירצה לתקן את הבעיה שנחשפה בבדיקה‬ ‫מציאת תקלות מוקדם‬
‫בדיקה שבוחנת עד כמה באמת התוכנית מפשלת‬ ‫עולה הרעיון לפרויקט‪.‬‬
‫זאת‬ ‫צריך להתחיל למצא באגים מוקדם ככל האפשר במהלך פיתוח התוכנה‬
‫בנקודה זאת‬ ‫‪---‬שלב התכנון ‪ Plan -‬זהו השלב המהותי ביותר בפרויקט‪ ,‬הצלחה בתכנון תוביל‬
‫אפשרי לביצוע – ניתן לבצע את מה שמתוכנן‬ ‫וצריך להתמקד על אובייקטים ידועים ומוגדרים‪ .‬ככל שנמצא באג מוקדם‬
‫* בדיקות תסריטים‪ :‬הבדיקות הינן סיפור מורכב שתופס‬ ‫לסיכוי רב לעמידה ביעדי הפרויקט‪ ,‬שביעות רצון המזמין‪ ,‬עמידה בלוחות‬
‫תחזוקתי – קל ונוח לתחזק נוכח השנוי בתוכנה‬ ‫יותר‪ ,‬כך העלות תיהיה נמוכה יותר‪.‬‬
‫כיצד התוכנית צריכה להתנהג במצב חיים אמיתי‪ .‬אלו‬ ‫הזמנים‪ ,‬עמידה באיכות ועוד‪.‬‬
‫ניתן לחזרה – זה קל ולא יקר להריץ מחדש את תהליך הבדיקה‬ ‫‪Defect clustering‬‬
‫הן קבוצות קומבינציה של בדיקות המייצגות באופן‬
‫חושפני – יחשוף מידע הנוגע להנחות יסוד וקריטיות‬ ‫התאגדות של תקלות במקום ספציפי‪.‬‬ ‫‪---‬שלב הביצוע ‪ Execute -‬השלב היקר ביותר בפרויקט‪ ,‬שלב זה כולל הפעלת‬
‫מכובד את השימוש האמיתי‬
‫מכסה – מריץ את המוצר באופן שעדיין לא הורץ תוך כדי הפעלת‬ ‫עקרון זה בא ואומר כי התקלות בדרך כלל יתקבצו ויתאגדו באותו חלק של‬ ‫אנשים ומשאבים שונים לפי תוכניות העבודה שנקבעו‪.‬‬
‫* בדיקות רגרסיה‪ :‬חזור על אותן הבדיקות לאחר כל שנוי‬
‫אזורים שעדין לא נבדקו ואוששו‬ ‫הקוד‪ .‬כלומר‪ ,‬אם יש חלק במערכת בה נמצאו מספר תקלות‪ ,‬כנראה שיש‬ ‫‪---‬שלב הבקרה ‪Control -‬שלב זה מספק איזון חוזר לאינטגרציה של כלל‬
‫בתוכנית‪ .‬ניתן להשתמש בכל טסט לרגרסיה בתנאי‬
‫קל ונוח להערכה‬ ‫שם עוד תקלות שלא נמצאו‪ ,‬ולעומת זאת חלקים אחרים במערכת יעבדו‬ ‫החלקים‪ ,‬לווידוא שהתכולה הושלמה ובאיכות הנדרשת‪ .‬הבקרה על הלו"ז‪,‬‬
‫שאכן התוכנית תיבדק מחדש‪ .‬כאשר נשתמש ברגרסיה‬
‫תומך באיתור תקלות – מספק מידע שימושי לתהליך איתור‬ ‫בצורה מושלמת ללא כל תקלה‪.‬‬ ‫עלויות‪ ,‬ניהול משאבים וכוח ‪-‬אדם‪ ,‬דיווחים לבעלי העניין‪.‬‬
‫באופן מסיבי – עלינו ללמוד לתכנן בדיקות יעילות מאוד‬
‫השגיאה‬ ‫*‪Pesticide paradox‬‬ ‫‪---‬שלב הסגירה ‪ - Closing‬השלב האחרון בפרויקט והסופי‪ .‬השלב הזה כולל את בואו נבנה ביחד תרשים זרימה לטיפול בשגויים (‪) 1‬‬
‫לצורך החזרות הללו‪.‬‬
‫מסובך במידה הנכונה ‪ -‬כאשר מתייצבת התוכנה ניתן להוסיף‬ ‫שינוי הבדיקות לעיתים תכופות‪.‬‬ ‫מה חסר לפני שמתחילים?‬ ‫סיום הפרויקט וסגירת החוזים המשפטיים הרלוונטיים‪.‬‬
‫* בדיקות לחץ‪ :‬יכולות להיות מספר הגדרות לבדיקות‬
‫סיבוכיות ומורכבות לבדיקה וכך לייצג את חווית המשתמש‬ ‫דרגת החומרה של השגיאה‪ ,‬מידת הדחיפות לטיפול ‪ ,‬סטאטוס לשגיאות – מה המצב בכל רגע נתון בשפה המקצועית עקרון זה נקרא גם עקרון ההדברה ( ‪pesticide‬‬ ‫ניהול הפרויקט ‪ -‬עמידה בלוחות זמנים‪ .‬טיב העבודה‪ .‬העלות הסופית‪.‬‬
‫הלחץ‪ ,‬כאשר אנו אומרים לחץ משמעו להציף את‬
‫מוצדק – אתה יכול להסביר להצדיק ולהוכיח באמצעות הריצה‬ ‫‪ ,‬מי מורשה לעשות מה‬
‫‪ )paradox‬עקרון זה אומר כי אם במשך זמן רב לא נעדכן ולא נחליף את התוכנה למשל בכמות וקצב מידע נכנס‪ ,‬קומבינציות‬ ‫גורמי הצלחה קריטיים לפרויקט ‪ -‬בהירות מטרת הפרויקט!!! – מפרט דרישות‬
‫מחיר – כולל זמן‪,‬מאמץ בנוסף לעלות ישירה‬ ‫הבדיקות אותן אנו מבצעים‪ ,‬בסופו של דבר לא נמצא תקלות ובאגים‬ ‫‪status‬‬ ‫ברור‪ .‬תכנון הפרויקט ‪ .‬מעורבות המזמין בתהליך ביצוע הפרויקט‪ .‬טיב הביצוע‪.‬‬
‫כאלה שאנו מעריכים יפילו את התוכנית תוך כדי בחינה‬
‫חוסך הוצאות אחרות – קיום הבדיקה תמנע הוצאות ועבודה‬ ‫חדשים‪ .‬ולכן חשוב כל הזמן לשנות את הבדיקות‪ ,‬את הערכים‪ ,‬את‬ ‫‪ne‬‬ ‫‪new‬‬ ‫עקרונות תכנון וניהול הפרויקט ‪ -‬חלוקת הפרויקט לנושאי עבודה עיקריים‪ .‬חלוקת‬
‫כיצד היא מנהגת בזמן ואחרי הנפילה‪.‬‬
‫נוספת‬ ‫התסריטים ולעדכן באופן רציף וקבוע לאורך כל מחזור חיי המוצר‪.‬‬ ‫נושאי העבודה לפעילויות‪ .‬הערכת דרישות המשאבים (כ"א כסף‪ . ).‬תכנון הזמנים‬
‫* בדיקות משתמשים‪ :‬מסור את התוכנית ל"משתמש"‬ ‫‪on‬‬ ‫‪On hold‬‬
‫אסטרטגיה בסיסית אפשרית ליישום בדיקות‬ ‫* ‪Testing is context dependent‬‬ ‫‪U‬‬ ‫‪Urgent‬‬
‫של הפעילויות והמשאבים‪ .‬בחירת צוות הביצוע ( אתם או משאבים חיצוניים‪.).‬‬
‫וצפה מה הוא עושה ומהן התגובות לפעולותיו‪ .‬בדיקות‬ ‫‪fi‬‬ ‫‪Fixed‬‬
‫‪)1‬התחל במובן מאליו ובבדיקות הפשוטות – בדוק את התוכנה‬ ‫בדיקות נעשות בהקשר ספציפי ‪.‬‬ ‫‪I‬‬ ‫‪Immediate‬‬
‫משתמש יכולות להיות מובנות ונוקשות או חופשיות‬ ‫‪re‬‬ ‫‪Retest‬‬ ‫תיעוד התקדמות העבודה ‪ .‬חיזוי תקלות אפשריות‪.‬‬
‫בערכים שאמורים לעבור בצורה פשוטה ויחשבו כשגיאה חמורה‬
‫המערכות הן שונות האחת מהשנייה ולכן הבדיקות יעשו בדרכים שונות‪ .‬כאשר הדגש הוא הפעלת התוכנה והתגובות כ‬ ‫‪can‬‬ ‫‪Cancel‬‬ ‫‪S‬‬ ‫‪Soon‬‬ ‫מבנים אירגוניים‬
‫באם התוכנית תכשל‬
‫יש תמיד לייחס ולמפות את ההקשר לבדיקות ‪ -‬הדבר החשוב ביותר הוא "משתמש"‬ ‫‪Hierarchical Organization )1‬‬
‫‪)2‬בדוק כל פונקציה באופן אוהד ולמד מה שימוש שלה לפני‬ ‫להבין מה צורך המערכת וקביעת קריטריונים‪ .‬אחרי שאלו נקבעו ניתן‬
‫‪cl‬‬ ‫‪Closed‬‬ ‫‪N‬‬ ‫‪No rush‬‬
‫* בדיקות ממוכנות בנפח גבוה‪ :‬תכנת והתקן את‬
‫שתבקר אותה‪.‬‬ ‫לרשום את הבדיקות תוך התבססות על הקריטריונים וצרכי המערכת‪.‬‬ ‫‪Information Flow‬‬
‫המחשב באופן שיורצו מספר גדול ומסיבי של בדיקות‪.‬‬
‫תוך כדי אספקת אורקל (ידע לוגי ה"מבין" את התוצאה)‪)3 .‬בדוק בדיקה שטחית כוללת לפני שתעמיק ותמקד‬ ‫*‪Absence-of-errors fallacy‬‬
‫‪Control Flow‬‬ ‫‪Chief Executive‬‬
‫‪)4‬חפש מבחנים יותר חזקים‪ .‬נסה תנאי קיצון ‪boundary‬‬ ‫ובחן את תצורת תוצרי ההרצות‪.‬‬ ‫לא קיים מצב שאין תקלות‪.‬‬ ‫‪x‬‬ ‫‪x‬‬ ‫בודק‬
‫‪conditions‬לאחר שהתוכנית שרדה את הבדיקות הפשוטות עליך‬ ‫נקודת המוצא היא כי אין מערכת מושלמת שאין בה תקלות‪ .‬כמובן‬ ‫‪First‬‬ ‫‪Level Manager‬‬
‫* בדיקות מונחות מודל ומצבים‪ :‬על ידי מידול בתוכנית‬ ‫‪x‬‬ ‫‪x‬‬ ‫‪x‬‬ ‫‪x‬‬ ‫ר צ‬
‫)”‪(“Front-Line Manager‬‬
‫לאמץ אסטרטגיה לבחירת המבחנים יותר מתוך כל מגוון הבדיקות‬ ‫כמכונת מצבים שהרצתה מעבירה אותה ממצב למצב‬ ‫שיכולים להיות מצבים בהם לא מוצאים תקלות אך הסיכוי שבאמת אין‬
‫‪x‬‬ ‫‪x‬‬ ‫מפתח‬
‫כתגובה לאירוע (למשל הזרמת מידע מסוים)‪ .‬נבחן בכל המועמדות למימוש‪.‬‬ ‫תקלות בכלל הוא אפסי‪.‬‬
‫‪x‬‬ ‫‪x‬‬ ‫‪x‬‬ ‫‪x‬‬ ‫‪x‬‬ ‫מנהל‬ ‫‪Project Members‬‬
‫‪)5‬הרחב את נקודת הראות שלך‪ ,‬אמץ את הכובע החושב‪ ,‬חפש‬ ‫מצב האם התגובות הן נכונות עבור כל אירוע‪.‬‬ ‫‪Spec based testing‬‬ ‫‪A‬‬ ‫‪B‬‬

‫אתגרים‪.‬‬ ‫בדיקות מונחות ספציפיקציות (מסמכי דרישה )‬ ‫‪x‬‬ ‫‪x‬‬ ‫נציג‬

‫שימושים עיקריים בבדיקה פונקציונאליות‬
‫‪)6‬בצע גם בדיקות חוקרניות ‪ exploratory testing‬והרץ בדיקות‬
‫‪---‬מוכוון להבטיח כסוי כל התיפקודים‬
‫חדשות כל פעם מתחילת תהליך הבדיקות ועד סוף הפרויקט‬
‫*ביכולתך להשוות את רשימת הפונקציות לרשימות‬
‫‪Domain Testing‬‬ ‫בתוכנית הבדיקה כולל רשימת התסריטים ומקרי‬
‫הבדיקה על מנת לכסות כל רכיב‪,‬תפקוד‪,‬תת רכיב של כל ‪---‬האנליזה ל ‪ Domain‬היא אסטרטגית דגימה שמאפשרת‬
‫להסתדר עם כמות מרובה מדי של בדיקות‬ ‫האם יש דרש לפשט ( או לשנות) את המוצר כך שיהיה יותר קל‪ ,‬פשוט או תכונה‬
‫המוצר‬ ‫של‬ ‫הראשונות‬ ‫הבדיקות‬ ‫עבור‬ ‫שימושי‬ ‫‪---‬‬
‫‪---‬הדרך המסורתית לניתוח מתייחסת לקלט ופלט של ערכים‬
‫נומריים‬ ‫*הכרות סימפטית עם היכולות של המוצר‬
‫*סריקה מהירה לזהוי בעיות רציניות שצריך לטפל בהם ‪---‬ניתוח הגבולות הוא האופטימאלי לחשיפת סוגי טעויות שונים‬
‫מתי תקבל תוצרים מאחרים‪.‬מתי עליך למסור את העבודה‪ .‬מה נחוץ לך בהתחלה‬
‫כמו קודדו קצוות לא מתאים או דו משמעותי של הגדרות ערכים‬
‫הסיכונים של בדיקות פונקציונאליות‬
‫חוקיים ולא‪ .‬למרות זאת ישנם תחומי טעות אחרים שהשיטה אינה‬
‫‪---‬יופי של דרך להתחיל איתה‪ ,‬אבל מספר אנשים‬
‫חושפת‬
‫מרכזי‬ ‫בדיקות‬ ‫כמהלך‬ ‫כך‬ ‫על‬ ‫להסתמך‬
‫‪---‬לעיתים קרובות הניתוח נראה מכני ורוטיני (נתינת שדה נומרי‬
‫‪---‬מי הם בעלי הענין ‪ ?stakeholders -‬האם יכול להיות שאותם בעלי עניין ‪---‬כשיטה עיקרית לבדיקה הבעיה היא בהדגשת בדיקות והגדרת ערכי הקצה שלו ) אנו עושים מה שאנחנו יודעים אולם‬
‫יחידה תוך בידוד יחידות מסוימות‪::‬‬
‫כאשר מתחשבים בסיכון הוספנו שיטת ניתוח קצת יותר מורכבת‬
‫‪---‬במקום לחשוב אנו יכולים לדרוש מראש שכל הבדיקות (לאחר‬ ‫*חסרה האינטראקציה בין הרכיבים‬
‫בחינת הסיכונים) יתבצעו‪ ,‬עלינו לאמן את הבודקים בזהויי‬ ‫*חסר כל הנושאים שעוסקים בעומס‪ ,‬אינטראקציה עם‬
‫המחלקות הזהות ובבדיקות מונחות סיכונים באופן כללי‪ .‬כאשר‬ ‫מה שקורה ברקע ולא נבחן נושא הפסקות ועצירות‬
‫יתגלו סיכונים חדשים המשויכים לשדה או למשהו אחר ‪ ,‬תוך כדי‬ ‫(מתוכננות ולא)‬
‫‪---‬לעיתים קרובות מתמקד בתפקודים ללא התחשבות בדיקה ביכולתם לנתח מחדש על מנת להגיע למידה אופטימאלית‬
‫של בדיקות‬ ‫בגבולות או פרטי מידע אחרים‬
‫ב ‪ Domain Testing‬אנו‪:‬‬ ‫‪---‬אינו משיב על מטלות המשתמשים – כאשר הלקוח‬
‫‪)1‬מחלקים את מרחב הבדיקות לאזורי בדיקה‬ ‫יכול להשיג את היתרון המובטח על ידי התוכנה‬
‫‪)2 Risk based testing‬מחלקים כל אזור למחלקות מקבילות ‪Equivalent Classes‬‬
‫בדיקות מונחות סיכונים ‪ )3‬בודקים כל מחלקה בנפרד תוך שימוש בערכים המוכלים בה‬
‫‪ )4‬בודקים את נקודות המפגש בין המחלקות ‪Boundary Testing‬‬ ‫)‪Re(f)  P(f)*C(f‬‬
‫‪ Re(f) - Risk Exposure of function f‬הניתוח הקלאסי של מחלקות זהות ‪ Equivalence class -‬ניתוח‬
‫‪ P(f) - Probability of a fault in function f‬גבולות‪:‬‬
‫‪---‬מה זה אומר על בדיקות ?‬
‫‪x‬‬
‫‪---‬המשמעויות עבור עיצוב הבדיקות‪:‬‬
‫איזה טכניקת בדיקות תהיה המתאימה ביותר לפרויקט‬
‫חדשים‬ ‫כלים‬ ‫או‬ ‫נוספת‬ ‫הכשרה‬ ‫דרושה‬
‫יותר זול או אולי מובנה יותר בפשטות‪ .‬כמה מחקר דורש הפרויקט‪.‬‬
‫‪---‬האם לצוות שלך יש את הידע היכולת והקשרים?‬
‫‪---‬לוח הזמנים והמשאבים לבדיקות‪:‬‬
‫על מנת להשלים את העבודה‪ .‬האם איזו התחייבות בדרך אינה סבירה‬
‫‪Testability support---‬‬
‫עשויים‬ ‫הדרישה‬ ‫מסמכי‬ ‫מתוך‬ ‫הבדיקות‬ ‫)‬ ‫‪Driving‬‬ ‫(‬ ‫"‬ ‫שאיבת‬ ‫"‬
‫יקבלו תוצאות צפויות אחרות מאשר איש צוות בודק ממוצע‪.‬‬
‫‪ ---‬מהם בדיקות מונחות ספציפיקציות טובות? אותו דבר כמו בדיקות‬
‫‪ Attribute of good software‬טובות‪ ,‬אבל הבדיקות באות מתוך הדרישות‪ ,‬האם יכול להיות שבדיקה‬
‫המכסה מספר דרישות עדיפה על בדיקה יחידה‪ ,‬יתכן מאוד שבדיקה‬
‫החושפת חוסר בהירות או דו משמעותיות בדרישות חשובה במיוחד‪.‬‬
‫‪---‬כסוי ‪ -‬כסוי כל הדרישות הוא משמעותי ביותר‬
‫‪---‬אמירות יחידות)‪- (individual statements‬כמה בדיקות לאמירה יש‬
‫לבצע‪ ,‬קבוצות רבות נדרשות לאחת בלבד לכל הערה שכזאת‬
‫‪---‬כסוי יחסים מיוחדים‬
‫על מנת לבדוק את א ו ב בודאי תרצה לבדוק‪:‬א נכון וגם ב נכון‪ ,‬א נכון ו‬
‫נכון‬ ‫ב‬ ‫ו‬ ‫נכון‬ ‫לא‬ ‫א‬ ‫‪,‬‬‫נכון‬ ‫לא‬ ‫ב‬
‫‪-‬‬ ‫‪- Traceability Matrices‬‬
‫הקשר בין הדרישות לעיצוב הבדיקות‪ ,‬הרצתם והתוצאות‬
‫‪Defect identifier‬‬
‫לקוח‬ ‫‪A wants to talk to B: Complicated Information Flow‬‬
‫‪B wants to make sure A does a certain change: Complicated Controlflow‬‬
‫‪x‬‬ ‫ועדת‬
‫ערר‬ ‫‪ )2‬מבנה ארגוני פונקציונאלי המבנה הקלאסי שבו כל יחידה ארגונית שייכת‬
‫לתחום מקצועי ואחראית לביצוע כל הפעולות בתחום זה לדוגמא‪ :‬ייצור ‪ ,‬שיווק‪,‬‬
‫בואו נבנה ביחד תרשים זרימה לטיפול בשגויים (‪) 2‬‬
‫האם‬ ‫כספים‪ ,‬הנדסה‪.‬‬
‫‪---‬יתרונות‪ :‬פיתוח מומחיות מקצועית‪ ,‬שימוש יעיל במשאבים‪ ,‬תקשורת בהירה‪,‬‬
‫אדמיניסטרטיביים‬ ‫נושאים‬ ‫ריכוז‬ ‫‪,‬‬ ‫ברורים‬ ‫מסלולי קידום‬
‫‪---‬חסרונות‪ :‬אין סמכות מרכזית לפרויקט‪ ,‬לכל יח' פונקציונאלית יש לו"ז ותקציב‬
‫נפרדים‪ ,‬קשה לתקשר ולשלב בין בעלי התפקידים‬
‫‪ )3‬מבנה ארגוני פרויקטלי מבנה ארגוני שבו כל יחידה עוסקת בפרויקט‪ ,‬מוצר או‬
‫קבוצת מוצרים מוגדרת‪ .‬בנוסף‪ ,‬קיימות יחידות מטה המשותפות לכל הארגון‬
‫‪---‬יתרונות‪ :‬מנהל פרויקט אחראי לתכנון וביצוע הפרויקט‪ ,‬התמקדות על השגת‬
‫מטרות הפרויקט‪ ,‬צוות הפרויקט מחויב לפרויקט‪ ,‬ההתקשרות עם הלקוח‬
‫מתבצעת רק על ידי מנהל הפרויקט‪ ,‬תקשורת טובה בתוך צוות הפרויקט‬
‫‪---‬חסרונות‪ :‬קשה לפתח מומחיות מקצועית‪ ,‬אין ניצול מלא של משאבים‬
‫מקצועיים‪ ,‬אין אופק תכנון מעבר לסיום הפרויקט‪ ,‬חוסר יציבות בארגון עקב מעבר‬
‫אנשים בין פרויקטים‬
‫‪ )4‬מבנה ארגוני מטריציוני מבנה ארגוני המשלב בין המבנה הפונקציונאלי למבנה‬
‫הפרויקטאלי‪ .‬כל פרויקט מנוהל על ידי מנהל פרויקט‪ ,‬המקבל את המשאבים‬
‫המקצועיים ממנהלי היחידות המקצועיות‪.‬‬
‫‪---‬יתרונות‪ :‬מקצועיות‪ ,‬ניצול יעיל של משאבי הארגון‪ ,‬התאמה לסביבה דינאמית‬
‫שבה צוות מצומצם בכל תחום משרת את כל הפרויקטים‬
‫‪---‬חסרונות‪ :‬מורכב לניהול‪ ,‬דורש תיאום בין גורמים רבים‪ ,‬אנשי צוות הפרויקט‬
‫כפופים לשני מנהלים‪ ,‬תקשורת מורכבת בין גורמים מתחומים שונים‪ ,‬למנהל‬
‫הפרויקט קשה לפקח על האיכות המקצועית של הביצוע‬
‫– ‪ CMMI‬היכולות של הארגון בדרגות השונות‬
‫התהליך מנוהל כמותית תוך כדי‬ ‫‪ - 5‬משתכלל – ‪optimizing‬‬
‫שיפור מתמיד‬
‫התהליך מוגדר בלוויות נורמות‬ ‫‪ - 4‬מנוהל כמותית –‬

‫‪ C(f) - Cost related to a fault in function f‬איננו יכולים להרשות לעצמנו להריץ כל בדיקה אפשרית‪ ,‬לפיכך‬ ‫‪TR1‬‬ ‫‪TS1‬‬
‫‪Defect severity‬‬
‫‪Defect‬‬
‫‪Defect‬‬ ‫‪identifier‬‬
‫‪status‬‬
‫‪Defectinfo‬‬
‫‪severity‬‬

‫כמותיות‬
‫‪Tc1‬‬ ‫‪Defect‬‬

‫עלינו לאמץ לעצמנו מתודולוגיה לבחירת מעט מקרים עוצמתיים‬ ‫‪TR2‬‬

‫‪Tc21‬‬
‫‪Tc21‬‬
‫‪Defect‬‬
‫‪Defect‬‬ ‫‪identifier‬‬
‫‪status‬‬
‫‪Defectinfo‬‬
‫‪Defect‬‬ ‫‪severity‬‬
‫‪Defect status‬‬
‫‪quantitatively managed‬‬
‫?‪ Software Errors : What Kind of Error‬אשר ייצגו את היתר‪ .‬ניתוח המחלקות הזהות ‪Equivalence -‬‬ ‫התהליך מנוהל כתהליך ארגוני אחיד‬ ‫‪ - 3‬מוגדר – ‪defined‬‬
‫‪Tc21‬‬ ‫‪Defect info‬‬
‫‪Tr21‬‬
‫‪Tc2‬‬
‫‪TS2‬‬ ‫‪Tc22‬‬
‫‪Tc21‬‬ ‫‪Defect identifier‬‬

‫‪---Coding Error: The program doesn’t do what the‬‬ ‫התהליך מבוצע על בסיס תשתית‬ ‫‪ - 2‬מנוהל – ‪managed‬‬
‫‪Tr22‬‬
‫‪Defect severity‬‬
‫‪Tc23‬‬ ‫‪Defect‬‬ ‫‪identifier‬‬
‫‪Defect‬‬ ‫‪status‬‬

‫‪ analysis‬הינה השיטה הנפוצה ביותר לכך‪.‬‬ ‫‪Tc22‬‬

‫‪Tc22‬‬
‫‪Defectinfo‬‬
‫‪Defect‬‬
‫‪Defect‬‬
‫‪Defect‬‬
‫‪severity‬‬
‫‪identifier‬‬
‫‪status‬‬

‫פרוייקטית‬
‫‪Tr23‬‬ ‫‪Defectinfo‬‬‫‪severity‬‬
‫‪Defect‬‬
‫‪programmer would expect it to do.‬‬ ‫‪Tc23‬‬ ‫‪Tc31‬‬ ‫‪Defect status‬‬

‫‪--‬על מנת למנוע בדיקות לא הכרחיות נחלק ‪- partition‬‬ ‫‪Defect info‬‬

‫התהליך משיג את יעדיו הספציפיים‬ ‫‪- 1‬מבוצע ‪performed -‬‬

‫‪(divide) ---Design Issue: It’s doing what the programmer‬את תחומי ערכי הכניסה ‪ - inputs‬לקבוצות של בדיקות‬ ‫עץ סטים לבדיקות‪ ,‬עץ תנון בדיקות‪ ,‬עץ דרישות‬ ‫מאגר שגויים‪,‬‬
‫מהו מיקור חוץ )‪(outsourcing‬‬
‫‪ intended, but a reasonable customer would be‬בעלות זהות מקבילה‬ ‫‪S-M-A-R-T Requirements.‬‬ ‫הרעיון ‪ -‬להוציא מהארגון את הפעילויות שאינן נמצאות בבסיסו ולהעבירן לספק‬
‫‪--- confused or unhappy with it.‬נתייחס לשתי בדיקות כמקבילות כאשר הם כה דומות אחת‬ ‫‪---Specific - We want requirements that are both precise and‬‬ ‫‪COCOMO 2 is really three different models‬‬ ‫חיצוני‪ ,‬ולהותיר בתפעול ובניהול ישיר רק את פעילויות הליבה של הארגון‪.‬‬
‫‪ ---Requirements Issue: The program is well‬לשניה ונדמה שזה מחוסר ענין לבדוק את שתיהן‪.‬‬
‫‪thorough‬‬ ‫‪---The Application Composition Model - Suitable for projects built with modern GUI-builder‬‬ ‫מיקום מיקור החוץ‬
‫‪--- designed and well implemented, but it won’t meet‬בחר ערך כניסה אחד מתוך מחלקה מקבילה כמייצגת את כל‬
‫‪---Measurable - while ‘measurable’ should encourage the use of‬‬ ‫‪tools. Based on new Object Points.‬‬ ‫–‪ On Site‬מיקור החוץ נמצאת פיזית בתוך הארגון אך לא שייכת ישירות אליו‬
‫‪ one of the customer’s requirements.‬הקבוצה‬
‫‪quantitative testable requirements that have been assigned an‬‬ ‫‪---The Early Design Model - You can use this model to get rough estimates of a project's‬‬ ‫– ‪Inshore / Onshore‬החוץ נמצאת באותה המדינה אך לא יושבת בתוך הארגון‬
‫‪--- ---Documentation / Code Mismatch: Report this to‬אם ביכולתך למפות את מרחב הכניסה למספר שורה‪ ,‬סמן את‬
‫‪actual value to both achieve and test against.‬‬ ‫‪cost and duration before you've determined it's entire architecture. It uses a small set of‬‬ ‫– ‪Offshore‬קבוצת מיקור החוץ נמצאת במדינה זרה מרוחקת‬
‫‪ the programmer (via a bug report) and to the writer‬הגבולות והאזורים המבדילים את המעבר בין מחלקה אחת‬
‫‪---Acceptable - ‘Acceptable’ requirements should satisfy the needs new Cost Drivers, and new estimating equations. Based on Unadjusted Function Points or‬‬ ‫‪ – Nearshore‬קבוצת מיקור החוץ נמצאת במדינה זרה סמוכה (בד"כ מדינה‬
‫‪ (usually via a memo or a comment on the‬לשניה ‪ -‬אלו הם מועמדים טובים של כל מחלקה כי התוכנית‬
‫‪ manuscript).‬עשויה להכשל דוקא בנקודות המעבר הזה‪.‬‬ ‫‪of the customers and users.‬‬ ‫‪KSLOC.‬‬ ‫הגובלת במדינה בה נמצא הארגון )‬
‫‪ ---Specification / Code Mismatch: Sometimes the ---Realisable - The main point of ‘realisable’ requirements is that‬טבלת הגבולות ‪boundary table -‬‬ ‫‪---The Post-Architecture Model - This is the most detailed COCOMO 2 model. You'll use it‬‬ ‫יתרונות מיקור חוץ של בדיקות תוכנה‬
‫‪Variables‬‬ ‫‪Valid Case‬‬ ‫‪Invalid Case‬‬ ‫‪Boundaries and‬‬ ‫‪Notes‬‬ ‫‪they should be realistic and achievable given the constraints of the after you've developed your project's overall architecture. It has new cost drivers, new line‬‬ ‫הפחתת עלויות‪ ,‬שיפור יכולות הארגון‪ ,‬שיפור איכות המוצר‪ ,‬האצת תהליך‬
‫‪spec is right; sometimes the code is right and the‬‬
‫‪Equivalence Equivalence Classes Special Cases‬‬ ‫‪project‬‬ ‫‪counting rules, and new equations.‬‬ ‫הפיתוח )‪ , (speedup‬חסכון במשאבי הארגון‪ ,‬שיפור תהליך בדיקת המוצר‬
‫‪Classes‬‬ ‫‪spec should be changed‬‬
‫מעקב ‪---Traceable -‬‬ ‫חסרונות מיקור חוץ של בדיקות תוכנה‬
‫)‪None Functional testing (NFT‬‬ ‫למה צריך אוטומציה לבדיקות? כי זה יותר זול‪ ,‬כי זה יותר אמין‪,‬כי אנשים משתעממים מבדיקות ידניות‪,‬‬
‫‪---‬הבדלי תרבויות בין מדינות ‪ -‬עלולים ליצור בעיות עקב חוסר הבנה של‬
‫בדיקות לא פונקציונליות‪ :‬בודקות איך התוכנה ( מערכת ) מתנהגת‪ ,‬לא בודקות מה היא עושה‬ ‫כי צריך לבדוק המון במעט זמן‪ ,‬כי זה יוקרתי‪ ,‬כי זה מעניין יותר‪ ,‬משלמים יותר כסף‬
‫‪-99 to 99‬‬ ‫‪> 99‬‬ ‫מאפיינים חברתיים‬
‫‪Functional‬‬ ‫&‬ ‫‪Non‬‬ ‫‪Functional‬‬ ‫‪Requirements‬‬ ‫‪Regression‬‬ ‫‪Strategy‬‬
‫‪< -99‬‬ ‫‪-‬‬ ‫‪-‬‬ ‫‪---‬אבטחת מידע ‪-‬צוות מיקור החוץ נחשף למידע רב על הארגון‬
‫‪First Number‬‬
‫‪---Functional Requirement - specifies a function that a system or system component must be able to perform.‬‬ ‫‪When regression is clear, re-check all stored runs from the set that produced the test case‬‬
‫‪-99 to 99‬‬ ‫‪> 99‬‬ ‫‪, 99‬‬ ‫‪---‬איכות השירות ‪ -‬לא ניתן להבטיח כי צוות הבדיקות הינו איכותי ומיומן‪ ,‬ויש‬
‫‪< -99‬‬ ‫‪-100, -99‬‬ ‫‪---Non Functional Requirement - Building systems with only functional requirements is relatively easy, but ultimately‬‬ ‫‪Add new (minimized only!) regressions if any of these tests fail‬‬
‫‪Second Number‬‬ ‫לבחור אותו בקפידה ‪.‬עמידה בזמנים ואיכות המוצר תלויים לא רק בארגון אלא‬
‫‪-198 to 198‬‬ ‫‪> 198‬‬ ‫)‪(99,-99‬‬ ‫‪ pointless. No-one wants a slow, unreliable system that costs a fortune to modify.‬איך‬ ‫‪Re-run all stored test cases on a weekly basis‬‬
‫גם בביצועים של צוות הבדיקות‪.‬‬
‫‪< -198‬‬ ‫)‪(-99,99‬‬ ‫‪ ‘Non-functional requirements’ is that they specify all the remaining requirements not covered by the functional‬להמציא‬ ‫‪ -‬אי אפשר לעשות את זה בלי ‪UTS – Design And Perspective Entity Model – Best practice:‬‬
‫)‪(99,99‬‬ ‫‪---‬תקשורת ‪ -‬במידה וקבוצת מיקור החוץ יושבת מחוץ לארגון‪ ,‬התקשורת בינה‬
‫מצבי‬ ‫‪requirements.‬‬ ‫מערכת‬ ‫‪,‬‬‫תחומיים‬ ‫בין‬ ‫עבודה‬ ‫צוותי‬ ‫‪,‬‬‫בארגון‬ ‫מוטמעות‬ ‫אוטומציה‬ ‫תשתיות‬ ‫‪,‬‬ ‫ההנהלה‬ ‫של‬ ‫מוחלטת‬ ‫תמיכה‬
‫)‪(-99,-99‬‬ ‫לבין המפתחים לא תמיד נעשית בתנאים נוחים (אמצעי תקשורת‪ ,‬שעות לא‬
‫שגיאה‬ ‫‪Nonfunctional requirements specify the system’s ‘quality characteristics’ or ‘quality attributes’.‬‬ ‫דיווח כלל אירגונית‪ ,‬מעבדה להרצה ממכונת של התסריטים‪ ,‬שנוי כוח אדם ומקצועי‪ ,‬מעורבות הלקוח‬
‫‪Sum‬‬ ‫שגרתיות )‬
‫(פנימי וחיצוני‪ ,‬תהליך הטמעה מסודר לכל הארגון‬

‫א‪ .‬הצע תרשים זרימה לתקלות‪ .‬את מי הוא משרת? מהי חשיבותו לפרויקט‬
‫הבדיקות? ‪bug flow‬‬
‫‪ – review‬סקירת התקלה‬ ‫‪ - Enterd‬זיהוי ופתחת תקלה‬
‫‪ – prioritized‬תעדוף ע"י בודק או מנהל לקוח (גורם אחראי מצד לקוח)‪ .‬נתינת‬
‫תעדוף לתקלות מאפשר להטיב קשר בין צוות פיתוח לבדיקות‪.‬‬
‫‪ - assigned‬שיוך‪/‬העברה לטיפול בד"כ ע"י פיתוח‪.‬‬
‫‪ – unassigned‬לא ניתן להעברה‪/‬שיוך לטיפול‪.‬‬
‫‪ – fixed‬תיקון התקלה או כשלון בתיקון‪.‬‬
‫‪ – closed‬סגירת תקלה לאחר אישור‪.‬‬
‫‪ – reopened‬פתיחת התקלה מחדש (בד"כ אחרי בדיקות רגרסיה)‪.‬‬
‫הערה‪ :‬אחרי שתקלה נסגרה הבודקים מבצעים בדיקות רגרסיה כדי לבדוק שאחרי‬
‫התיקון הכל עובד‪.‬‬
‫תרשים ‪ bug flow‬משרת את כולם‪ :‬חשוף לכולם‪ ,‬יש תיעוד שגיאה שיכול לעזור‬
‫בטיפול בשגיאות דומות‪ ,‬יש כללים והגדרות עלפיהן יש לפעול‪ .‬כל צוות יודע מה‬
‫עליו לעשות‪.‬‬
‫חשיבות התרשים לפרויקט בדיקות נותן סדר למערכת‪ ,‬משפר קשר בין צוותים‪.‬‬
‫במקרה שלנו צוות בדיקות נותן העדפות‪ ,‬צוות פיתוח יכול להתייחס להעדפות האלו‬
‫וצוות אוטומציה יכול להריץ בדיקות רגרסיה על תקלות שטופלו‪ .‬כאשר בארגון יש‬
‫כלי לניהול תקלות כל ראשי הצוותים יכולים להיכנס למערכת ולדעת מה מצב‬
‫התקלות‪ .‬כמו כן יצומצמו מספר התקלות הלא מטופלות כיון שכולם רואים אותן‬
‫והדבר מפריע להנהלה‪.‬‬
‫ב‪ .‬תאר באופן מילולי את זרימת הטיפול בשגויים ופרט מה תפקיד כל אחד‬
‫ואחד מהמשתתפים?‬
‫קודם כל בודקים או מנהל לקוח מזהים תקלה ומבצעים פתיחת תקלה‪ .‬לאחר מכן‬
‫בודקים‪/‬מנהל לקוח נותנים עדיפות כדי שהמפתחים ידעו במה לטפל קודם‪.‬‬
‫לפעמים ועדה מיוחדת יכולה לדחות שגיאה ואז היא תהיה בסטאטוס ‪(committee‬‬
‫)‪ . reject‬כאשר שגיאה עוברת ליעד המטפל היא מקבל סטאטוס ‪.allocated‬‬
‫שלאחר שיוך השגיאה לטיפול היא עוברת לסטאטוס ‪ .assigned‬צוות מפתחים‬
‫מבצע תיקון ואז ניתן לשנות סטאטוס ‪ .delivered to cc‬ואז צוות בדיקות יכול‬
‫להריץ רגרסיה‪.‬‬
‫לאחר הרגרסיה הסטאטוס עובר ל ‪ verified‬או אם נרצה לדחות תיקון או שגיאה‬
‫נעביר ל ‪.reject‬‬
‫אם התיקון הצליח הסטאטוס עובר ל ‪ .closed‬אם אין זמן לתקן אז ‪.cancel‬‬
‫ג‪ .‬הצג את הסיכונים הנובעים מאי עמידה ובזרימה המוצעת?‬
‫אי עמידה בזרימה משבש את הקשר בין צוותים השונים‪ ,‬קשה לדעת כמה תקלות‬
‫יש ומה מצבן‪,‬אין תיעוד נכון עבור תקלות‪ .‬כתוצאה מכך אי עמידה בלוז או בתקציב‪,‬‬
‫אי מעידה בדרישות הלקוח‪.‬‬
‫מדובר בפרויקט תוכנה ולכן אבחר במודל ‪ .agile scrum‬לכן יהיו הרבה צוותים קטנים של ‪ 5-9‬איש‬
‫סיכון עקרי – בזמן בדיקת האינטגרציה צוות הפיתוח נמצא באיטראציה הבאה‪.‬‬
‫ד‪ .‬הצע מנגנון לשילוב הלקוח בתהליך העבודה?‬
‫לפי מודל ‪ time box‬הלו"ז נמצא בראש סדר העדיפויות‪ .‬הפיתוח מתבצע‬
‫באיטראציות קצרות‪ .‬לאחר כל איטראציה יוצאת גרסה של מוצר ללקוח‪ .‬בשלב זה‬
‫הלקוח בודק האם המוצר עומד בדרישותיו ובנוסף הוא יכול לזהות תקלות‬ ‫מדובר בפרויקט גדול לכן נצטרך קבוצות נוספות‪ :‬קבוצות לביצוע אינטגרציה בין מה שעשו כל הצוותים‪.‬‬
‫שהבודקים לא זיהו‪.‬‬
‫א א‪ .‬באיזה אופן ניתן לבדוק ולהעריך את איכות פרויקט הבדיקות?‬
‫מדובר בפרויקט גדול (‪ 79‬אנשי פיתוח ובדיקות)‪ ,‬נכתבו רק ‪ .TC 231‬בפרויקט בסדר‬
‫גודל כזה צריך להיות הרבה יותר ע"מ לכסות את הפרויקט כולו במקרי בדיקה‪ .‬לא‬
‫יתכן שפרויקט שכותבים ‪ 48‬מפתחים יש לו רק ‪ 231‬מקרי בדיקה ורק ‪ 8‬סטים‬
‫לבדיקות הרצה‪ .‬היפותטית זה יכול לקרות אבל ברור שהמצב לא תקין‪ .‬ע"פ ביל‬
‫גייטס למייקרוסופט יש מספר בודקים כמספר המפתחים וישנן יותר שורות קוד‬
‫בדיקה מקוד התכנית (ככה צריך להיות פחות או יותר בכל פרויקט תוכנה)‪ .‬במקרה‬
‫זה מספר הבודקים הוא כמעט קטן פי ‪ 2‬ממספר המפתחים‪ .‬פרויקט זה חרג‬
‫בשבועיים דבר המצביע על תקלות רבות כגון חריגה בניהול התקציבי (אולי קנסות)‪,‬‬
‫תקלת כ"א שהיא סיבה שכיחה לחריגה בלו"ז‪ .‬חוסר הספק בעבודה עקב חוסר בכ"א‬
‫או כ"א לא מיומן – במקרה זה מחסור בבודקים‪.‬‬
‫חילופי מנהלי בדיקות במהלך פרויקט פוגע קשות בלו"ז המתוכנן ובסדר העבודה‬
‫מכיוון שלכל מנהל יש מדיניות משלו ולוקח זמן ליישם ולהטמיע אותה‪ .‬היחס בין‬
‫שגויים למס' בדיקות הוא גבוה מדי‪ ,‬יש יותר מדי באגים יחסית למקרי הבדיקה ויש‬
‫יותר מדי באגים קשים למרות שרובם נסגרו‪ .‬דבר זה מצביע על מיומנות ירודה של‬
‫מפתחים או חוס הבנת הדרישות‪.‬‬
‫ב‪ .‬על בסיס מה אפשר לבחון את איכות התוכנה הנבדקת (פרטו הצעותיכם‬
‫לאיש שימונה בוחן האיכות מטעם הארגון – מה לבדוק והסבירו למה)?‬
‫איכות תוכנה – נבחן את איכות הקוד על מישוריו‪ .‬מכיוון שמס' מקרי הבדיקה הוא‬
‫נמוך הדבר מצביע כי הקוד הוא יחסית פשוט ואינו מורכב ביחס לגודל הפרויקט‪.‬‬
‫כלומר מס' הדרכים המינימאלי להגיע מתחילת ועד סוף הקוד קטן יחסית‪ .‬יש בעיה‬
‫עם אמינות הקוד עקב המצאות מס' רב של שגויים בסה"כ ‪ .1049‬נוסף על כך היחס‬
‫בין חומרת השגויים מצביע על איכות ירודה (‪ ,)409/640‬היחס צריך להיות קטן‬
‫בהרבה‪ 140 .‬שגיאות בינוניות נותרו בהמתנה – מספר יחסית גדול‪ ,‬אין נתונים לגבי‬
‫סיבוך הקוד‪ ,‬מס' לולאות ואורך הקוד ‪ LOC‬יחסית למס' שגיאות זה גם גורם משפיע‪.‬‬
‫ג‪ .‬איזה אניפורמציה חסרה לכם לצורך תשובות יותר טובות לשאלה הקודמת?‬
‫חסר מידע לגבי כ"א אדם נוסף לפרויקט מלבד מפתחים בודקים ושני מנהלים‪ .‬רמת‬
‫מקרה מייצג משיכה של סכום של ‪– 450‬בדיקה שמטרתה שלילית מצפה להודעה שלא ניתן למשוך‬
‫ניסיון והכשרה של כ"א קיים‪ .‬חסרה אינפורמציה לגבי הסכמים עם הלקוח‪ ,‬בעיקר‬
‫לגבי חריגות בלו"ז ובתקציב דבר לגרור קנסות‪ .‬לא מפורטות אבני הדרך‪ ,‬אין מידע‬
‫תקציבי על הפרויקט (שכר‪ ,‬מחיר תוכנה‪ ,‬בונוסים‪ ,‬חריגות)‪ ,‬אין פרוט לגבי בדיקות‬
‫לא פונק' ‪ ,NFT‬קיימת אפשרות שהרבה מהבעיות נוצרו דווקא שם‪.‬‬
‫ההגדרה הפורמלית מכריחה את מקרה הבדיקה להיות מסודר ומתאים לחלוטין למה שנדרש – נצפה‬
‫‪ -‬סה"כ שגיאות‬ ‫‪1‬‬
‫‪ -‬שגיאות פתוחות‬ ‫‪2‬‬
‫‪ -‬שגיאות שתוקנו‬ ‫‪3‬‬
‫‪ -‬כמות שגיאות‬ ‫‪4‬‬
‫ב ‪ -TDD‬התרשים אינו בסדר‪ -‬יש קודם‬
‫לכתוב טסט ולהריצו ורק אחרי כן‬
‫(לאחר כישלון) לכתוב את הקוד להריץ‬
‫עוד פעם‬
‫‪ TDD‬מתייחס לבדיקות התוכנה באופן הבא ‪ TDD‬גורסת שלא נפתח משהו שאין לנו בדיקות עבורו‪-‬‬
‫זאת אומרת בואו קודם נגדיר בדיקה‪ -‬נבדוק ונראה שנכשל ולפי זה נפתח תוכנה שמעבירה את‬
‫הטסטים‪.‬‬
‫לפי התרשים הבא מהם התוצרים הנדרשים ממהנדס הבדיקה בתהליך עבודתו‬
‫‪ - a‬תוכנת ולוז‬
‫‪ - b‬מקרי הבדיקה‬
‫‪ - c‬נתונים וסביבות בדיקה‬
‫‪ - d‬שגויים ודוח תוצאות‬
‫מהו תהליך קסטומיזציה )‪(customization‬תהליך ההתאמה לתנאי המקום הספציפיים‬
‫במודל אג'ילי (‪ ) agile‬מה מסמלות האותיות בתרשים הבא?‬
‫‪ - a‬הפריט הבא לפיתוח‬
‫‪ - b‬רשימת רכיבים‬
‫ממתינים לפיתוח‬
‫‪ - c‬קבוצת המטלות להיום‬
‫‪ - d‬התוכנה מוכנה‬
‫למסירה‬
‫התגלתה תקלה וטופלה‪ .‬תסריט הפעולה הנכון ביותר (מגילוי הבעיה על לסגירתה) הוא‪ :‬פתיחת‬
‫התקלה‪ ,‬סיווג התקלה‪ ,‬תיקון התקלה ובדיקתה ‪ ,‬אינטגרציה‪ ,‬בדיקה מערכת וסגירתה‬
‫מדוע נאמר שאין אפשרות לכסות הכול בבדיקות? לכל תוכנה גם אם נראית פשוטה מצבים רבים‬
‫ומשאבים מוגבלים וקשה לבדוק את כולם‬
‫האם‪ :‬בתכנון בניית תזמונים בתכנון פרויקטים‪ :‬ה‪ ES -‬של המצבים אשר יוצאים מה‪ START -‬הינו ‪0‬‬
‫וה‪ EF -‬מתקבל ע"י הוספת ה‪ ES -‬של הצומת למשך זמן הביצוע שלה‪.‬‬
‫תרשים ‪ GANT‬הוא‪ :‬תרשים המתאר את רשימת הפעילויות לפי הסדר הנדרש והמשאבים הדרושים‬
‫לביצוען בעזרת מערכת צירים‪.‬‬
‫תרשים ‪ PERT‬הוא‪ :‬תרשים המתכנן את הפעילויות שיש לבצע ע"פ סדר עדיפויות הגיוני וזיהוי המסלול‬
‫הקריטי‪.‬‬
‫מהי בדיקה פונקציונאלית? בדיקת תהליך בודד במוצר מתחילתו ועד סופו לפרטי פרטים‪.‬‬
‫רשימה מייצגת בדיקות לא פונקציונאליות (‪ (NFT‬היא‪Scalability, security, load, stress, stability, :‬‬
‫‪performance, volume, robustness, compatibility and data conversion, usability‬‬
‫מהו ‪?CFG‬מודול סכמתי לשיטת תיאור קוד בעזרת רצף פקודות‪ ,‬צמתים וקשתות‪.‬‬
‫מסמך ‪ STR‬הוא‪ :‬מסמך המתאר את מקרי הבדיקה הכולל בתוכו את תוצאות הבדיקה במבנה טבלאי‬
‫מפורט‪ .‬נכתב ע"י צוות הבודקים יחד‪.‬‬
‫מסמך ‪ STD‬הוא‪ :‬מסמך תיאור הבדיקות המתאר בשלבים את הבדיקות שיש לבצע‪ .‬מכיל את‬
‫הדרישות לבדיקות ומטרות הבדיקה‪.‬‬
‫מה יהיו מקרי הבדיקה המינימליים שתבחר עבור בדיקות לשדה קלט במחלקה שהערכים‬
‫המותרים בה הם ‪)0,1,57,99,100 ( 100 < X < 0 *** (99,100,150,200,201) 200 => X => 100‬‬
‫בדיקות מונחות סיכון הן‪ :‬בדיקות שנבנו על פי מידת הסיכון שארגון יחשף אליו אם הנושא לא יעבוד‬
‫כראוי‬
‫ביל גייטס אמר בעדותו על הנעשה במיקרוסופט‪ :‬יש יותר שורות קוד למעטפת הבדיקות מאשר‬
‫לקוד עצמו‪.‬‬
‫כאשר מקרה בדיקה (‪ ) test case‬נוצר בהתבסס על מקרה שימוש (‪ .) use case‬איזה סוג בדיקה‬
‫(‪ ) test type‬נוצר? בדיקת תפקוד‬
‫לכל שגיאה ‪ -‬לפני תחילת הטיפול בה‪ ,‬יש להגדיר בדיוק מהן‪ :‬דרגת החומרה של השגיאה‪ ,‬מידת‬
‫הדחיפות לטיפול וסטאטוס לשגיאות‪ .‬מה זה בדיקות רכיבים ‪ :‬רמת בדיקה‬
‫מהו מחזור חיי תוכנה? שלב הדרישות ‪ >-‬שלב הניתוח ‪ >-‬שלב התכן ‪ >-‬שלב המימוש ‪ >-‬שלב‬
‫השילוב ‪ >-‬שלב האחזקה ‪ >-‬פרישה‬
‫מתוך הרשימה הנ"ל‪ :‬מה אינו עקרון של ‪,Refactoring ,Pair ,Continuous testing : XP‬‬
‫‪programming, testing ,ownership of testing , 40-hour work week, On-site customer ,Coding‬‬
‫‪Ownership of testing standards‬‬
‫א‪ .‬איזה כלי בקרה תבחר ע"מ לנטרל את הבעיות? איך ישפר הכלי את הבעיה?‬
‫אבחר למדל את העבודה בצורה מסודרת יותר שתוכל להאכף יותר בקלות‪ .‬במרבית בתי התוכנה‬
‫היום קיימת מערכת לטיפול בשגיאות‪ .‬ישנן מס' מערכות נפוצות בשוק אשר מאפשרות לבית התוכנה‬
‫להתאים תוכנת עזר למעקב‪ .‬תכנת עזר מוכרת שמאחוריה עומד תהליך הטיפול היא ‪ .foglougz‬ניתן‬
‫להתייחס אליו כתרשים זרימה מכניסת השגיאות למערכת ועד טיפול ותיקון הבעיה‪ .‬כלי כזה ישפר את‬
‫הבעיה בכך שהמערכת תהיה משותפת לכל הנוגעים בדבר ויהיה ניתן לצפות בסטאטוסים ובשינויים‬
‫ללא צורך בתיאום מפגש בין המפתחים‪/‬בודקים לראש הצוות‪ .‬מידע לא ילך לאיבוד‪ ,‬בנוסף בכל מערכת‬
‫שכזו יש פונק' שעוזרות רבות לניהול הטיפול מלבד החשיפה לכל המעוניין‪ .‬למשל מתן עדיפות לבעיה‬
‫שהתגלתה‪ .‬העדיפות יכולה להיות גדולה כי מנהל הלקוח דוחף לטיפול מיידי (בצדק)‪ ,‬או מכיוון‬
‫שהמפתח מאמין שבעיה זו יכולה לגרום לבעיות נוספות בעתיד ויש לתקנה בדחיפות‪.‬‬
‫כאשר לכל אחד מוגדרת הרשאה חלק יכולים לפתוח תקלה‪ ,‬אחרים לסגור ובד"כ כולם יכולים להסתכל‬
‫בתיעוד והתפתחותו‪.‬‬
‫ב ‪ .‬מי המשתתפים העיקריים בו? מה תפקיד כל אחד בכל אחת מנק' ההחלטה?‬
‫המשתתפים העיקריים בכלי יהיו כל הנוגעים לקוד‪ .‬אם מדובר בבית תוכנה אזי מנהלי לקוחות התוכנה‬
‫יהיו אלה שמקבלים את הדיווח על השגיאה מהלקוח‪ ,‬או תיקונים רצויים‪ .‬המפתחים יהיו אלה‬
‫שמתקנים את הבעיה והבודקים יבדקו שהבעיה אכן תוקנה‪ .‬בד"כ יצאו גרסאות חדשות המכילות את‬
‫השינויים לפי השמנת הלקוח ובהתאם לחוזה‪ .‬כי שצויין יש אפשרות להוסיף במערכת דרישות קדימות‬
‫ועדיפות לפני שהבעיה מגעיה לטיפול‪ ,‬כך שיהיה ניתן להשפיע על עבודת נמפתח‪ .‬במובן כלשהו אפילו‬
‫ללא הסבר או פגישה‪ .‬בעיות עם עדיפות גבוה יותר יטופלו קודם ובכך אולי יתרמו ליחסים בין הבודקים‬
‫לפיתוח אשר יוכלו להשפיע על סדר העבודה של שני הצדדים‪ .‬ישנן מס' נק' החלטה‪ ,‬לדוגמא למי‬
‫להעביר את השגיאות לטיפול ולמי לבדיקה‪ .‬בד"כ תהיה הירארכיה ואם אין אז כדאי לבנות כזו‪ .‬בנוסף‬
‫צוותי פיתוח ובדיקות בארגונים רבים עובדים לפי מוצר ולא לפי תהליך‪ .‬נק' החלטה נוספות הן סגירת‬
‫השגיאה‪ ,‬שינוי סדר העדיפויות‪ .‬ההחלטה תתבצע ע"י גורמים בכירים בד"כ אשר רואים את תמונת‬
‫המערכת הכוללת‪.‬‬
‫א‪ .‬הצע את קבוצות העבודה השונות והסבר כיצד הן משתלבות בתוך מחזור חיי הפרויקט‬
‫שבחרת‪.‬‬
‫אשר יכללו מנהל‪ ,‬לקוח אשר יקבע מה דרך הפעילות ובה חשיבות לכל ‪ story‬וגם יהיה נציג של לקוח‬
‫בקבוצה‪ .‬אנשי הפיתוח‪ :‬ארכיטקט‪ ,‬מפתחים‪ ,‬מנהלי ‪ ,DB‬אנשי בדיקות‪ scrum master ,‬אשר ידאג‬
‫שהעבודה מתקדמת כמו שצריך וגם יקשר בין הצוות לעולם החיצון (צוותים אחרים‪ ,‬לקוח‪ ,‬הנהלה)‪.‬‬
‫יהיה צוות בדיקות מרכזי הכולל אנשי אוטומציה‪ ,‬אנשי תשתיות ותמיכה וצוות אינטגרציה‬
‫ב‪ .‬שרטט את המבנה הארגוני שנדרש לפרוייקט כולו (בכללי) וליח' הבדיקה באופן ספציפי‪.‬‬
‫כמו בדף נוסחאות (מבנה ארגוני לפרויקט‪ ,‬מבנה צוות בדיקה בתוך הפרויקט)‪.‬‬
‫מבנה צוות ‪ ,developing team ,scrum master – scrum‬אנשי ‪product manager ,QA‬‬
‫ג‪.‬נמק מה חשיבות כל קבוצה שאתה מציע ומה הסיכון לא להקים אותן‪.‬‬
‫חשיבות קבוצות ‪ – scrum‬שילוב של אנשים מתחומים שונים כך שכל קבוצה תוכל לעבוד על החלק‬
‫שלה‪ .‬צוות בדיקות ‪ -‬בדיקת עבודת המערכות לאחר ביצוע אינטגרציה‪.‬‬
‫צוות תשתיות ותמיכה – בדיקת תשתית ‪,‬מסד נתונים‪ ,‬חומרה ותחזוקה‪.‬‬
‫צוות אינטגרציה – הרצת רגרסיות ותיקון שגיאות‪.‬‬
‫צוות אוטומציה – וידוא בדיקות ממוכנות‪.‬‬
‫הוטל עליך להכין תסריטי בדיקות עבור מערכת תוכנה לכספומט שמכיל שטרות בנות ‪ ₪ 100‬ו‪,₪ 200‬‬
‫הפעלת התוכנה מחולקת לשלושה מודולים‪:‬‬
‫כניסה והזדהות ‪ -‬באמצעות העברת כרטיס והקשת קוד סודי‬ ‫‪‬‬
‫בחירת הסכום למשיכה (מותרים סכומים עד ‪ 1000‬שקל)‬ ‫‪‬‬
‫פעולת הגשת הכסף למגירת המשיכה וגריעת הסכום מתוך חשבון הלקוח‬ ‫‪‬‬
‫עבור שני המודולים הראשונים יש‪:‬‬
‫‪.1‬להגדיר לפחות שתי מחלקות לבדיקה – ‪ Equivalent Classes‬הסבר למה מה שבחרת הינן‬
‫מחלקות שונות‬
‫מודול ‪ :1‬מחלקה אחת העברת כרטיס תקין או שגוי‬
‫מחלקה שניה הקלדת מספר סודי נכון ולא נכון‬
‫ניתן לראות שאין כל קשר בין המחלקות שנבחרו משום שעוסקות בפרטים שונים ובלתי תלויים‬
‫מודול ‪ : 2‬בחירה בסכומים המותרים (כפולות נכונות של השטרות הקיימים)‬
‫בחירה בסכומים לא מותרים (למשל ‪) ₪ 350‬‬
‫‪ .2‬לתכנן מקרי בדיקה עבור כל מחלקה כך שיכילו‪ :‬בדיקה מייצגת לכל מחלקה ומקרי קצה ‪-‬‬
‫‪ – boundary testing‬כדאי להציג בטבלה‬
‫למודול ‪: 1‬בדיקת כרטיס תקין מצפה שנגיע למודול הבא‬
‫בדיקת כרטיס שגוי מצפה להודעת שגיאה‬
‫למודול ‪ :2‬מקרה מיצג – משיכה של סכום ‪₪ 300‬‬
‫מקרה קצה משיכת ‪ 1100‬שח – מצפה להודעת שגיאה שלא ניתן למשוך יותר מ ‪ 1000‬שקלים‬
‫אלא רק סכומים עגולים‪.‬‬
‫‪.3‬עבור המודול השלישי ‪ -‬יש לנסח ‪ 2‬מקרי הבדיקה על פי ההגדרות הפורמאליות של ‪.IEEE‬‬
‫ההגדרה על פי ‪ IEEE‬היא ‪ :‬מקרה הבדיקה הוא – סט של נתוני כניסה ‪ ,‬תנאי הרצה‪ ,‬ותוצאה מצופה‬
‫על פי ציפיה מאוד ברורה מהנדרש ממקרה הבדיקה בהתאם להתאמה לדרישה מסויימת‪.‬‬
‫‪.4‬להסביר מדוע ההגדרה הפורמלית עוזרת במקרה זה‬
‫לתשובה המדגימה את זה בהתאם למקרי הבדיקה שנבחרו‬
‫סקירת קוד הוא תהליך המיועד ל‪ :‬בדיקת התוכנה עוד לפני שהופעלה‬
‫מיהם בעלי העניין ‪ stakeholders‬בפרויקט הבדיקות הגורמים המעוניינים האמיתיים בהנהלות‬
‫(ספק‪ ,‬לקוח) בהצלחת הפרויקט או אלו שיינזקו ביותר אם יכשל‪.‬‬
‫כהכנה לתרגיל המשולש נתונה טבלת מחלקות תואמות – )‪? )equivalence classes‬‬
‫‪ -A‬הנושא לבדיקה ‪ -B‬ערך קיצון למשתנים ‪ -C‬הדרישה המכוסה ‪ -D‬תשובה לשאלה האם‬
‫הצליחה הבדיקה‬
‫מחלקות מקבילות )‪ (equivalent classes‬הן‪ :‬קבוצות ערכי קלט ופלט המייצגות מצבים‬
‫עקרוניים זהים (להתנהלות התוכנה) בתהליך הבדיקה‬
‫‪ Testing‬בדיקות מונחות סיכון משמעו שיטת בדיקה המבוססת על מנגנון של סיכול סיכונים ‪-‬‬
‫קודם עוסקים בסיכון הגבוה‬
‫איזו רשימה מייצגת דרגות הבדיקה (‪Unit Test, Sub System test, ?)testing levels‬‬
‫‪System Test, User acceptance test‬‬
‫איזו מהרשימה אינן מייצגת דרגות הבדיקה ( ‪Code Testing, API ? ) testing levels‬‬
‫‪Testing, Objet Testing, Application Testing‬‬
‫מתי נשתמש בטכניקת בדיקות הקצה (‪ ?)boundary testing‬כאשר נרצה לדעת מה קורה‬
‫במקרי קצה (למשל בקצוות מחלקות בדיקה)‬
‫אנלוגית שדה המוקשים מתייחסת ל‪ :‬סוגית כסוי הבדיקות ומציאת באגים נוספים באמצעות‬
‫בדיקות רגרסיה במצבים דומים‬
‫‪ Exploratory testing‬היא‪ :‬גישה מהירה לגלוי מוקדם וזריז של תקלות באופן אינטואיטיבי –‬
‫אינה מתיימרת להחליף שום מנגנון אחר‪.‬‬
‫מערכת קלט באינטרנט נדרשת לאפשר התחברות של ‪ 10,000‬לקוחות בו זמנית‪.‬‬
‫איזה סוג בדיקה נכונה לדרישה ? בדיקות עומס איזה סוג בדיקה מתאימה פחות ?בדיקות‬
‫התאמה‬
‫מערכת באינטרנט נפלה לאחר התחברות של ‪ 10,000‬לקוחות בו זמנית‪ .‬איזו בדיקה לא‬
‫התבצעה ?בדיקות עומס‬
‫אנשי המפתח בפרויקט הבדיקות הם‪ :‬מנהל הפרויקט‪ ,‬אנשי תשתיות‪ ,‬ראשי צוותים‪ ,‬בודקים‬
‫בחינת כמות ה ‪ Function points‬עשויה לשמש ל‪ :‬מדד למורכבות התוכנה ואינדיקאטור‬
‫לכמות התיעוד והשגיאות שניתן יהיה לצפות ממנה‪.‬‬
‫קבוצת ה ‪ SCRUM‬היא קבוצה‪ :‬קבוצת עבודה בסיסית המכילה את כל הפונקציות הנדרשות‬
‫בתהליך הפיתוח ולוקחת אחריות כוללת על מה שייצרה‪.‬‬
‫מהם הרכיבים מהם מורכב ה ‪ Test Case‬מטרה‪ ,‬ערכי קלט‪ ,‬התהליך‪ ,‬ערכי פלט‪ ,‬אורקל‬
‫עקרונות ה ‪ time box‬מאפשרים פיתוח ‪:‬עבודה במקביל של מהלכי פיתוח על גירסה נוכחית‬
‫ואינטגרציה בגירסה קודמת‬
‫שפת ה ‪ WSDL‬היא שפה ל‪:‬שפה פורמליסטית המאפשר הגדרת שירותים בעולם ה ‪WEB‬‬
‫המכילה הגדרות‪,‬פעולות וקשרים‬
‫אלו משמונת העקרונות של ‪ SOA‬הכי דומה לשיטת הקופסה השחורה בבדיקות?‬
‫***עקרון ה‪ Service Abstraction :‬המסתיר את מבנה ואופן השימוש בשרות באמצעות תיאור‬
‫פורמליסטי ***עקרון ה‪ Service Statelessness :‬המתייחס לשרות כאילו הוא בן מהלך אחד‬
‫בלבד ולא מפורק לגורמים‬
‫סביבת בדיקה לבדיקות אוטומטיות של תוכנה כוללת? מערכת הפעלה מסוימת‪,‬ורסיה מסוימת‬
‫של תוכנה‪ ,‬תשתית הפעלה והרצה לתהליך הרצוי‪,‬נתונים מתאימים להרצת התהליך‬
‫הנבדק‪,‬תשתית להפצת תוצאות הבדיקה לכל מי שצריך לדעת על התוצאות‪.‬‬
‫מודל המפץ הגדול חוזקתו היא ביכולת לעבוד במקביל‬
‫מודל הקוקומו מיועד ל אחד ממודלי הערכת העלויות לפרויקט התוכנה‬
‫בשיטת ה ‪ Model Based Testing‬מחוללים תהליכי בדיקות על פי‪ :‬מידול התהליך הנבדק‬
‫מתוך ה ‪ UML‬וחילול מקרי הבדיקה הנובעים ממודל זה‬
‫מדוע מודל ה ‪ COCMO2‬הינו מודל מתכנס ככל שהפרויקט מתקדם כמות הפרמטרים שנכנסים‬
‫למודל עם התקדמות הפרויקט יותר קטנה לכן דרגות החופש מועטות ומודל מתכנס‬
‫מודל הספירלה הינו‪ :‬מודל חיים של פרויקט אג'ילי ( ‪ ) AGILE‬משום שממלא אחרי כל התנאים‬
‫שמוגדרים במניפסט האג'ילי והסיבה שלא יישמו אותו היא שהקדים את זמנו‬
‫‪ RUP - Rational Unified Process‬הוא מודל מחזור חיים ש‪ :‬מייצג הרבה פרויקטי מפל מים‬
‫קטנים המופעלים אחד בשלוב השני‬
‫הבעיה העיקרית של מודל המפץ הגדול היא‪ :‬לא ניתן לזהות מהיכן הגיעה תקלה מסוימת כי בבת‬
‫אחת הוכנסו לתוך המערכות המון מודולים חדשים‬
‫מודל רשת הנוירונים מדגים אפשרות ל‪:‬להשתמש בניסיון המצטבר של הרבה פרויקטים על מנת‬
‫ליצור מודל לומד להערכת עלויות הפרויקט‬
‫‪ Virtual machine‬משמשים בעולם הבדיקות ל‪ :‬ליצר משאבי בדיקות (סביבות ומכונות) וכך‬
‫לחסוך הרבה כסף ומשאבים‬
‫למה קשה לבדוק ‪ SOA‬עדיין אין כלים ותשתיות מתאימות לבדוק ‪ SOA‬כראוי – הכלים היחידים‬
‫המתייחסים ל ‪ SOA‬שכבר פותחו הם כלים לבדיקת‪ , WEB SERVICES‬מה לעשות ש‪ SOA‬היא‬
‫ארכיטקטורה רב שכבתית שהשרות ברשת הוא רק קצהו של הקרחון‪.‬‬
‫ב ‪ State Diagram MBT‬הינו תרשים המציג את ה מרחב המצבים והקשרים בינהם בהם יכול‬
‫לזרום מודל מסוים ממנו צריך הבודק לבחור תסריט בדיקה מסוים‬
‫סקירת קוד – )‪ (Code review‬הוא תהליך המיועד ל‪ :‬לזהות בעיות אפשריות ולהצביע על‬
‫שגיאות עוד לפני הפעלת התוכנה‬
‫אלו מבין התהליכים הבאים נכון לגבי סקירת קוד )‪*** : (Code Review‬בדיקת התוכנה עוד‬
‫לפני שהופעלה ***תהליך מומלץ שיקדים את בדיקת התוכנה המורצת‬
‫מהי הסיבה לתקלה שהתגלתה במרכזת ה ‪ :Telenova‬לא הביאו בחשבון שצריך לנקות את‬
‫המצביעים כאשר מי שהתקשר סגר את הטלפון במקום להמתין לשלוחה‬
‫מהי הסיבה בגללה לא הצליחו לזהות את הבעיה במרכזת ‪ Telenova‬במסגרת הבדיקות‬
‫השגרתיות? לא ניתן היה לבדוק כמות כל כך גדולה של קומבינציות של ריצת המערכת‬
‫מהי הסיבה בגללה הצליחו לזהות את הבעיה במרכזת ‪ Telenova‬רק ביציאה לייצור? רק אז‬
‫הועמסה המערכת עד כדי לחץ והגיע לידי ביטוי המצב המיוחד של זליגת זיכרון‬
‫אנליזה דינמית של קוד היא שיטת ניתוח הקוד המתבססת על אינסטרומנטציה של פקודות בתוכו‪.‬‬
‫מטריצת מעקב ‪ Traceability matrix‬משמשת ל‪ :‬מאפשרת לדעת איזה תקלה השפיעה על‬
‫איזו דרישת משתמש‬
‫מהו האורקל בבדיקות התוכנה? יענה על השאלה ‪ -‬באיזה אופן ניתן לדעת שתוצאות הבדיקה‬
‫חיובית או שלילית‬
‫למה קשה למכן את מנגנוני ה ‪Test Oracle‬כי המנגנון צורך התערבות בן אדם בכל החלטה‬
‫מסובכת‬
‫למה קשה למכן את האורקל ? האורקל היחידי שניתן למימוש בקלות יחסית הוא מנגנון השוואה‬
‫לתוצאות מצופות – האם ערך מסוים מתאים לציפיות‪ .‬כאשר אנו מצפים לאורקל יותר מורכב ‪-‬‬
‫נתקשה לממש חוקים מורכבים‬
‫למה קשה למכן את האורקל של הבדיקות? ***חוקי האורקל מפעילים אופרטורים לוגיים על‬
‫תוצאות הבדיקה – אולם חייבים להבין את תוצאות הבדיקה מראש ולכן קשה למכן מגוון כל כך‬
‫רחב של מצבים ***האורקל הוא תלוי לוגיקה עסקית של ההרצה ולכן מאוד קשה להכליל חוקים‬
‫ומנגנונים לכל מקרי הבדיקה מראש*** נכונות בחלקן אבל יש להוסיף בעיות לוגיסטיות של הקושי‬
‫להגיע לנתונים מוצפנים‪ ,‬מכווצים‪ ,‬ו‪/‬או בעלי כתובות דינמיות‪.‬‬
‫ההבדל בין פתרון – ‪ Solution‬לבין מוצר‪ Product -‬של תוכנה מתבטא ב‪ :‬ארכיטקטורת‬
‫התוכנה שונה לחלוטין ‪ -‬במוצר חלק שלא ניגע בו אף פעם (גרעין – ‪ ) CORE‬והיתר מותאם ללקוח‬
‫ואילו בפתרון הכול פתוח וניתן לשנת ולהתאים כל קוד ללקוח‪.‬‬
‫הרבה פרויקטים בתוכנה נוטים לא להסתיים משום‪*** :‬עד שהסתיימו תהליכי ההטמעה שלהם‬
‫אינם מתאימים יותר למציאות המשתנה‪ *** .‬בגלל מורכבותם אינם מגיעים לסופם כמו שציפו‬
‫בהתחלה *** במהלך רוב הפרויקטים ישנים שינויים רבים בדרישות‬
‫‪ Execution Point‬משמשות ל‪ :‬מנגנון לאמידה יותר טובה את גודל ומורכבות ה ‪TC‬‬
‫להלן רשימת רכיבים עיקריים לפרויקט בדיקות איזו סעיף מכסה יותר מידע לצורך חישוב‬
‫עלויות העבודה ? כמות ומורכבות הדרישות‪ ,‬זמינות כוח אדם לבדיקה‪ ,‬יעלות הבודקים‪ ,‬נגישות‬
‫הלקוחות‪ ,‬נגישות המפתחים לבודקים‪ ,‬לוח זמנים לביצוע‪ ,‬עלות להקמת סביבת בדיקה‪ ,‬מידת‬
‫המקצוענות של הבודקים‪ ,‬זמינות כלים אוטומטיים לבדיקות‬
‫בתרשים זרימת תקלות )‪ (Defect Flow‬מי צריך לסגור את התקלה?שונה לכל סוג סגירה‬
‫בהתאם למי שהוכרז כרשאי‬
‫בדיקות מונחות סיכון הן בדיקות שנבנו על פי מידת הסיכון שארגון ייחשף אליו אם הנושא לא‬
‫יעבוד כראוי‬
‫נתיב קריטי בפרויקט בדיקות? אין שום ייחוד בנתיב הקריטי בפרויקט הבדיקות גם כאן הוא מייצג‬
‫את המסלול המגביל (על פי המשאבים) של הפרויקט‬
‫סקראם הוא תהליך אג'ילי בנוי על בסיס של קבוצת עובדים מתחומים שונים‬
‫המושג טכניקות בדיקה מתייחס ל אופנים שונים לגיבוש מהלכי הבדיקות בהתאם לראיית צרכים‬
‫אחרים‬
‫מהי בדיקה תהליכית?בדיקות הכוללות רצף של פעולות פונקציונאליות לאורך ציר הזמן‬
‫הקשר בין עלות תיקון הבאג למתי מוצאים אותו קשר ישר‪ -‬עלות תיקון הבאג ומתי מוצאים אותו‬
‫קשורים מוקדם יותר = זול יותר‬
‫כאשר מסתכלים על הקוד‪ ,‬המבנים הבסיסיים )‪ (primitives‬של התוכנה זיהוי שלהם עשוי‬
‫לאפשר לנו לקצר מאוד את תהליכי הבדיקות‬
‫תהליך צמצום‪ -‬איתור יחידות פנימיות (פרימיטיבות) מאפיין מהלך של ‪:‬בחינת המורכבות‬
‫‪ complexity‬והאיכות של הקוד‬
‫איזו בדיקה ניתן לבצע בעזרת סריקת קוד בדיקת ‪.complexity‬‬
‫‪ Product Backlog‬היא רשימת מטלות‪ :‬שהסדר שלה משתנה כל מחזור בהתאם לצרכים‬
‫אנשי המפתח בפרויקט הבדיקות הם‪:‬מנהל הפרויקט‪ ,‬אנשי תשתיות‪ ,‬ראשי צוותים‪ ,‬בודקים‪.‬‬
‫תהליך ה ‪ CMMi‬הוא תהליך השתפרות מובנה המאפשר לארגון פיתוח התוכנה לשפר את כלל‬
‫תפקודיו‬
‫לפני תחילת הטיפול בשגיאה שהתגלתה‪ ,‬יש להגדיר‪ :‬מהי דרגת החומרה של השגיאה‪ ,‬מידת‬
‫הדחיפות‪.‬‬
‫הגדרת טבלאות החלטה‪ :‬טבלאות המציגות קומבינציות של קלטים ו‪/‬או סיבות יחד עם הפלטים‬
‫ו‪/‬או התוצאות שלהם אשר ניתן להשתמש בהן לתכנון מקרי הבדיקה‪.‬‬
‫קודי סטאטוס טיפול בשגיאה הם‪ :‬סטאטוס המתאר מצב הטיפול בשגיאה בכל רגע נתון‬
‫הטבלה הבאה מציינת דוח סטאטוס בפרויקט בדיקות‪ ,‬מהן העמודות?‬
‫(‪)a‬‬ ‫(‪)b‬‬ ‫(‪) c‬‬ ‫(‪)d‬‬ ‫(‪)e‬‬
‫‪Unit Test‬‬ ‫‪1200‬‬ ‫‪1160 898‬‬ ‫‪26‬‬ ‫‪0‬‬ ‫כמות הטסטים המתוכננים ‪(a) -‬‬
‫‪Component test 498‬‬ ‫‪496‬‬ ‫‪400‬‬ ‫‪3‬‬ ‫‪3‬‬ ‫כמות הטסטים שבוצעו ‪(b) -‬‬
‫‪Package test‬‬ ‫‪1000‬‬ ‫‪756‬‬ ‫‪690‬‬ ‫‪22‬‬ ‫‪0‬‬ ‫כמות הטסטים שעברו‪) c) -‬‬
‫‪Integration‬‬ ‫‪500‬‬ ‫‪490‬‬ ‫‪410‬‬ ‫‪23‬‬ ‫‪2‬‬ ‫מספר השגיאות שנפתחו ‪)d) -‬‬
‫‪Totals‬‬ ‫‪3198‬‬ ‫‪2932 2398‬‬ ‫‪88‬‬ ‫‪5‬‬ ‫מספר השגיאות הפתוחות ‪)e) -‬‬
‫‪-1‬הגדרת תכולת הבדיקה‬
‫‪-2‬סיום עיצוב הבדיקות‬
‫‪ -3‬מוכנות לבדיקה‬
‫‪ -4‬מוכנות להתקנה‬