סיכונים בבדיקות אוריאלה כהן מאי 2012 נובמבר 18 אוריאלה כהן

נושאים הגדרות מהם סיכונים בבדיקות? סיכונים בניהול הפרויקט השפעת הפיתוח על הבדיקות Risk Based Testing (RBT) למה צריך? המודל הקלאסי (תיעדופים) המודל האירואיסטי (Heuristic RBT) Taxonomies מדדים בבדיקות נובמבר 18 אוריאלה כהן

הגדרות איכות: סיכון: "התאמה לדרישות" [Conformance to Requirements” Phil Crosby"] "התאמה לשימוש" [Fittness for Use” J.M. Juran’s"] סיכון: "אירוע עתידי אפשרי, שאם יקרה – יגרום לתוצאות לא רצויות" [Leishman & VanBuren] "האפשרות שתקלה בתוכנית תגרום לנזק עסקי" [Steve Wakeland] נובמבר 18 אוריאלה כהן

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

סיכונים בניהול הפרויקט נובמבר 18 אוריאלה כהן

קצת סטטיסטיקה.... 53% מהפרויקטים הושלמו, אבל בעלות גבוהה מהמתוכנן ובלו"ז ארוך יותר. 31% מהפרויקטים בוטלו לפני שהושלמו סיבות לכישלונות: 65% בגלל נושאים ניהוליים מבנה פרויקט לא טוב משאבים לא מספיקים / לא מיומנים ללא תכנון ומתודולוגיות ללא ניהול סיכונים 35% בגלל נושאים טכניים תכנון מערכת לקוי אי-התאמה לדרישות פיתוח לא יעיל / לא תקין מתודולוגיות פיתוח ובדיקות לא טובות נובמבר 18 אוריאלה כהן

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

השיטה הקלאסית מתבצע בתכיפות קבועה לאורך כל חיי הפרויקט נובמבר 18 אוריאלה כהן

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

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

ניתוח וכימות הסיכונים הערכת הסיכוי שהסיכון יתממש (תחום ערכים) הנזק שעלול להיגרם בגינו (תחום ערכים) רמת הסיכון = סיכוי * נזק נזק 5 4 3 2 1 5 10 15 20 25 4 8 12 16 20 3 6 9 12 15 2 4 6 8 10 1 2 3 4 5 סיכוי 5 4 3 2 1 נובמבר 18 אוריאלה כהן

הגדרת פעולות התעלמות סיכון סיכוי נזק רמה פעולה סיכון סיכוי נזק רמה פעולה הספק לא יבצע בדיקות 3 5 15 [1] ביצוע בדיקות בחברה באיכות הנדרשת [2] מציאת ספק אחר הדרישות לרכיב X לא יוגדרו 2 3 6 לדחות את לוחות הזמנים בזמן הבודקים לא מכירים את כלי 5 3 15 לא להשתמש בכלי העזר העזר שנבחר התעלמות נובמבר 18 אוריאלה כהן

הגדרת פעולות הגדרת פעולות העברה סיכון סיכוי נזק רמה פעולה סיכון סיכוי נזק רמה פעולה הספק לא יבצע בדיקות 3 5 15 להגדיר מדדי קנסות לאיכות באיכות הנדרשת הדרישות לרכיב X לא יוגדרו 2 3 6 לחייב את הלקוח על איחורים בזמן הבודקים לא מכירים את כלי 5 3 15 לסדר גישה חופשית לכלי ללימוד העזר שנבחר העברה נובמבר 18 אוריאלה כהן

הגדרת פעולות הגדרת פעולות פעולה סיכון סיכוי נזק רמה פעולה סיכון סיכוי נזק רמה פעולה הספק לא יבצע בדיקות 3 5 15 לשים איש מקצועי שיעבוד באיכות הנדרשת עם הספק ויבקר את עבודתו הדרישות לרכיב X לא יוגדרו 2 3 6 מעקב שוטף בזמן הבודקים לא מכירים את כלי 5 3 15 העזר שנבחר פעולה גידור ניטור קבלה נובמבר 18 אוריאלה כהן

מעקב תקופתי מעקב סיכונים קיימים, זיהוי סיכונים חדשים סיכון סיכוי נזק רמה פעולה אחראי ת. יעד סטטוס ת. סטטוס הספק לא יבצע בדיקות 3 5 15 באיכות הנדרשת הדרישות לרכיב X לא 2 3 6 יוגדרו בזמן הבודקים לא מכירים 5 3 15 את כלי העזר שנבחר תוספות: תאריך דיווח סיכון, רכיב מערכת, אחראי רכיב...... נובמבר 18 אוריאלה כהן

מהו הסיכון הגדול ביותר?..... לא לדעת מה הם הסיכונים!! נובמבר 18 אוריאלה כהן

השפעת הפיתוח על הבדיקות נובמבר 18 אוריאלה כהן

השפעת הפיתוח על הבדיקות מתודולוגיה של פיתוח Big-Bang איטרציות (כמו Agile) UML רציף ועוד השפעות / סיכונים דורש התאמת שיטת הבדיקות דורש התאמת לוחות זמנים (איטרציות, UML) סיכון לאיבוד שליטה על הנושאים הנבדקים (רציף) סיכון לפשרות לא נשלטות (רציף) דורש קשר הדוק במיוחד מול פיתוח (בעיקר UML, רציף) נובמבר 18 אוריאלה כהן

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

השפעת הפיתוח על הבדיקות אי-שילוב הבודקים בדרישות / אפיון השפעות / סיכונים סיכון לאי עמידה בלוחות הזמנים סיכון לאי-הבנות של תפקוד המערכת אין אפשרות לזיהוי תקלות מוקדם נובמבר 18 אוריאלה כהן

השפעת הפיתוח על הבדיקות קשר לקוי בודק-מפתח: בזמן תכנון הבדיקות בזמן ביצוע הבדיקות השפעות / סיכונים: כתיבת בדיקות שאינן תואמות מערכת דיווח על תקלות שאינן תקלות עבודה לא יעילה ולא בזמן נובמבר 18 אוריאלה כהן

השפעת הפיתוח על הבדיקות איכות לקויה של מסמכי הדרישות / האפיון השפעות / סיכונים: כתיבת בדיקות שאינן תואמות מערכת דיווח על תקלות שאינן תקלות בזבוז זמן מיותר על שאלות / הבהרות עבודה לא יעילה ולא בזמן תלוי גם בקשר בודק-מפתח נובמבר 18 אוריאלה כהן

השפעת הפיתוח על הבדיקות ניהול סביבת העבודה: בשליטת גוף הבדיקות בשליטת גוף הפיתוח השפעות / סיכונים כאשר השליטה היא של גוף הפיתוח: העברת גרסת מערכת / Build שלא בהתאמה לעבודת הבודקים ריענון נתונים שלא בהתאמה לעבודת הבודקים כפילות עבודה ניהול נתונים מורכב כאשר ישנם "שותפים" לסביבה נובמבר 18 אוריאלה כהן

השפעת הפיתוח על הבדיקות טיפול במאפייני תקלות: אחריות הפיתוח? אחריות הבודקים? השפעות / סיכונים כאשר השליטה היא של גוף הפיתוח: שינויים לא מבוקרים לדרגת החומרה של התקלות שינויים לא מבוקרים של סטטוס התקלות סיכון בהערכת איכות המערכת נובמבר 18 אוריאלה כהן

בדיקות מנוהלות סיכונים (RBT)Risk Based Testing נובמבר 18 אוריאלה כהן

סיכונים בתכנון וביצוע בדיקות “There never is time to do it right, but there’s always time to do it over” לא ניתן לתכנן ולבצע את כל הבדיקות האפשריות The Pesticide Paradox מערכת הנבדקת שוב ושוב עם אותן בדיקות (קוטל חרקים) נהיית "מחוסנת" מפניהן. נובמבר 18 אוריאלה כהן

השיטה הקלאסית [מבוססת תיעדוף] נובמבר 18 אוריאלה כהן

השיטה הקלאסית הנזק שייגרם: נזק כספי על הארגון נזק כספי למשתמשים כמות משתמשים תכיפות השימוש נזק למוניטין עצירת עבודה שוטפת הסיכוי לתקלה: רמת מורכבות מרכזיות נושאים שמשתנים לעיתים תכופות טכנולוגיה חדשה מספר האנשים המעורבים בבניית הנושא לחץ זמן היו בעבר הרבה תקלות לא נבדק כראוי עד כה רגיש בהיבט אבטחת מידע דרישות / אפיון לא שלמים נובמבר 18 אוריאלה כהן

חישוב רמת הסיכון ערך מספרי בתחום מוגדר (כמו: 1-5, כאשר 5 = גבוה, 1 = נמוך): 5 (סיכוי) * 3 (נזק) = 15 (רמת סיכון) על בסיס פרמטרים ותחום ערכים לכל פרמטר: סיכוי = 3 (מורכבות) + 2 (טכנולוגיה) + 4 (מרכזיות) = 9 נזק = 2 (משתמשים) + 1 (כספי) + 5 (תכיפות) = 8 רמת סיכון = 9 * 8 = 72 הוספת משקל לכל פרמטר: סיכוי = 3 (מורכבות) * 0.5 + 2 (טכנולוגיה) * 0.3 + 4 (מרכזיות) * 0.2 = 2.9 נזק = 2 (משתמשים) * 0.4 + 1 (כספי) * 0.4 + 5 (תכיפות) * 0.2 = 2.2 רמת סיכון = 2.9 * 2.2 = 6.38 נובמבר 18 אוריאלה כהן

דוגמא לטבלת סיכונים נושא נזק עסקי כמות משתמשים מורכבות תכיפות שינויים רמת סיכון משקל 0.6 0.4 0.5 0.5 הרשמה 2 4 5 1 2 * 3 חשבונית 4 5 4 2 4.4 * 3 דו"ח כספי 2 1 2 4 1.6 * 3 סיכוי לתקלה הנזק שייגרם נובמבר 18 אוריאלה כהן

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

אם זה כל כך יפה – מה לא טוב? מתמטיקסם? האם ההבדל בין 1 ל- 2 דומה להבדל בין 4 ל- 5? מה הסיכוי לתקלה? תמיד 100%!!!!!!!! מה המשמעות של סיכון ברמה 25 לעומת סיכון ברמה 20? רמת הנזק של תקלה.... איזו תקלה? נובמבר 18 אוריאלה כהן

(HRBT)Heuristic Risk Based Testing איכות: זה לא "כמה אנחנו בודקים", אלא "מה אנחנו בודקים" נובמבר 18 אוריאלה כהן

הגישה ההאוריסטית לבדיקות תוכנה הגדרה: גישה מבוססת ניסיון שעוזרת בפתרון בעיות, לימוד וגילוי. שלוש גישות: Inside-Out – מציאת הסיכונים הקשורים לכל רכיב במערכת Outside-In - מציאת הרכיבים המקושרים לסיכון ספציפי FMEA (Failure Mode & Effect Analysis) המשלב את שתי הגישות הקודמות נובמבר 18 אוריאלה כהן

HRBT – Inside-Out מציאת הסיכונים האפשריים לכל פונקציה / רכיב במערכת הנבדקת. איך עושים את זה?..... לפרק את המערכת לרכיבים 1. לדמיין איך הרכיב יכול "ליפול" 2. להגדיר בדיקות שיציפו את ה"נפילות" האפשריות האלו נובמבר 18 אוריאלה כהן

HRBT – Inside-Out דורש: מאמץ משותף מול המפתח ו - הבנה מעמיקה ברכיב/פונקציה יצירתיות בהגדרת סיכונים נובמבר 18 אוריאלה כהן

HRBT – Outside-In מציאת הרכיבים המקושרים לסיכון ספציפי עבודה על בסיס רשימות וקטלוגים של סיכונים נובמבר 18 אוריאלה כהן

HRBT – Outside-In - דוגמאות Generic Risk Lists Generic risks are risks that are universal to any system. Complex - anything disproportionately large, intricate, or convoluted New - anything that has no history in the product Changed - anything that has been tampered with or "improved" Upstream Dependency - anything whose failure will cause cascading failure in the rest of the system Critical - anything whose failure could cause substantial damage Precise - anything that must meet its requirements exactly Popular - anything that will be used a lot Strategic - anything that has special importance to your business, such as a feature that sets you apart from the competition Third-party - anything used in the product, but developed outside the project Law - anything that must comply with the law or other standards Buggy - anything known to have a lot of problems נובמבר 18 אוריאלה כהן

HRBT – Outside-In - דוגמאות Installation Risk Catalog Wrong files installed Temporary files not cleaned up Old files not cleaned up after upgrade Unneeded file installed Needed file not installed Correct file installed in the wrong place Files clobbered Older file replaces newer file User data file clobbered during upgrade Other apps clobbered File shared with another product is modified File belonging to another product is deleted Hardware not properly configured Hardware clobbered for other apps Hardware not set for installed app Screen saver disrupts install No detection of incompatible apps Apps currently executing Apps currently installed Installer silently replaces or modifies critical files or parameters Install process is too slow Install process requires constant user monitoring Install process is confusing User interface is unorthodox User interface is easily misused Messages and instructions are confusing [By James Bach] נובמבר 18 אוריאלה כהן

FMEA – Failure Mode & Effect Analysis "שיטה לזיהוי הסיכונים בכל אחד מרכיבי המערכת, ההשפעה שלהם על התנהגות המערכת והגדרת פעולות שימנעו או יצמצמו את הסיכונים האלה". Failure Mode = האופן בו המערכת/התוכנית עלולה ליפול (=סיכון) הייתה בשימוש לראשונה ב- 1960 בתעשיית אווירונאוטיקה בארה"ב, בפיתוח "אפולו" ב- 1974 צבא ארה"ב פיתח את הסטנדרט MIL-STD-1629 ב- 1980 תעשיית המכוניות החלה ליישם שיטה זו כיום הותאמה לפיתוח מערכות תוכנה: לשלבי תכנון המערכות, הפיתוח ובדיקות התוכנה. נובמבר 18 אוריאלה כהן

FMEA – Failure Mode & Effect Analysis בודק חייב לעבוד בשיטה מסודרת שתענה על השאלות: מה עלול לא לעבוד במערכת/תוכנית/רכיב? כמה "מכוערת" ומזיקה תהייה התקלה? כיצד ניתן למנוע אותה בעתיד? שיטת FMEA מאפשרת לבודק לגלות באופן שיטתי את הבעיות האפשריות (FM). חלק ה- EA מטפל בניתוח ההשלכות של בעיות אלו. ניתן מראש למנוע בעיות רבות אם התהליך מתבצע בשלבים מוקדמים (תכנון, עיצוב, קידוד) של בניית המערכת/התכנית/הרכיב, נובמבר 18 אוריאלה כהן

FMEA – השיטה [1] איזו תקלה אפשרית? איך תמצאו את התקלה? מי יושפע מהתקלה? כמה מסוכנת תהייה התקלה? כמה השקעה תידרש בכדי למצוא את התקלה? כמה השקעה נדרשת בכדי לתקן את התקלה? נובמבר 18 אוריאלה כהן

FMEA – השיטה [2] – חלוקה לקטגוריות Computational Logic Data I/O Data handling Interfaces Data definition Data Base Other לרוב הנושאים / סוגי המערכות ישנן רשימות מוכנות (Taxonomies) נובמבר 18 אוריאלה כהן

FMEA – השיטה [3] – חלוקה לקטגוריות Structure Functions Data Platform כל דבר המרכיב את המוצר (לוגי ופיזי) כל דבר שהמוצר עושה כל דבר שהמוצר מעבד כל דבר שהמוצר תלוי בו נובמבר 18 אוריאלה כהן

FMEA – השיטה [4] – פירוט הקטגוריות Structure Database Server Cashe Server Web Server DB Failures Functions Calculations Discount / Coupons Checkout Shipping Navigation Error handling Memory Leaks Data Human Errors Retail Side Customer Side System Security Performance Process Level of Order Taking Payment Processing Platform Network Failure Modes = איך הם יכולים "ליפול"? נובמבר 18 אוריאלה כהן

FMEA – השיטה [5] – הגדרת Failure Modes Data Human Errors Retail Side Customer Side System Security Performance Process Level of Order Taking Payment Processing Platform Network Order taking page does not load New customer registration process not working Login process failed Search process not working Order selection fails Cart process losses state נובמבר 18 אוריאלה כהן

FMEA – השיטה [6] – תוספות ל- FM Quality Attributes Usability Easy to use Easy to learn Max number of clicks Accessible to someone with disabilities Auditory Visual Missing functions Browser compatibility Fault tolerance Easy to maintain Adaptability to other components / systems Installation נובמבר 18 אוריאלה כהן

FMEA – השלבים הבאים ההחלטה מה לעשות עם כל FM תתבסס על RPN: האם להגדיר תרחישים? האם לבצע את התרחישים? האם לתקן את התקלות המתגלות? נובמבר 18 אוריאלה כהן

לא כל התקלות מתוקנות אין מספיק זמן It’s not a bug, it’s a feature! מסוכן מדי לתקן לא כדאי לתקן אבל מה יכול לקרות אם עושים החלטה לא נכונה? נובמבר 18 אוריאלה כהן

לא כל התקלות מתוקנות הקישו במחשבון על ה- PC: (4195835 / 3145727) * 3145727 – 4195835 אם קיבלתם אפס – המחשב שלכם בסדר, אחרת – כנראה יש לכם Intel Pentium CPU ישן המכיל תקלה של חלוקה. התקלה התגלתה תוך כדי מחקר באוניברסיטה בוירג'יניה ופורסמה באינטרנט, דבר שגרר הרבה תגובות ותלונות. הבעיה לא הייתה עם התקלה עצמה אלא עם הדרך שאינטל טיפלו בה: הם היו מודעים לתקלה אבל הניחו שהיא "זניחה" – לא חמורה מדי ובעלת סיכוי נמוך שתקרה, ניסו להפחית מחומרת הבעיה, והסכימו להחליף את הצ'יפ רק למי שיוכיח שהושפע מהתקלה. אחרי לחץ ציבורי, אינטל שילמה M400$ בכדי להחליף את הצ'יפ הפגום לכול המשתמשים. נובמבר 18 אוריאלה כהן

Taxonomies נובמבר 18 אוריאלה כהן

מה זה Taxonomy? מיוונית:Taxis – Arrangement, Nomos – law טקסונומיה: ארגון של אוסף מידע ספציפי עבור מטרה ספציפית. Carl Linnaeus (1707-1778) הראשון המקושר למונח Taxonomy. פרסם את השיטה בספר Systema Naturae שם הוא ארגן את הקבוצות והשמות של חיות וצמחים. השיטה מאוד מורחבת במדעי המחשב, בגלל הצורך. נובמבר 18 אוריאלה כהן

קצת מידע על טקסונומיות המטרות העיקריות של טקסונומיה עבור יישום שיטת FMEA: להשתמש ברשימות קיימות של נושאים וקטגוריות מוגדרים בכדי לתרום לחשיבה לעזור בגילוי יצירתי של Failure Modes לכל נושא או קטגוריה דרך רשימות דורש הרבה עבודה בפעם הראשונה: דורש הבנה מעמיקה של המערכת הנבדקת לרוב חסר מידע היסטורי טקסונומיה של תקלות יכולה לעזור נובמבר 18 אוריאלה כהן

טיפה בים הטקסונומיות... Computer Attacks Taxonomies [Lough, 2001] Types of Attackers [Straub and Widom] Network Security Taxonomy [Jayaram and Morse] UNIX Security Taxonomy [Aslam] Generic System Functional Flaws [Linde] Bug Taxonomy [Beizer, “Software Testing Techniques”] Common Software Errors [Cem Kaner] http://www.logigear.com/logi_media_dir/Documents/whitepapers/Common_Software_Errors.pdf E-Commerce Risks & Failures Taxonomy [Giri Vijayaraghavan] http://testingeducation.org/a/tecrf.pdf נובמבר 18 אוריאלה כהן

תודה!!! נובמבר 18 אוריאלה כהן

נובמבר 18 אוריאלה כהן

בדיקות מסירה 5 3 בדיקות מסירה 3 5 משיכת כספים בשקלים בדולארים נובמבר 18 אוריאלה כהן