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

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

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

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

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

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

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

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

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

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

11. ניתוח וכימות הסיכונים הערכת הסיכוי שהסיכון יתממש (תחום ערכים)
הנזק שעלול להיגרם בגינו (תחום ערכים)
רמת הסיכון = סיכוי * נזק
נזק 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
סיכוי
נובמבר 18
אוריאלה כהן

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

38. 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
אוריאלה כהן

39. 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
אוריאלה כהן

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

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

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

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

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

45. 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
אוריאלה כהן

46. 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
אוריאלה כהן

47. 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
אוריאלה כהן

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

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

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

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

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

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

54. טיפה בים הטקסונומיות... 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]
E-Commerce Risks & Failures Taxonomy [Giri Vijayaraghavan]
נובמבר 18
אוריאלה כהן

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

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

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