Issuu on Google+

‫מה ה–‬ ‫‪ FUNTASY‬שלך?‬

‫כלי בדיקות אוטומטיות ייחודי‬ ‫שיגשים לך את כל הפנטזיות*‬

‫*בתחום בדיקות האוטומציה בלבד‪...‬‬ ‫יושב מעל רוב כלי האוטומציה‬ ‫כגון ‪ QTP, Test Complete‬ועוד‬ ‫מאפשר לבודקים ידניים לתכנן‬ ‫ולהריץ בדיקות אוטומטיות‬

‫מאפשר כתיבת בדיקות אוטומטיות‬ ‫לפני שהמערכת מוכנה‬ ‫משלב בדיקות ‪ Non-GUI‬כגון‬ ‫הרצת ‪API‬‬

‫למידע נוסף ותיאום פגישת היכרות‪:‬‬ ‫‪www.QualiTestGroup.com/FUNTASY FUNTASY@QualiTestGoup.com‬‬


‫מיומנו של בודק תוכנה מתחיל‬

‫מעצור בדיקות‬ ‫כ‬

‫בר כמה וכמה שבועות שאני לא מצליח למצוא‬ ‫אף תקלה בשום דבר‪ .‬אפילו האוכל במסעדה‬ ‫למטה‪ ,‬שאתמול נדרתי בפעם המאה נדר לא‬ ‫לאכול שם יותר‪ ,‬נהייה פתאום טעים‪...‬‬ ‫החבר שלי פישר‪ ,‬אומר שזה בגלל שאני מתפשר‪,‬‬ ‫מסתפק במועט‪” .‬אם באמת תחפש – תמצא את‬ ‫התקלות!“ הוא אומר‪ .‬אני לא מאמין שהוא צודק‪.‬‬ ‫אני מתחיל לחשוב שפשוט אין יותר תקלות בעולם‪.‬‬ ‫לראיה‪ ,‬בגרסה האחרונה של המערכת‪ ,‬הדבר היחיד‬ ‫שמצאתי שלא התאים לאיפיון היה הצבע של‬ ‫הכפתור כיבוי שהיה ורוד ולא אדום‪ .‬לי זה לא נראה‬ ‫כמו תקלה‪ .‬אני חושב שזה ממש התאים לממשק‬ ‫המשתמש ואפילו יוכל למצוא חן בעיני המשתמשות‬ ‫העתידיות )ואפילו חלק מהמשתמשים‪.(...‬‬ ‫פתאום החבר‘ה מהפיתוח התחילו לחבב אותי‪,‬‬ ‫וזה אחרי שלפני שבועיים כמעט הלכנו מכות אחרי‬ ‫שאמרתי להם שהם מייצרים יותר באגים משורות‬ ‫קוד‪ .‬פתאום מצאתי את עצמי מחמיא להם על איכות‬ ‫העבודה ונטולת הבאגים שלהם‪ .‬פישר אומר שאני‬ ‫סתם חנפן אבל אני חושב שהוא קצת מקנא משום‬ ‫שאתמול בצהרים הם הזמינו אותי לארוחה על חשבון‬ ‫כרטיסי הסיבוס שלהם‪.‬‬ ‫מה קורה לי? האם איבדתי את היכולת להיות בודק?‬ ‫ודווקא אחרי שהרגשתי בשבועות האחרונים שהולך‬

‫פתאום החבר‘ה‬ ‫מהפיתוח התחילו‬ ‫לחבב אותי‪ ,‬וזה אחרי‬ ‫שלפני שבועיים‬ ‫כמעט הלכנו מכות‬ ‫אחרי שאמרתי להם‬ ‫שהם מייצרים יותר‬ ‫באגים משורות קוד‪.‬‬ ‫פתאום מצאתי את‬ ‫עצמי מחמיא להם על‬ ‫איכות העבודה ונטולת‬ ‫הבאגים שלהם‪.‬‬

‫לי ממש טוב )את הגרסא שלפני חודשיים עצרו‬ ‫בגלל באג שמצאתי ברגע האחרון(? האם עליי‬ ‫לחפש עבודה אחרת? אומרים שהעולם נראה ורוד‬ ‫דרך עיניים אדומות‪ .‬איפה לעזאזל קונים צבע אחר‬ ‫לעיניים?‬ ‫הרי רק לפני כמה שבועות ישבתי עם פישר ואמרנו שאי‬ ‫אפשר לעבוד יותר בגלל כל הבאגים במערכת‪ .‬איפה‬ ‫שלא נגענו מצאנו באג‪ .‬אפילו תכננו לשכתב את קורות‬ ‫החיים שלנו ולנסות למצוא עבודה במקום שעובד יותר‬ ‫מסודר ובלי כל כך הרבה באגים‪ .‬פתאום התמלאתי‬ ‫בתחושת ריקנות כאילו אין לי בשביל מה לעבוד‪ .‬יכול‬ ‫להיות שאני חווה את משבר גיל הארבעים עוד לפני‬ ‫שמלאו לי ‪?25‬‬ ‫המנהל שלי זימן אותי לשיחה‪ .‬בדרך כלל השיחות‬ ‫איתו מסתכמות בהחלפת כאפות חברותיות על‬ ‫העורף במסדרון‪ ,‬אז קבלת זימון רשמי במייל בהחלט‬ ‫מדליקה נורה אדומה )או לפחות ורודה(‪” .‬אתה בודק‬ ‫תוכנה‪ ,‬ובודקי תוכנה אמורים למצוא תקלות!“ הוא‬ ‫הטיח בי‪” .‬חיפשתי‪ ,‬אבל באמת שאין!“ החזרתי‪ .‬הוא‬ ‫קם מהכיסא שלו‪ ,‬התקרב אלי עד שהיינו במרחק‬ ‫סנטימטרים ספורים בלבד ושאל בטון מאשים ”אם‬ ‫כך‪ ,‬אז איך אתה מסביר את זה שפישר מצליח למצוא‬ ‫תקלות? אתה בטוח שבאמת הכל כל כך מושלם‬ ‫במערכת?“‪ .‬אחרי שמלמלתי כמה מילים מתוך פחד‪,‬‬ ‫החלטתי לנסות גישה מעט שונה ”לא נשבר לך כבר‬ ‫מתקלות? לא מתאים לך קצת שקט בחיים?“‬ ‫המנהל שלי לא חשב פעמיים וענה ”עולם בלי תקלות‬ ‫הוא עולם תקוע!“‬ ‫יצאתי בהרגשה רעה מהשיחה הזו‪ .‬כאילו תפיסת עולמי‬ ‫החדשה על עולם ללא תקלות – קיבלה מהמנהל שלי‬ ‫כאפה חברותית על עורף‪ .‬הצטערתי על שלא שכתבתי‬ ‫את קורות החיים שלי והחלטתי שעכשיו זה הזמן‬ ‫לעשות את זה ולחפש תחום חדש בו אוכל סוף‪-‬סוף‬ ‫למצוא תקלות‪...‬‬ ‫כשהתעוררתי בבוקר מהחלום הזה )כן‪ ,‬מסתבר שהכל‬ ‫היה חלום!(‪ ,‬הרגשתי הרבה יותר טוב‪ .‬תחושת הריקנות‬ ‫עברה לה והגעתי למסקנה שזה בסדר שיש תקלות‪ .‬זה‬ ‫מספק לנו עבודה‪ .‬ובכלל‪ ,‬אני אוהב להיות בודק תוכנה‪.‬‬ ‫בלי תקלות‪ ,‬החיים שלי יהיו הרבה יותר משעממים‪.‬‬ ‫יצאתי ליום חדש ומלא תקלות‪...‬‬

‫מגזין חושבים בדיקות ׀ ינואר ‪ 2011‬׀ ‪39‬‬


‫ביקורת ספר ובלוג איל זילברמן יואל מונטבליסקי‬

‫‪Perfect‬‬ ‫‪Soſtware‬‬

‫‪and other illusions‬‬

‫‪about‬‬ ‫‪testing‬‬ ‫‪Jerry Weinberg‬‬

‫א‬

‫ם במקרה עדיין לא שמעתם על ג‘רי וינברג‪ ,‬עכשיו הזמן לתקן את זה‪.‬‬ ‫וינברג כותב ספרים במשך עשרות שנים כאשר הוא מתמקד בעיקר‬ ‫באיכות ובדיקות‪ ,‬ובין הייתר מכסה גם ייעוץ ופסיכולוגיה‪.‬‬

‫הספר ”‪ “Perfect Software‬בא להפריך תפיסות הרסניות על בדיקות ועל בודקים‪.‬‬ ‫עם תערובת של שנינות‪ ,‬סיפורים‪ ,‬ותובנות מדהימות אשר הביאו לו מעריצים‬ ‫ברחבי העולם‪ ,‬וינברג מפריד במיומנות בין מה צפוי‪ ,‬משמעותי‪ ,‬ואפשרי בבדיקות‬ ‫תוכנה‪ .‬הוא מנפץ מיתוסים ומנווט את הקוראים הרחק מטעויות נפוצות‪.‬‬ ‫וינברג טוען שהוא כתב את הספר מכיוון שראה כל כך הרבה אנשים הסובלים‬ ‫עקב ציפיות מוגזמות מהמודלים הכוזבים של בדיקות תוכנה‪.‬‬ ‫הספר מעלה ומנסה להשיב על שאלות פופולאריות בתחום הבדיקות‬ ‫שעדיין מועלות ורלוונטיות כיום‪ :‬מדוע אנו טורחים לבצע בדיקות‬

‫‪ABAKAS‬‬

‫המלצה על בלוג –‬

‫הבלוג של קטרין פאוול‬ ‫)‪(http://blog.abakas.com‬‬

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

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

‫‪Expected‬‬ ‫‪Bug Level‬‬

‫‪http://blog.abakas.com/2010/11/‬‬ ‫‪expected-bug-levels.html‬‬ ‫הפוסט מדבר על העובדה שבשלבים שונים‬ ‫בפרויקט אנחנו צריכים לצפות לכמויות שונות‬ ‫של באגים )מס‘ באגים חדשים‪ ,‬סה“כ באגים‬ ‫פתוחים וכו‘(‪ .‬תפקידינו כבודקים הוא לזהות‬ ‫באיזה שלב אנו נמצאים‪ ,‬להבין אם כמות הבאגים‬ ‫נמצאת בתוך הנורמה הצפויה ולהתריע במידה‬ ‫ואנו חורגים מאותה נורמה‪.‬‬ ‫העיקרון הזה יכול להישמע פשוט וטריביאלי‪,‬‬ ‫אבל האמת היא שישנם לא מעט בודקים‬ ‫ומנהלים המתקשים להתריע כשהפרויקט‬ ‫שלהם נמצא במצב לא טוב מבחינת כמות‬ ‫הבאגים הפתוחים או כאשר קצב גילוי באגים‬ ‫הוא גבוה או נמוך מהמצופה‪ .‬בנוסף‪ ,‬ישנם‬ ‫בודקים רבים ש לא יודעים להעריך מהיא אותה‬ ‫כמות שתיחשב ”נורמלית“ לכל שלב בפרויקט‬ ‫ובמוצר שלהם‪.‬‬

‫‪They Don’t Have‬‬ ‫‪To Justify‬‬

‫‪http://blog.abakas.com/2010/10/they‬‬‫‪dont-have-to-justify.html‬‬ ‫גם פוסט זה מציף מקרה יומיומי מעניין‪ .‬מקרה בו‬ ‫אנו חושבים שבאג הוא קריטי וחייב להיות מתוקן‬ ‫כבר בגרסה הנוכחית‪ ,‬אבל מישהו ”מעלינו“‬ ‫מחליט לדחות אותו לגרסה הבאה )אם בכלל!(‪.‬‬ ‫הפוסט מזכיר לנו שאותו אדם המחליט לדחות‬ ‫באגים הוא בדרך כלל מנהל או מישהו גבוה‬ ‫בהיררכיה הארגונית‪ .‬בנוסף‪ ,‬נטען שם שזה לא‬ ‫יהיה חכם או מועיל להתעצבן ולהתווכח עם אותו‬ ‫אדם באופן עקרוני‪.‬‬ ‫הפוסט מציע גישה נכונה יותר במידה ואתם לא‬ ‫מסכימים או חושבים שזו טעות לדחות את הבאג‪.‬‬ ‫יש לוודא שההחלטה התקבלה אחרי שהמצב‬ ‫וחומרת הבאג הובנו כהלכה‪ ,‬ולא לדרוש הסברים‬ ‫או הצדקות —‬ ‫‪“Seek confirmation of understanding,‬‬ ‫”‪not justification‬‬

‫‪ 38‬׀ מגזין חושבים בדיקות ׀ ינואר ‪2011‬‬

‫‪27-Dec-10 11:14:27 AM‬‬

‫‪Book_Review.indd 38‬‬


‫שרגילה לפתח מוצר ‪ /‬גרסה בטווח של שנה ועוברת לשיטה שבה בכל ‪ 3‬שבועות‬ ‫מוציאים “חלקי מוצר” עובדים וגמורים לייצור‪.‬‬ ‫על מנת להצליח לעמוד בלוחות זמנים קצרים כאלו המודלים האג’ילים כוללים‬ ‫בחובם עוד לא מעט טכניקות ושיטות לייעול הפיתוח והבדיקות כגון‪ :‬פיתוח‬ ‫מונחה בדיקות (‪ ,)TDD‬פיתוח בדיקות קבלה במקביל לפיתוח הפיצ’רים (‪,)ATTD‬‬ ‫שימוש נכבד ב‪ exploratory testing -‬כשיטה מובילה לבדיקות‪ ,‬הטמעת‬ ‫תהליכי אוטומציה בפיתוח ובבניית בילדים (‪ )continuous integration‬והרבה‬ ‫שימוש בתעדוף על בסיס ניתוח סיכונים (‪.)risk based testing‬‬ ‫‪...repeat as‬‬ ‫‪needed‬‬

‫‪time box‬‬

‫‪time box‬‬

‫‪time box‬‬

‫‪time box‬‬

‫‪some‬‬ ‫‪requirements/‬‬ ‫‪back log‬‬

‫כיצד מודלים אלו משפיעים עליי כבודק תוכנה?‬ ‫המודלים האג’ילים‪ ,‬ו‪ scrum-‬כטכניקה מובילה‪ ,‬למעשה משנים את התפיסה‬ ‫הקלאסית של שלבי פיתוח‪ .‬בנוסף‪ ,‬בשל לוחות הזמנים הקצרים מתבצע‬ ‫בדרך כלל מעט מאוד תיעוד בתהליך‪.‬‬ ‫לנו כבודקים המשמעות היא שאין זמן לכתוב תכנית בדיקות או תרחישי בדיקות‬ ‫מפורטים ואין זמן לבצע ריגרסיות מעמיקות‪ .‬במודל זה הבודקים הם חלק מצוות‬ ‫משימה והאחריות לאיכות התוצר היא של כל הצוות ולא רק של הבודקים (“כולם‬ ‫בודקים”)‪ .‬בנוסף‪ ,‬הבודקים משתלבים בתכנון וביצוע הבדיקות למן הרגע הראשון‬ ‫של “האפיון” (‪ )user story‬ובמהלך הפיתוח עצמו‪ .‬במודלים אלו אנו נדרשים‬ ‫ומחוייבים לבצע הרבה יותר אוטומציה ורצוי גם ממש כחלק ממשימות הפיתוח‬ ‫עצמן (‪ .)Test Driven Development‬לעיתים הבודקים אחראים לפתח את כלי‬ ‫האוטומציה או להכשיר את המפתחים לבצע בדיקות בעצמם (ולבקר אותן)‪.‬‬ ‫חשוב מאוד לשים לב שהבודקים לא ייבלעו בתוך צוות הפיתוח‪ .‬חייבת להיות‬ ‫להם עמדה של כח ויכולת להשפיע על השחרור של הרכיב בסיום הספרינט‬ ‫בהתאם להיקף הבדיקות שבוצע בפועל‪ .‬לבודקים הנמצאים בתוך צוותי‬ ‫‪ scrum‬חייבות להיות יכולות מקצועיות גבוהות מאוד וגם יכולות אישיותיות‬ ‫(כמעט ברמה של ראשי צוותים)‪.‬‬ ‫מודלים אחרים‪ /‬עתידיים‪ :‬אז מה העתי�� הקרוב‪ /‬הרחוק צופן לנו?‬ ‫אחת המגמות המאוד ברורות‪ ,‬שבאה לתת מענה להתקצרות משכי הפיתוח‬ ‫והבדיקות הינה העברת אחריות רבה יותר לאיכות המוצרים‪ /‬גרסאות לצוותי‬ ‫הפיתוח והוספת משימות אוטומציה לשלבי כתיבת הקוד‪ .‬כבר היום אנו רואים‬ ‫שימוש גובר והולך ב‪ ,TDD (test driven development( -‬הוספת תסריטי‬ ‫אוטומציה בתהליכי קומפילציה ובניית בילדים (‪)continues integration‬‬ ‫ותכנון תסריטי בדיקות של תהליכים עיסקיים (‪ )ATDD‬כבר בשלב כתיבת הקוד‬ ‫וביצוע בדיקות יחידה‪.‬‬ ‫בנוסף לאוטומציה‪ ,‬טכנולוגיה וכלים נראה מגמה נוספת של בודקי תוכנה שהם‬ ‫חלק בלתי נפרד מהאנשי המוצר‪ .‬כפי שחלק נכבד מפעילות הבדיקות תהיה‬ ‫תלויה ביכולת שלנו לפתח תוכנה ותהיה התקרבות וחפיפה בין המפתחים‬ ‫“לבודקים האוטומטיים”‪ ,‬תהיה גם התקרבות מאוד חזקה לשלב הגדרת‬ ‫הדרישות והאפיון של המוצר‪ /‬מערכת‪ .‬נראה מהנדסי בדיקות שהם גם מנתחי‬ ‫מערכות‪ ,‬מאפיינים ומנהלי מוצר שמצד אחד מגדירים את דרישות המוצר‬ ‫ובמקביל גם מוודאים שהוא מפותח בהתאם לאותן דרישות‪.‬‬ ‫כיצד מודלים אלו ישפיעו עליי כבודק תוכנה?‬ ‫נראה יותר ויותר בודקים עם רקע ויכולות של פיתוח תוכנה‪ .‬בודקים אלו יישבו‬ ‫כחלק מצוותי הפיתוח ויכתבו תסריטי אוטומציה כחלק מהספרינט עצמו‪.‬‬ ‫נראה שימוש גובר והולך בכלי אוטומציה‪ ,‬כלי עזר וטכניקות מתקדמות שיסייעו‬ ‫לנו לבצע בדיקות בכיסוי מספק (לא בהכרח גבוה מאוד) ובאיכות גבוהה‪.‬‬ ‫אם כיום בארגונים משתמשים בעיקר בכלי לניהול בדיקות וכלי אוטומציה‬ ‫בודד‪ ,‬בשנים הקרובות יהיו לכל בודק ‪ 5-10‬כלים “קטנים” שיסייעו לו לעשות‬

‫את הבדיקות מהר ויעיל יותר‪ .‬כלים אלו יסייעו לו לאתר מה חשוב לבדוק‬ ‫(היכן יש סיכוי גבוה יותר למצוא באגים)‪ ,‬לצמצם מקרי בדיקה (ראו מאמרו‬ ‫של טלמון בן כנען על ‪ all pairs‬במגזין הנוכחי)‪ ,‬לבנות ‪ DATA‬לבדיקות (ראו‬ ‫מספר דוגמאות מצויינות בבלוג הבא‪http://strazzere.blogspot.com/ :‬‬ ‫‪ )search/label/Test%20Data‬להריץ בדיקות (כולל כלים שונים לדפדפנים‬ ‫שונים)‪ ,‬לזהות פערים בין נתונים או דפים (שיטה שנקראת ‪:blink testing‬‬ ‫‪)http://strazzere.blogspot.com/2010/06/blink-tests-in-blink.html‬‬ ‫וכמובן לתעד את הבדיקות ואת התקלות (לדוגמא באמצעות‪SnagIt ,time :‬‬ ‫‪.) snapper‬‬ ‫מי שכבר מכיר את ה– ‪ ,sprinter‬ה‪ manual runner -‬החדש שנכלל בגרסת‬ ‫‪ QC 11‬של ‪ HP software‬למעשה יודע שבתוך “החבילה” הזו יש הרבה‬ ‫מאוד יכולות‪ ,‬כמו לדוגמא היכולת לבצע בדיקה ידנית בקונפיגורציה מסויימת‬ ‫של המערכת (נניח ‪ )Win XP ,IE7‬שתרוץ במקביל על עוד ‪ 4‬סביבות שונות‬ ‫(לדוגמא‪ .)IE 8 ,9 ,FF ,chrome :‬הפיצ’ר החדש הזה שנקרא ‪mirroring‬‬ ‫מאפשר למעשה לבצע פי ‪ 5‬יותר בדיקות במשך אותו הזמן‪.‬‬ ‫הדוגמא הזו של ‪ ,HP software‬כמו גם יכולות האוטומציה כחלק מתהליך‬ ‫הפיתוח הקיימות ב‪ Visual studio 2010 (Coded UI and MTM( -‬של‬ ‫מיקרוסופט בהחלט מהוות סמן ימני בולט וברור למגמה הזו של השוק‪.‬‬ ‫לסיכום‪ :‬השוק משתנה‪ ,‬תהליכי הפיתוח והבדיקות מתקצרים ועימם צצים‬ ‫כלים חדשים ושיטות חדשות לביצוע בדיקות‪.‬‬ ‫להערכתי בשנים הבאות השוק יתחלק לשני סוגי בודקים‪:‬‬ ‫‪ .1‬איש אוטומציה מומחה שיישב קרוב מאוד לגופי הפיתוח — מחייב יכולות‬ ‫פיתוח גבוהות מאוד‬ ‫‪ .2‬בודק ידני מומחה שילמד להשתמש במספר רב של כלי עזר לבדיקות‬ ‫מי שייקפא על שמריו‪ ,‬לא ינסה ללמוד ולהטמיע שיטות חדשות לבדיקות ייפלט‬ ‫משוק הבדיקות תוך ‪ 5-10‬שנים מהיום‪ ,‬כי זה יהפוך להיות הסטנדרט בתעשיה‬ ‫(בוודאי במדינות כמו הודו וסין לשם תעבור רוב העבודה ה”פשוטה”)‪.‬‬ ‫הדרך להתקדם וללמוד שיטות וכלים חדשים מבוססת על סקרנות ולמידה‪.‬‬ ‫אני מאוד ממליץ להצטרף לפורומים מקצועיים ולבלוגים מקצועיים בהם‬ ‫ניתן לקבל הרבה מאוד מידע רב ערך‪ .‬דוגמאות לבלוגים כאלו ניתן למצוא‬ ‫גם בתוך המאמר הזה אבל גם בטור של יואל “המלצה על בלוג”‪.‬‬

‫שיהיה בהצלחה לכולנו‪.‬‬ ‫רם‬

‫מקורות מידע‪:‬‬

‫‪• Kent Beck: http://www.threeriversinstitute.org/JustShip.html‬‬ ‫‪• Joe Strazzere: http://strazzere.blogspot.com/2010/06/blink-tests-in‬‬‫‪blink.html‬‬ ‫‪• Johanna Rothman: http://www.jrothman.com/Papers/Cutter/‬‬ ‫‪whatlifecycle.html‬‬ ‫‪• Mike Kelly: Agile software testing strategies for managers - http://‬‬ ‫_‪searchsoftwarequality.techtarget.com/tip/0,289483,sid92‬‬ ‫_‪gci1517262,00.html?track=NL-516&ad=778256&asrc=EM‬‬ ‫‪USC_12143795‬‬

‫תשובות נכונות מתוך‪ :‬בחן את עצמך‬ ‫‪( Exploratory Testing‬עמ’ ‪:)31‬‬ ‫‪(1‬א )‬ ‫‪(6‬ב) ‬

‫‪(2‬ג) ‬ ‫‪(7‬א )‬

‫‪(3‬ד )‬ ‫‪(8‬ב) ‬

‫‪(4‬ב )‬ ‫‪(9‬ג) ‬

‫‪(5‬ד) ‬ ‫‪(10‬ב)‬

‫מגזין חושבים בדיקות ׀ ינואר ‪ 2011‬׀ ‪37‬‬ ‫‪23-Dec-10 11:02:23 AM‬‬

‫‪Globalization.indd 37‬‬


‫מגמות בבדיקות תוכנה רם יוניש‬

‫קיצור תולדות הזמן‬ ‫אני לא סטיבן הוקינג וזה ממש לא מאמר על חורים שחורים‬ ‫)למרות שלחלק מהאנשים זה נשמע ככה(‪.‬‬ ‫המאמר מנסה לסקור מגמה שמלווה אותנו הרבה מאוד זמן‬ ‫וצוברת תאוצה בעיקר בשנים האחרונות של קיצור משכי‬ ‫הפיתוח וזמני הבדיקות‪ .‬בנוסף לסקירת המגמה אנסה לתת‬ ‫גם כלים‪ /‬טיפים לבודקי תוכנה עבור כל אחד ממודלי הפיתוח‬ ‫בהווה ובעתיד הקרוב ‪ /‬רחוק‪.‬‬ ‫מנהל פרויקט בכיר‪ ,‬שנחשד בציניות קלה‪ ,‬אמר פעם‪“ :‬זה מרגיש כאילו אני‬ ‫תקוע בין השמרנים לבין האג’יליסטים אנחנו לא יכולים להשתמש במודלים‬ ‫מסורתיים של מעבר בין שלבים‪ ,‬כי זה לא מספיק “זריז” (‪ ,)agile‬ובפעם‬ ‫האחרונה‪ ,‬כאשר ניסינו להטמיע ‪ scrum‬נכשלנו כישלון חרוץ‪ .‬האם אין גישה‬ ‫נכונה ומתאימה יותר לפרויקטים שלנו?“‬ ‫במאמרה של ג’ואנה רוטמן (ראו קישור בתחתית הכתבה) היא מתארת את‬ ‫ההתפחות האבולציונית של מודלים למחזור חיי הפיתוח לאורך השנים‪ .‬ג’ואנה‬ ‫מתארת ‪ 4‬מודלים שונים שלכל אחד מהם התפתחו טכניקות מתאימות‪:‬‬ ‫‪Serial model )waterfall, V model(, Iterative model )spiral(,‬‬ ‫)‪Incremental model and Agile )scrum, xp, kanba...‬‬ ‫המודלים הבאים מתוארים לפי סדר כרונולגי‪ ,‬מהמיושנים ‪ /‬מסורתיים‬ ‫לחדשים יותר‪.‬‬ ‫מודלים סידרתיים )‪:(Serial‬‬ ‫מחזור חיים סדרתי הוא כזה שבו כל השלבים מופיעים בסדר כרונולגי ברור‪.‬‬ ‫יש לסיים שלב אחד לפני שמתחיל השלב הבא (או לפחות דורשים כי אם אתה‬ ‫נמצא בשלב ‪ ,N‬יש להשלים את השלב הנוכחי בטרם יתחיל שלב ‪.)N+2‬‬ ‫‪test‬‬

‫‪integration‬‬

‫‪code‬‬

‫‪design‬‬

‫‪analysis‬‬

‫‪requirements‬‬

‫המודלים המסורתיים השכיחים ביותר הינם מפל המים ומודל ‪ .V‬מודלים אלו‬ ‫מהווים אחוז ניכר ממחזורי הפיתוח בישראל בכל מגזרי התעשיה ובעיקר‬ ‫בארגוני ‪( IT‬כגון‪ :‬בנקים‪ ,‬ביטוח‪ ,‬קופות חולים‪ ,‬חברות אשראי‪ ,‬חברות סלולר‬ ‫ומשרדי ממשלה) ובחברות ביטחוניות ורפואיות המצריכות תהליך מסודר‬ ‫ומתועד ברמת פירוט גבוהה‪.‬‬ ‫מודלים איטרטיביים )‪:(Iterative‬‬ ‫במודל האיטרטיבי‪ ,‬אנחנו קודם כל מפתחים אב טיפוס (‪ )prototype‬של‬ ‫רכיבי המוצר‪ /‬מערכת ורק לאחר שמאשרים אותו מתחילים פיתוח מסודר‪.‬‬ ‫לעיתים שומרים את הקוד שנכתב לצורך אב הטיפוס ולעיתים זורקים אותו‪,‬‬ ‫אבל העיקרון הוא למצוא דרכים יעילות לבנות אב טיפוס שמדגים מה הרכיב‪/‬‬ ‫המודול צריך לעשות בצורה הטובה ביותר ובשלב מוקדם‪.‬‬ ‫במחזור חיי פיתוח איטרטיבי משתמשים בעיקר‬ ‫בחברות מוצר ובחברות ‪ startup‬שכן יש יתרון‬ ‫ברור להציג אבטיפוס טרם התקדמות בפיתוח‬ ‫המוצר‪.‬‬

‫‪test‬‬

‫‪integration‬‬

‫‪prototype:‬‬ ‫‪analysis,‬‬ ‫‪design, code‬‬

‫‪prototype:‬‬ ‫‪analysis,‬‬ ‫‪design, code‬‬

‫‪prototype:‬‬ ‫‪analysis,‬‬ ‫‪design, code‬‬

‫‪requirements‬‬

‫מודלים “מצטברים” )‪:(Incremental‬‬ ‫במודלים אינקרמנטלים מפתחים את המערכת ב”חבילות”‪“ .‬החבילות” יכללו‬ ‫בדרך כלל מודולים סגורים של המערכת‪ ,‬שפותחו בצורה מלאה‪ .‬ככל שמייצרים‬ ‫יותר מודולים כאלו המערכת שלמה יותר‪.‬‬ ‫בשיטות האינקרמנטליות משך הפיתוח של כל מודול מתקצר וכולל בתוכו את כל‬ ‫השלבים האופייניים למודלים הסדרתיים (דרישות ‪ -‬אפיון – פיתוח – בדיקות)‪.‬‬ ‫החסרון במודלים אלו הינו בכך שמשך בדיקות הרגרסיה המצטבר ארוך יותר‬ ‫אך מאידך במידה ומבצעים אותם נכון (מסיימים קודם כל לפתח חבילות‬ ‫הקשורות להיבטים תשתיתיים ‪ /‬רוחביים ורק אחר כך פיצ’רים) ומשאירים‬ ‫מספיק זמן לבדיקות אינטגרציה ו‪ E2E -‬אזי המוצר יקבל פידבק מוקדם יותר‬ ‫ויהיה מתאים יותר לצרכי הלקוח‪.‬‬ ‫המודל האינקרמנטלי מעניין מאוד אבל אין הרבה חברות שמשתמשות בו‪ ,‬או‬ ‫שיש חברות שמשתמשות בו אבל קוראות לו אחרת‪...‬‬ ‫‪final‬‬ ‫‪test‬‬

‫‪final‬‬ ‫‪integration‬‬

‫‪design,‬‬ ‫‪code,‬‬ ‫‪int’ & test‬‬

‫‪design,‬‬ ‫‪code,‬‬ ‫‪int’ & test‬‬

‫‪design,‬‬ ‫‪code,‬‬ ‫‪int’ & test‬‬

‫‪analysis‬‬ ‫‪to choose‬‬ ‫‪overall‬‬ ‫‪architecture‬‬

‫‪some‬‬ ‫‪requirements‬‬

‫מודלים “אג‘ילים” )‪:(agile‬‬ ‫המודלים האג’ילים צצו כפטריות שלאחר הגשם בעיקר על מנת לתת מענה‬ ‫לאתגרים של “העת החדשה” כגון הצורך בגמישות רבה מאוד וזריזות בפיתוח‬ ‫ומענה לצרכי השוק‪.‬‬ ‫במודלים האג’ילים (זריזים) משכי הפיתוח מתקצרים מאוד ומוגדרים בתוך‬ ‫‪ time box‬של שבועיים עד חודש בדרך כלל‪ .‬ב‪ scrum -‬לדוגמא‪ ,‬מגדירים את‬ ‫רשימת הפריטים שיש לפתח (‪ )feature back log‬ומתעדפים אותם‪ .‬כל “צוות‬ ‫משימה” בוחר לעצמו את הפריטים אותם הוא מסוגל לפתח ואחראי להצלחת‬ ‫הרכיב‪ .‬כל ‪ time box‬או ספרינט כולל את כל ה”שלבים המסורתיים” ביחד‪,‬‬ ‫כלומר‪,‬אפיון הרכיב‪,‬פיתוחו ובדיקתו‪ ,‬כך שבסיום הספרינט אותו רכיב למעשה‬ ‫מוכן להטמעה בסביבת הייצור או כחלק מהמוצר בסביבת ‪.Pre-production‬‬ ‫קיימים מודלים נוספים מלבד ‪ ,scrum‬כגון‪ KanBan ,Lean ,XP :‬ו‪.DSDM -‬‬ ‫על מודלים אלו תוכלו לקרוא במאמר על “בדיקות בסביבת ‪ agile‬שפרסמנו‬ ‫במהדורה הראשונה של המגזין באוקטובר ‪.2010‬‬ ‫מתוך כל המודלים הנ”ל ‪ scrum‬הוא ללא ספק המודל שתפס הכי חזק‬ ‫בישראל‪ .‬ניתן לראות היום הרבה מאוד גופים שמנסים להטמיע ‪ scrum‬בכל‬ ‫מיני דרכים והתאמות למבנה והצורך הארגוני‪ .‬עם זאת‪ ,‬לדעתי המודל הזה‬ ‫מתאים בעיקר לחברות מוצר ולחברות הזנק (‪ )start up‬ופחות לחברות‬ ‫מסורתיות‪ ,‬ארגוני ‪ IT‬וחברות מהתחום הביטחוני והרפואי‪.‬‬ ‫אחת הבעיות בהטמעה של מודלים אלו הוא הקיבעון‬ ‫המחשבתי של אנשי בדיקות מנוסים שמבחינתם‬ ‫“ללא מסמך אפיון לא ניתן להתחיל לבדוק”‪ .‬חשוב‬ ‫להבין את הבעייתיות והשינוי הנדרש מחברה‬

‫‪ 36‬׀ מגזין חושבים בדיקות ׀ ינואר ‪2011‬‬

‫‪23-Dec-10 11:02:23 AM‬‬

‫‪Globalization.indd 36‬‬


‫תמונה מספר ‪ :2‬דוגמה – ערכים של פרמטר בודד‬

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

‫תמונה מספר ‪ :3‬תוצאת החישוב‪ .‬המספר למעלה מראה כמה מקרי בדיקה נדרשים‪.‬‬ ‫כל שורה בטבלה היא מקרה בדיקה‪.‬‬ ‫הערה‪ :‬הוספת החוק העסקי‪ ,‬שלא ניתן לחתוך פיצה אישית ל ‪ 12‬פלחים‪ ,‬מגדילה את מספר מקרי הבדיקה ל ‪123‬‬

‫פיתוח אתר ‪ ?Web‬סוג ה ‪ ,Browser‬תכנת הפעלה‪ ,Plug-ins ,‬סוג השרת‪...‬‬ ‫דוגמה מעולם התקשורת‪:‬‬ ‫חברת תקשורת המספקת שירותי טלפון נייד‪ ,‬טלפון קווי‪ ,‬אינטרנט וטלויזיה‪:‬‬ ‫מערכת ההזמנות (‪ )Ordering‬מעבירה את פרטי ההזמנה למערכות הטכנאים‬ ‫האמורים לספק ללקוח ציוד ביתי מתאים או להחליף ציוד קיים‪.‬‬ ‫הבדיקות הקיפו ‪ 12‬סוגי ציוד (מפענחים‪ ,‬מודמים)‪ 3 ,‬סוגי לקוח‪ 3 ,‬מסלולים‬ ‫עסקיים‪ 3 ,‬שיטות אספקה (על ידי טכנאי‪ ,‬משלוח ‪ ,carrier‬קנייה בחנות)‪ ,‬שני‬ ‫סוגי הרכשה (מכירה או השכרה) ו ‪ 6‬סוגי הזמנה (הזמנה חדשה‪ ,‬שינוי הזמנה‪,‬‬ ‫שדרוג ועוד)‪.‬‬ ‫מתוך כ ‪ 2600‬אפשרויות‪ ,‬נבחרו בהתחלה (ללא כלי וללא אלגוריתם אלא על סמך‬ ‫נסיון ואינטואיציה של הבודקים) ‪ 153‬מקרי בדיקה‪ ,‬כאשר בחירת הפרמטרים‬ ‫נעשתה ידנית‪ .‬בבדיקה מצאנו כמות גדולה של זוגות לא מכוסים בבדיקות‪.‬‬ ‫שימוש בכלי נתן ‪ 72‬מקרי בדיקה‪ ,‬כאשר כל הזוגות החוקיים מכוסים‪.‬‬ ‫ואצלך? השימוש בכלי מסובך? מה תכל’ס צריך לעשות בכדי להשתמש‬ ‫בטכניקה הזו?‬ ‫מספר פעילויות פשוטות יחסית‪:‬‬ ‫‪ .1‬זהה את הפרמטרים והערכים והכן טבלת ‪ Excel‬כגון טבלת הפיצות למעלה‪.‬‬

‫רשימת כלים אפשר לראות באתר ‪http://www.pairwise.org/tools.asp‬‬ ‫אתר זה גם מסביר יותר לעומק את התיאוריה מתמטית ומצטט משתמשים‬ ‫מרוצים‪.‬‬

‫‪ .2‬העלה את הטבלה לכלי (ראה דוגמה לשימוש ב‪ FoCuS -‬של ‪.)IBM‬‬ ‫זהה את החוקים העסקיים והכנס לכלי‪( .‬רשימת כלים אפשר לראות באתר‬ ‫‪)http://www.pairwise.org/tools.asp‬‬

‫אנחנו השתמשנו בכלי של ‪ IBM‬שנקרא ‪ .FoCuS‬כלי זה פותח במעבדת‬ ‫המחקר של ‪ IBM‬בחיפה‪ .‬כחול לבן!‬

‫‪ .3‬קבע את מידת הכיסוי בהתאם לרמת הסיכון (זוגות? שלישיות? רביעיות?)‪.‬‬

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

‫‪ .4‬בקש לחולל דו”ח בדיקות‪ .‬התוצאה תיראה כמו תמונה מספר ‪ ,3‬כאשר כל‬ ‫שורה מתארת מקרה בדיקה יחיד‪.‬‬ ‫‪ .5‬ייצא את הטבלה ל”אקסל” והנה לך טבלת נתוני בדיקה מבוססת ‪All‬‬ ‫‪.pairs‬‬ ‫ביבליוגרפיה‬

‫ברוב הכלים ניתן להכניס חוקים עסקיים‪ ,‬ועל ידי כך לייצר אך ורק צירופים‬ ‫שיש להם משמעות עסקית (אולי נרצה לייצר רשימה נוספת של בדיקות‬ ‫שליליות)‪.‬‬ ‫גם כמות בדיקות מינימלית וגם כיסוי אופטימלי‪ ...‬מה‪ ,‬אין חסרונות?‬ ‫‪ ‬האלגוריתם המייצר את רשימת הבדיקות לא מבין “ביזנס”‪ .‬אין לו אפשרות‬ ‫לתת לערכים מסוימים העדפה‪ ,‬ועל ידי כך להתאים את הכיסוי לצורך‬ ‫העסקי‬ ‫‪ ‬כאשר כמות הפרמטרים קטנה‪ ,‬החסכון בכמות מקרי הבדיקה אינו גדול‪.‬‬ ‫יתרון השיטה הוא כאשר כמות הפרמטרים גדולה (מעל ‪ .)5‬כאשר כמות‬ ‫הפרמטרים קטנה‪ ,‬ניתן לבצע בדיקות לכל הצירופים‪.‬‬ ‫‪ ‬אין יתרון גדול ל‪ Pairwise -‬אם הפונקציונליות הנדרשת לא מתייחסת‬ ‫לאינטראקציות בין הפרמטרים‪.‬‬ ‫‪ ‬לא תמיד המציאות קלה להחלפה במודל‪.‬‬ ‫‪ ‬נדרשת רמת ידע מסויימת (כגון זיהוי פרמטרי מלא וזיהוי חוקים מגבילים)‬

‫‪1. Lee Copeland, A Practitioner’s Guide to Software Test Design. Chapter 6:‬‬ ‫‪Pairwise Testing‬‬ ‫‪2. Cem Kaner, James Bach, Bret Pettichord, Lessons Learned in Software‬‬ ‫‪Testing. Chapter 3: Testing Techniques: How to Do Combination Testing‬‬ ‫‪Using the All-Pairs Technique‬‬ ‫‪3. Combinatorial Methods for Cybersecurity Testing; Rick Kuhn and Raghu‬‬ ‫‪Kacker; National Institute of Standards and Technology Gaithersburg, MD‬‬ ‫)‪(csrc.nist.gov/groups/SNS/acts/documents/kuhn-idga-mte.ppt‬‬ ‫‪4. Automated Combinatorial Testing SYSTEM , NIST, http://csrc.nist.gov/‬‬ ‫‪groups/SNS/acts/index.html‬‬ ‫‪5. Software Fault Interactions and Implications for Software Testing, D.‬‬ ‫‪Richard Kuhn, Senior Member, IEEE, Dolores R. Wallace, Member, IEEE‬‬ ‫‪Computer Society, and Albert M. Gallo Jr., 2004‬‬

‫‪ 34‬׀ מגזין חושבים בדיקות ׀ ינואר ‪2011‬‬

‫‪27-Dec-10 11:13:10 AM‬‬

‫‪Pairwise testing.indd 34‬‬


‫‪5‬‬

‫‪4‬‬

‫‪3‬‬

‫‪11‬‬

‫‪11‬‬

‫‪4‬‬

‫‪2‬‬

‫‪3‬‬

‫גודל‬ ‫הפיצה‬

‫סוג‬ ‫הבצק‬

‫תוספת‬ ‫גבינה‬

‫תוספות‪,‬‬ ‫חצי פיצה‬

‫תוספות‪ ,‬חצי‬ ‫פיצה‬

‫רוטב‬

‫אפייה‬

‫חיתוך‬

‫ללא‬

‫ללא‬

‫ללא‬

‫רגילה‬

‫‪ 6‬פלחים‬

‫משפחתי גדול‬

‫עבה ורך‬

‫עם תוספת‬

‫פפרוני‬

‫פפרוני‬

‫רגיל‬

‫‪ 8 Well Done‬פלחים‬

‫משפחתי קטן‬

‫דק ופריך‬

‫‪ 4‬גבינות‬

‫זיתים ירוקים‬

‫זיתים ירוקים‬

‫חריף‬

‫בינונית‬

‫דק ורך‬

‫ענקית‬

‫אישית‬

‫עבה ופריך‪ ,‬ללא‬

‫זיתים שחורים זיתים שחורים‬ ‫חצילים‬

‫חצילים‬

‫פטריות‬

‫פטריות‬

‫פלפל קלוי‬

‫פלפל קלוי‬

‫בצל טרי‬

‫בצל טרי‬

‫בצל מטוגן‬

‫בצל מטוגן‬

‫תירס‬

‫תירס‬

‫אנשובי‬

‫אנשובי‬

‫אם ההצעה האחרונה לא מעניינת אתכם‪ ,‬אתם יכולים‬ ‫לעבור לקרוא את המאמר הבא‪.‬‬ ‫כמה מקרי בדיקה ייתנו לנו בטחון שחישוב המחיר מדוייק‪,‬‬ ‫ולוודא שההוראות שאנו שולחים לקו היצור מכסות את מה‬ ‫שנדרש?‬ ‫רשום כאן את הערכתך לפני שאתה ממשיך לקרוא‪_____ :‬‬

‫ההגיון מאחרי האלגוריתם של ‪:Pairwise‬‬

‫בדיקות שפורסמו על ידי ‪ NIST‬מראות שמקרי בדיקה‬ ‫המבוססים על בדיקת פרמטר אחד‪ ,‬יגלו כ ‪ 30%‬עד ‪70%‬‬ ‫מהשגיאות הקשורות לקוד שתומך באותו פרמטר‪ .‬שגיאות‬ ‫נוספות הן תוצאה של צירוף של שני פרמטרים או יותר‪.‬‬ ‫לדוגמא — המחיר של תוספת זיתים ירוקים מחושב נכון לחצי‬ ‫פיצה‪ ,‬אבל יכולה להיות שגיאה אם אותה תוספת נבחרה‬ ‫לכל הפיצה (המחיר נמוך יותר מאשר פעמיים חצי פיצה)‪.‬‬ ‫אחוז קטן יותר של שגיאות יהיה תוצאה של שלושה‬ ‫צירופים או יותר‪.‬‬

‫‪ 12‬פלחים‬

‫מתקתק‬

‫סיכום ביניים‪ :‬בינתיים אנחנו מבינים שהשם ‪Pairwise‬‬ ‫מצביע על מציאת כל הזוגות האפשריים וגם שכנראה לא‬ ‫צריך ‪ 170,000‬מקרי בדיקה ועדיין לעלות על כמות טובה‬ ‫של כשלים‪.‬‬ ‫“פיצה פיצוץ” — כמה מקרי בדיקה נדרשים?‬ ‫זוכרים? הגענו לכ‪ 175,000 -‬אפשרויות‪ .‬כמה בדיקות‬ ‫נדרשות לכיסוי כל הזוגות? השלשות? הרביעיות?‬ ‫‪ 122‬מקרי בדיקה מכסים את כל הצירופים הזוגיים;‬ ‫‪ 623‬מקרי בדיקה מכסים את כל השלישיות;‬ ‫לא מספיק? רוצים לכסות כל רביעיה אפשרית? אין בעייה‪.‬‬ ‫כמות מקרי הבדיקה היא ‪.2,859‬‬ ‫וואו‪ ,‬איך חישבתם? האם זה מסובך לייצר את הרשימה?‬ ‫ישנם מספר כלים המכילים את האלגוריתם המתאים‪.‬‬ ‫אנו מזינים את הכלי ברשימת הפרמטרים והערכים‪,‬‬ ‫ומקבלים כתוצאה טבלה בה כל שורה היא מקרה‬ ‫בדיקה‪.‬‬

‫תמונה מספר ‪ :1‬הכנסת הפרמטרים של “פיצה פיצוץ” לכלי ‪ FoCuS‬של ‪ .IBM‬בחלק התחתון הוכנסה מגבלה עסקית‪.‬‬ ‫(מספר האפשרויות המקסימלי מצויין בכותרת)‬

‫טלמון בן‪-‬כנען‬ ‫טלמון בן‪-‬כנען עובד בחברת‬ ‫“אמדוקס” מזה כ ‪ 10‬שנים‬ ‫כמנהל איכות‪ .‬תפקידו הנוכחי‬ ‫הוא מנהל איכות בגוף ה ‪SI-‬‬ ‫‪ ;Testing‬גוף זה מונה כיום כ‬ ‫‪ 1,500‬אנשי בדיקות הממוקמים‬ ‫ביותר מ – ‪ 30‬אתרים בעולם‪,‬‬ ‫ומבצעים בעיקר בדיקות קבלה‬ ‫עבור לקוחות “אמדוקס”‪.‬‬ ‫לפני שעבר לתחום בדיקות‬ ‫תכנה שימש טלמון כמטמיע‬ ‫תהליכי ניהול פרוייקטלי וכן‬ ‫שימש כמנהל תחום מדדי‬ ‫התכנה ומנהל הטמעת‬ ‫‪ Function Points‬באמדוקס‪.‬‬

‫מגזין חושבים בדיקות ׀ ינואר ‪ 2011‬׀ ‪33‬‬ ‫‪27-Dec-10 11:13:10 AM‬‬

‫‪Pairwise testing.indd 33‬‬


‫‪e‬‬ ‫‪s‬‬ ‫‪i‬‬ ‫‪w‬‬ ‫‪r‬‬ ‫‪i‬‬ ‫‪Pa sting‬‬ ‫מ‬ ‫‪e‬‬ ‫ק‬ ‫ב סימו ‪T‬‬

‫מ‬ ‫כ‬ ‫י‬ ‫י‬ ‫נ‬ ‫י‬ ‫מו בדיסוי‬ ‫ק‬ ‫ו‬ ‫ת‬

‫ה‬ ‫ש‬ ‫א‬ ‫ל‬ ‫ה‬ ‫ה‬ ‫נ‬ ‫דונ‬ ‫ה‬ ‫ב‬ ‫ה‬ ‫כ‬ ‫מ‬ ‫מ‬ ‫ש‬ ‫ה‬ ‫ך‬ ‫מ‬ ‫ה‬ ‫י‬ ‫נ‬ ‫ק‬ ‫ר‬ ‫ה‬ ‫י‬ ‫ב‬ ‫בד‬ ‫י‬ ‫עניי‬ ‫ק‬ ‫ן‬ ‫ה‬ ‫ש‬ ‫נ‬ ‫ל‬ ‫ד‬ ‫ר‬ ‫כ‬ ‫י‬ ‫ש‬ ‫י‬ ‫ס‬ ‫ו‬ ‫י‬ ‫ם למערך בדיקות נאות‪:‬‬ ‫אפקטיבי?‬ ‫“פיצה פיצוץ” היא רשת הפיצות הממוחשבת הראשונה‬ ‫בתחומה‪ ,‬המייצרת פיצות ללא מגע יד אדם‪ ,‬ולכן במחיר שווה‬ ‫לכל נפש‪ .‬ההזמנה מבוצעת באינטרנט‪ .‬מערכת משוכללת‬ ‫של רובוטים בוחרים את הבצק‪ ,‬הגבינה הצהובה והתוספות‬ ‫על פי ההזמנה‪ ,‬מכניסים את הפיצה לתנור ממוחשב‪ ,‬אורזים‬ ‫אותה ומעבירים לדואר שליחים מהיר ויעיל‪.‬‬ ‫עלינו הוטל לבדוק את תוכנת ההזמנות (אנחנו עדיין מקווים‬ ‫לזכות גם במכרז הבדיקות לקו‪-‬היצור)‪ .‬האתר המהודר של “פיצה‬ ‫פיצוץ” מאפשר ללקוח לבחור את מרכיבי הפיצה שלו‪ ,‬תוכנת‬ ‫ההזמנות מחשבת את המחיר‪ ,‬גובה את התשלום ושולחת הוראות‬ ‫ממוחשבות למערכות הרובוטיות במפעל‪ .‬עלינו לוודא שהמחיר‬ ‫מחושב נכון‪ ,‬וכן שהוראות הייצור נשלחות ללא שגיאה לכל מרכיבי‬ ‫הייצור‪.‬‬ ‫דרישות המערכת (לאחר מסך הכניסה‪ ,‬פרסומת ורישום נתוני‬ ‫הלקוח) כוללת מבחר לא רע של גדלים וטעמים וכמובן לכל צירוף‬ ‫יש מחיר משלו‪:‬‬ ‫‪ ‬בחירת גודל הפיצה (ענקית‪ ,‬משפחתית גדולה‪ ,‬משפחתית‬ ‫קטנה‪ ,‬בינונית‪ ,‬אישית)‬ ‫‪ ‬סוג הבצק (עבה ופריך‪ ,‬עבה ורך‪ ,‬דק ופריך‪ ,‬דק ורך)‬ ‫‪ ‬אפשרות לתוספת גבינה צהובה או ל ”‪ 4‬גבינות”‬ ‫‪ ‬תוספות‪ :‬התוספת יכולה להיות לכל הפיצה‪ ,‬או שתי תוספות‪,‬‬ ‫אחת לכל חצי פיצה‪ .‬המבחר כולל ‪ 10‬תוספות (פפרוני‪ ,‬זיתים‬ ‫ירוקים‪ ,‬זיתים שחורים‪ ,‬חצילים‪ ,‬פטריות‪ ,‬פלפל קלוי‪ ,‬בצל טרי‪,‬‬ ‫בצל מטוגן‪ ,‬תירס‪ ,‬אנשובי) או ללא כל תוספת‪.‬‬ ‫‪ ‬רוטב‪ :‬רגיל‪ ,‬חריף‪ ,‬מתקתק‪ ,‬ללא רוטב‬ ‫‪ ‬אפייה רגילה או ‪Well Done‬‬ ‫‪ ‬חיתוך ל ‪ 8 ,6‬או ‪ 12‬פלחים‬ ‫‪ ‬כמות (כמה פיצות)‬

‫‪ ‬המשך ההזמנה‪ :‬חזרה להתחלה‪ ,‬או הזמנה נוספת‪ ,‬או מעבר‬ ‫לאמצעי התשלום‪.‬‬ ‫בסיום תהליך הבחירה ולפני הצגת המחיר הסופי מוצגת לצופה‬ ‫הרעב תמונה מעוררת תאבון‪.‬‬ ‫כמובן שלפני שאנחנו מתחילים בתכנון הבדיקות הזמנו פיצה עם כל‬ ‫התוספות (עוד לילה ארוך לפנינו)‪.‬‬ ‫הבה ננסה לחשב כמה מקרי בדיקה יכסו את הדרישות (להזכיר‪:‬‬ ‫לכל אפשרות מחיר אחר והוראות אחרות למערך הייצור)‪.‬‬ ‫המספרים שבראש הטבלה שבעמוד ממול‪ ,‬מראים את כמות‬ ‫הערכים לכל פרמטר‪.‬‬ ‫סך כל האפשרויות‪:‬‬ ‫‪5x4x3x11x11x4x2x3=174,240‬‬ ‫האם נבצע מעל ‪ 170‬אלף מקרי בדיקה? ואם לא‪ ,‬כמה מקרי בדיקה‬ ‫יתנו כיסוי נאות? ‪ 400‬יספיקו? אולי ‪ ?4,000‬אולי ‪?40,000‬‬ ‫עכשיו אנחנו נותנים ביס בשאריות הפיצה הקרה ומנסים לראות‬ ‫באיזה אסטרטגיה לנקוט‪:‬‬ ‫‪ ‬אולי נבדוק הכל; הלקוח יהיה מה זה מרוצה‪ ,‬ויש לנו שישי שבת‬ ‫ולילה ואח שיעזור לנו; אולי נבקש שהלקוח שלנו יידחה את‬ ‫מועד הפתיחה בשבועיים ואז יהיה לנו יותר זמן‪.‬‬ ‫‪ ‬יש לנו עשרה ימי בדיקות ונוכל לבצע ‪ 100‬תסריטי בדיקה ביום‪,‬‬ ‫אז בואו נבחר ‪ 1,000‬ונקווה שיהיה טוב‪.‬‬ ‫‪ ‬בואו נייצר רשימה של כל מקרי הבדיקות ונעשה כמה שנספיק‪.‬‬ ‫‪ ‬בואו נחפש פטנט אחר‪ :‬מינימום מקרי בדיקה במקסימום כיסוי‪.‬‬

‫‪ 32‬׀ מגזין חושבים בדיקות ׀ ינואר ‪2011‬‬

‫‪23-Dec-10 11:26:22 AM‬‬

‫‪Pairwise testing.indd 32‬‬


‫בחן את עצמך‬

‫)‪Exploratory Testing (ET‬‬ ‫‪1‬‬

‫מה ההגדרה של ‪?ET‬‬

‫‪2‬‬

‫היתרון העיקרי ב‪ ET-‬הוא‬

‫‪3‬‬

‫אילו מהמשפטים הבאים אינו נכון?‬

‫‪4‬‬

‫מה ההגדרה המדוייקת ביותר עבור‬ ‫‪?Test Session‬‬

‫‪5‬‬

‫אילו תכונות נדרשות לבודק ‪?ET‬‬

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

‫א‪ .‬כיף יותר מהרצת תסריטי בדיקות מוכנים‬ ‫ב‪ .‬מאפשר ”למלא את הזמן“ אחרי סיום הרצת בדיקות‬ ‫ג‪ .‬מאפשר למצוא יותר באגים בפרק זמן נתון‬ ‫ד‪ .‬חוסך זמן של תכנון בדיקות‬

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

‫א‪ .‬מסמך המסכם הבדיקות שבוצעו ע“י הבודק‬ ‫ב‪ .‬מקטע באורך ‪ 90‬דקות בו הבודק נדרש לבדוק נושא מסוים‬ ‫ג‪ .‬חלק הבדיקות המתמקד בביצוע בדיקות קצה‬ ‫שלב ההרצה של בדיקות ‪ET‬‬

‫‪6‬‬

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

‫מתי כדאי לעשות ‪?ET‬‬

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

‫מי מהאנשים הבאים אינו נחשב חסיד‬ ‫‪ 7‬של גישת ה‪?ET-‬‬ ‫א‪Martin Pol .‬‬ ‫ב‪James Bach .‬‬ ‫ג‪Cem Kaner .‬‬ ‫ד‪Michael Bolton .‬‬

‫‪ 8‬מה הבעיה העיקרית בגישת בדיקות מונחית‬ ‫תסריטים )‪?(Scripted Testing‬‬ ‫א‪ .‬לא מאפשרת מציאת הרבה באגים‬ ‫ב‪ .‬לא מאפשרת חופש פעולה לבודק תוך כדי הרצת בדיקות‬ ‫ג‪ .‬דורשת הרבה מסמכים‬ ‫ד‪ .‬אינה מאפשרת בדיקות של מצבי קצה‬

‫‪9‬‬

‫האם הרצת בדיקות חופשיות )‪(Free-style testing‬‬ ‫ללא תיעוד נחשבת סוג של ‪?ET‬‬

‫א‪ .‬כן‬ ‫ב‪ .‬כן בתנאי שהבודק חוקר המערכת תוך כדי הרצה‬ ‫ג‪ .‬לא‪ .‬אם אין תיעוד של תהליך הרצת הבדיקות אז זה ‪ Free-style‬ולא ‪ET‬‬ ‫ד‪ .‬כן‪ ,‬אבל דרך לא טובה לעשות ‪ET‬‬

‫‪ 10‬מהם המקורות עליהם מסתמכים בביצוע ‪?ET‬‬

‫א‪ .‬אפיון המערכת‬ ‫ב‪ .‬איפיון המערכת‪ ,‬שיחות עם גורמים רלבנטיים )כמו מנהל המוצר‪,‬‬ ‫משתמשים( וחקירת המערכת הנבדקת‬ ‫ג‪ .‬חקירת המערכת הנבדקת‬ ‫ד‪ .‬ניתוח אופן השימוש במערכת ע“י המשתמשים‬

‫!‬

‫התשובות הנכונות נמצאות בעמוד ‪37‬‬

‫גלה האם אתה בודק ‪ ET‬מקצועי או‪...‬‬ ‫)הציון בהתאם לכמות התשובות הנכונות שענית(‬ ‫‪ 0-3‬איך לומר זאת בעדינות? אין לך מושג! אפילו מבחינה סטטסטית —‬ ‫אם היית מסמן תשובה אחת זהה בכל השאלון — היית מקבל ציון גבוה‬ ‫יותר‪ .‬ממש כישרון‪...‬‬ ‫‪ 4-6‬תפתח את עמוד ‪ 6‬בגליון שאתה מחזיק‪ .‬יש לך עוד לא מעט ללמוד‬ ‫בתחום‪.‬‬ ‫‪ 7-8‬תראה‪ ,‬עוד קצת ‪ Exploratory‬ואתה בהחלט תהיה מוכן לביצוע‬ ‫‪ .Testing‬לא רע!‬ ‫‪ 9-10‬קודם כל‪ ,‬אנחנו שמחים לראות שהתפנית לכמה דקות מלקרוא‬ ‫מאמרים ולבצע בדיקות בשביל לענות על השאלון הזה‪ .‬חוץ מזה‪ ,‬נשמח‬ ‫אם תכתוב משהו עבור הגליון הבא של ”חושבים בדיקות“‪.‬‬

‫מגזין חושבים בדיקות ׀ ינואר ‪ 2011‬׀ ‪31‬‬ ‫‪27-Dec-10 11:10:30 AM‬‬

‫‪Test_Yourself.indd 31‬‬


‫‪page 4‬‬

‫‪042‬‬

‫‪041‬‬

‫‪App. Back-End‬‬

‫‪043‬‬

‫‪page 2‬‬

‫‪Pages‬‬

‫‪page 3‬‬

‫‪page 1‬‬

‫‪data‬‬

‫איור ‪ .3‬זיהוי תרחיש בדיקה‬

‫‪10 – Conn. Starvation‬‬ ‫‪100 – Apache Limit‬‬ ‫‪500 – Slow DB Queries‬‬ ‫‪1000 – Code, Search, Cache‬‬

‫איור ‪ .4‬פירמידת הממצאים‬

‫בניגוד למה שקורה כאשר מתכננים בדיקת פונקציונאליות‪ ,‬הרעיון מאחורי‬ ‫בדיקת עומסים הוא לבחור מערך מינימאלי של תרחישים אשר יכסה את‬ ‫מרבית הפעולות השגרתיות במערכת הניהול‪ .‬גם כאן‪ ,‬חשוב להבין שמוקד‬ ‫בדיקות הביצועים והעומסים הוא מערכת הניהול ולא ממשק המשתמש‬ ‫)‪.(frontend‬‬ ‫אחת הטעויות הנפוצות בין ארגונים רבים בראשית דרכם בבדיקות ביצועים‪,‬‬ ‫היא המרת כל הפעולות העסקיות הקיימות לתרחישי בדיקה‪ .‬העיקרון של‬ ‫בחירת תרחישי בדיקה מודגם באיור ‪ .3‬המפתחות לזיהוי ובחירת תרחישי‬ ‫בדיקה הינם‪:‬‬ ‫‪ .1‬בחר את חמשת התרחישים הנפוצים ביותר במערכת שלך‪.‬‬ ‫‪ .2‬אל תוסיף תרחישים שיש להם זרימה דומה במערכת הניהול‪.‬‬ ‫‪ .3‬זהה מראש זרימות בעייתיות במערכת הניהול וודא שהתרחישים מכסים את‬ ‫האפשרויות הללו‪.‬‬ ‫ביצוע בדיקה‬ ‫ביצוע בדיקה וניתוח התוצאות הינם תהליכים החוזרים על עצמם עד להשגת‬ ‫כל יעדי הבדיקה‪ .‬עם הגדלת העומס‪ ,‬תיחשפנה בעיות חדשות‪ ,‬ופתיחת‬ ‫צוואר בקבוק אחד בדרך כלל מובילה אל צוואר הבקבוק הבא בצנרת היישום‪.‬‬ ‫המשימה היא לאמת ולנקות את הצנרת לכל אורכה‪.‬‬ ‫אחד המשתנים שעשויים להשפיע על תוצאות הבדיקה הוא הפרמטרים של‬ ‫הבדיקה‪ .‬ישנם פרמטרים רבים‪ ,‬החל מהברורים מאליהם כמו שם משתמש‬ ‫וסיסמא וכלה בטווח תאריכים‪ ,‬מילות חיפוש וערכים רנדומאליים‪ .‬על פרמטרים‬ ‫אלה להיות חלק מתוכנית הבדיקה מאחר וביצועי המערכת עשויים להיות‬ ‫נתונים להשפעה דרמתית מצידם‪.‬‬

‫‪ ‬ראשית‪ ,‬בדוק את המערכת עם משתני קלט ”קלים“‬ ‫‪ ‬בדוק את צווארי הבקבוק הברורים מאליהם‪ ,‬תוך הגדלה מדורגת של העומס‬ ‫‪ ‬הרץ בדיקות ליליות בכל לילה‪ ,‬על מנת להבטיח את אמינות המערכת ואת‬ ‫יציבותה‬ ‫‪ ‬כאשר מגיעים לרמת ‪ 500‬משתמשים יש ליישם משתני קלט ”כבדים“‬ ‫‪ ‬בדוק את המערכת תחת עומס מבוזר אקראי‬ ‫פירמידת הממצאים‬ ‫הגדלת העומס מציפה בעיות חדשות‪ .‬איור ‪ 4‬מדגים בעיות נפוצות עמן‬ ‫התמודדנו ברמות בדיקה שונות‪ .‬המספרים מצביעים על מספר המשתמשים‬ ‫הבו‪-‬זמניים )עומס(‪.‬‬ ‫ניצול ההתחברות לבסיס הנתונים הוא אחת הבעיות הותיקות אך נפוצות בפיתוח‬ ‫יישומי רשת‪ .‬ללא שחרור נכון‪ ,‬יישומים מנצלים יותר ויותר חיבורים לבסיס‬ ‫הנתונים עד הגיעם לקצה גבול היכולת של המערכת‪ .‬ברמת ‪ 10‬משתמשים‬ ‫המערכת הגיעה אל גבול הקיבולת של מאגר החיבורים כתוצאה מיישום לקוי‬ ‫של ההתחברות לבסיס הנתונים וכתוצאה ממאגר חיבורים קטן מדי‪.‬‬ ‫ברירות המחדל בתצורות שרתי רשת לרוב מותאמות היטב לצרכי פיתוח‪,‬‬ ‫אך כושלות בסביבת ייצור מרובת עומסים‪ .‬ברמת ‪ 100‬משתמשים בו‪-‬זמניים‪,‬‬ ‫ברירות המחדל של תצורת ‪ ,APACHE‬כמו למשל מספר החיבורים המקסימאלי‬ ‫המותר‪ ,‬חושפות את מגבלותיהן‪ .‬מומחה מנוסה יכול בקלות לזהות ולפתור‬ ‫בעיות מעין אלה על ידי הגדלת ערכי הסף הרלוונטיים‪.‬‬ ‫יישום שאילתות לבסיס הנתונים )‪ (database query utilization‬הוא מקור‬ ‫נפוץ נוסף לבעיות ביישומי רשת‪ .‬מאחר ומרבית השאילתות עדיין נכתבות‬ ‫על ידי מפתחים‪ ,‬מאגר נתונים גדול ומערכת איחזור נתונים מורכבת הם סוס‬ ‫טרויאני בחצר האחורית של יישומי רשת‪ .‬ברמת ‪ 500‬משתמשים בו‪-‬זמניים היה‬ ‫צורך בניצול שאילתות למאגר הנתונים‪ .‬בשלב זה שופרו מבני שאילתות ‪,SQL‬‬ ‫כמו גם שיטות לחילול שאילתות ‪ inline‬ברמת קוד‪.‬‬ ‫אחרי שפתרנו את הבעיות הפשוטות‪ ,‬נוכל לגשת אל עבודת הנמלים הכרוכה‬ ‫בשיפור היבטים נוספים של ביצועי היישום‪ .‬נקודות תורפה נוספות היכולות‬ ‫להאט את ביצועי היישום או לפגוע ביציבות המערכת עשויות להסתתר בכל‬ ‫מקום‪ .‬קוד לא יעיל‪ ,‬קיפאון של בסיס הנתונים )‪,(database deadlock‬‬ ‫תצורת המערכת‪ ,‬קבוצות גדולות של תוצאות‪ ,‬ואפילו מנוע חיפוש‪ ,‬כל אחד‬ ‫מאלה עשויים לשחק תפקיד‪ .‬תצורת התשתית‪ ,‬שאילתות לבסיס הנתונים‬ ‫ואיכותו הבסיסית של הקוד כבר תוקנו‪ .‬שימוש מושכל במטמון )‪ (cache‬של‬ ‫היישום ושל שרת הרשת יכול לשדרג את הביצועים ולמנוע כשל מערכתי‪ .‬אופן‬ ‫יישום מנגנון החיפוש חשוב אף הוא ועשוי להשפיע באופן משמעותי על רמת‬ ‫הביצועים הכוללת‪.‬‬ ‫התוצאות שהושגו‬ ‫באמצעות הגדלה הולכת וגוברת של העומס ופתרון עוקב של בעיות אחת‬ ‫אחר השנייה הצלחנו להשיג את התוצאות הבאות‪:‬‬ ‫תמיכה במשתמשים‪ /‬שיחים בו‪-‬זמניים — הגדלה מ‪ 10 -‬ל‪) 1000 -‬פי ‪.(100‬‬ ‫שיפור אמינות המערכת — מ‪ 90% -‬כשל ל‪ 100%~ -‬מערכת אמינה‪.‬‬ ‫צמצום זמן התגובה – מדקה אחת לפחות משניה‪.‬‬ ‫שיפור תפוקת המערכת )‪ — (throughput‬מ‪ 13 -‬דפים ל‪ 166 -‬דפים לדקה‪.‬‬

‫סיכום‬

‫בדיקות ביצועים הן קריטיות עבור יישומי רשת מודרניים‪ .‬תהליך‬ ‫אבטחת האיכות הפונקציונאלית הסטנדרטי אינו יכול לאתר פגמים‬ ‫תלויי‪-‬ביצועים‪ .‬מערך בדיקות מדויק ויעיל מסייע באיתור בעיות‬ ‫מגוונות ביישום‪ ,‬כגון‪ :‬צווארי בקבוק‪ ,‬דליפות זיכרון‪ ,‬כשל מערכת‬ ‫ושאר דפוסי התנהגות בלתי אמינה‪ .‬בדיקות ביצועים יכולות לשמש‬ ‫גם בתכנון קיבול )‪ (capacity‬המערכת והחומרה ובתכנון גבולות‬ ‫בטוחים לעלויות התשתית‪.‬‬

‫‪ 30‬׀ מגזין חושבים בדיקות ׀ ינואר ‪2011‬‬

‫‪27-Dec-10 11:07:54 AM‬‬

‫‪Yesumim.indd 30‬‬


‫‪3000‬‬ ‫‪2500‬‬

‫‪Re 22/08‬‬ ‫‪10 que /200‬‬ ‫‪mi sts 7‬‬ ‫‪nu pe‬‬ ‫‪tes r‬‬

‫‪2000‬‬ ‫‪1500‬‬ ‫‪1000‬‬ ‫‪500‬‬ ‫‪0‬‬

‫‪00:00‬‬ ‫‪01:00‬‬ ‫‪02:00‬‬ ‫‪03:00‬‬ ‫‪04:00‬‬ ‫‪05:00‬‬ ‫‪06:00‬‬ ‫‪07:00‬‬ ‫‪08:00‬‬ ‫‪09:00‬‬ ‫‪10:00‬‬ ‫‪11:00‬‬ ‫‪12:00‬‬ ‫‪13:00‬‬ ‫‪14:00‬‬ ‫‪15:00‬‬ ‫‪16:00‬‬ ‫‪17:00‬‬ ‫‪18:00‬‬ ‫‪19:00‬‬ ‫‪20:00‬‬ ‫‪21:00‬‬ ‫‪22:00‬‬ ‫‪23:00‬‬ ‫‪24:00‬‬ ‫איור ‪ .1‬שיאי פעילות משתמשים ביום פרסום התוצאות‬

‫נחום דימר‬

‫נחום דימר הינו יזם ‪ IT‬ומנכ“ל‬ ‫‪ ,TEST4LOAD‬ספק מוביל‬ ‫של בדיקות עומסים ושירותי‬ ‫אופטימיזצית ביצועים‪ .‬מר‬ ‫דימר מעורב בפיתוח‪ ,‬בדיקות‬ ‫וניהול של מגוון פרוייקטים‬ ‫בתחום תוכנה ומערכות‬ ‫ארגוניות‪ .‬יש לו ניסיון עשיר‬ ‫ורקע טכנולוגי מעמיק במגוון‬ ‫תחומים הכולל תוכנות‬ ‫וביצועים הנדסה‪ ,‬וכן אבטחת‬ ‫איכות של מערכות אינטרנט‬ ‫וטלקום‪.‬‬ ‫‪ TEST4LOAD‬עוזר לתכנן‪,‬‬ ‫ליישם‪ ,‬לבדוק ולמטב היבטים‬ ‫ביצועים של מערכות תוכנה‬ ‫מרובת משתמשים‪ .‬בין לקוחות‬ ‫החברה נמנים חברות מובילות‬ ‫מהארץ ומהעולם‪.‬‬

‫איור ‪ .2‬סביבת ייצור )‪ (Production‬מול סביבת בדיקה )‪(Test‬‬

‫האתגר‬ ‫האתגר האמיתי מהיבט הביצועים הוא יום פרסום תוצאות המבחנים‪ .‬בזמן‬ ‫שהמערכת מספקת ניתוח של תוצאות המבחנים‪ ,‬נוצר עומס כבד ביותר על‬ ‫המערכת במשך מספר ימים לאחר תאריך פרסום התוצאות‪ .‬העומס הרגיל של‬ ‫‪ 10‬דפים לדקה‪ ,‬מטפס עד ל ‪ 300‬דפים לדקה ביום הפרסום‪ .‬איור ‪ 1‬מדגים את‬ ‫העליה הדרמטית בפעילות המשתמשים במהלך יום פרסום התוצאות‪.‬‬ ‫שיא הפעילות נרשם בין השעות ‪ 8:00‬ל ‪ 11:00‬בבוקר ביום פרסום התוצאות‪.‬‬ ‫לפניכם מספר נתונים מספריים‪:‬‬ ‫‪ ‬בסיס הנתונים מונה יותר מ ‪ 100‬מיליון רשומות‬ ‫‪ 10 ‬מיליון רשומות פעילות‬ ‫‪ 70,000 ‬משתמשים‬ ‫‪ ‬עומס של פחות מ ‪ 10‬דפים ‪ /‬דקה ביום רגיל‬ ‫‪ ‬שיא של ‪ 300‬דפים ‪ /‬דקה ביום פרסום התוצאות‬ ‫סביבת פיתוח ובדיקה‬ ‫על מנת לקבל תוצאות אמינות יש צורך בסביבת בדיקה נכונה‪ .‬סביבת הבדיקה‬ ‫האידיאלית צריכה להיות זהה לסביבת הייצור‪ ,‬גם מבחינת התוכנה וגם מבחינת‬ ‫החומרה‪ .‬למרבה הצער‪ ,‬בפועל‪ ,‬סביבת הבדיקה שונה משמעותית מסביבת‬ ‫הייצור‪ .‬הסיבה העיקרית לכך היא בדרך כלל העלות הגבוהה של החזקת סביבת‬ ‫ייצור נפרדת‪ .‬יישום חדש לרוב מוטמע על גבי סביבה קיימת‪ ,‬אשר כבר משמשת‬ ‫מספר יישומים אחרים‪ .‬הגישה הטובה ביותר במקרים אלה היא להכין ”גרסה קלה“‬ ‫של סביבת הייצור ולערוך עליה את רוב הבדיקות‪ .‬אם עושים שימוש בצבר של‬

‫שרתים‪” ,‬הגרסה הקלה“ צריכה לכלול שרת יחיד עבור כל שכבה בצבר‪ ,‬ולהתאים‬ ‫למפרטי החומרה והתוכנה שבסביבת הייצור האמיתית‪ .‬גישה זו מודגמת באיור ‪.2‬‬ ‫תכנון בדיקות‬ ‫תכלית בדיקות העומסים שונה לחלוטין מזו של בדיקות פונקציונאליות‪ .‬בדיקות‬ ‫פונקציונאליות מכוונות כלפי כל ההיבטים הפונקציונאליים של המערכת‪ ,‬החל‬ ‫מאימות רכיבי ממשק המשתמש )‪ (UI‬וכלה באימות לוגיקה עסקית מורכבת של‬ ‫המערכת‪ .‬בניגוד לבדיקות פונקציונאליות‪ ,‬בדיקות עומסים הינן מערכת אימות‬ ‫ביצועים המושפעת משימוש כבד במערכת‪ .‬במהלך מחזור חיי מוצר‪ ,‬בדיקות‬ ‫העומסים מתבצעות אחרי אימות האיכות הפונקציונאלית של המערכת‪ .‬בדיקות‬ ‫עומסים משמעותן אימות איכותה של מערכת הניהול )‪ ,(backend‬אשר נתונה‬ ‫בעיקר להשפעת שימוש כבד‪ .‬הבדל עקרוני זה הוא המפתח לתכנון הבדיקות‪.‬‬ ‫זיהוי תרחישי בדיקה‬ ‫אחד המרכיבים החשובים בתכנון בדיקה הוא זיהוי תרחישי הבדיקה המתאימים‪.‬‬ ‫בדרך כלל‪ ,‬תרחיש יחיד מקביל לתהליך עסקי המייצג מחזור אינטראקציה של‬ ‫המשתמש עם המערכת‪ .‬למשל‪ ,‬במקרה של ‪ ,AQA‬אחד התרחישים המוגדרים‬ ‫היה ”בדיקת התוצאות של תלמיד מסוים“‪ .‬התרחיש כלל את הפעולות הבאות‪:‬‬ ‫‪ .1‬היכנס למערכת‬ ‫‪ .2‬מצא בחינה‬ ‫‪ .3‬בדוק תוצאות עבור תלמיד מסוים‬ ‫‪ .4‬צא מן המערכת‬

‫מגזין חושבים בדיקות ׀ ינואר ‪ 2011‬׀ ‪29‬‬ ‫‪27-Dec-10 11:07:54 AM‬‬

‫‪Yesumim.indd 29‬‬


‫בדיקה‬ ‫ואופטימיזציה‬ ‫של ביצועי‬ ‫יישום רשת‬

‫מקרה בוחן‬ ‫מאת נחום דימר‬

‫הקדמה‬

‫מורכבותם של יישומי אינטרנט מודרניים והמספר הגדל של משתמשים‬ ‫פוטנציאליים מעלה מדרגה את נושא אבטחת איכות התוכנה‪ .‬לא ניתן עוד‬ ‫להסתפק באימות פונקציונאלי מפורט‪ .‬מעתה יש צורך בתהליך אבטחת‬ ‫ביצועים ייעודי‪ .‬בנקודה זו מצטרפת בדיקת ביצועים ועומסים למשחק‪ .‬מגובּה‬ ‫על ידי כלים אוטומטיים המסוגלים לדמות מספר גדול של משתמשים‪ ,‬היא‬ ‫מספקת שיטה מתוחכמת למידול ובדיקה של ביצועי המערכת‪ ,‬ומסייעת‬ ‫באיתור עיכובים בביצועי התוכנה‪.‬‬ ‫מילות מפתח‪ :‬ביצועי תוכנה‪ ,‬בדיקות עומסים‪ ,‬בדיקות ביצועים‪ ,‬אבטחת‬ ‫איכות התוכנה‪ ,‬הנדסת ביצועים )‪.(Performance Engineering‬‬ ‫במקביל לדרישה הקריטית של מרבית התוכנות היום לביצועי תוכנה‬ ‫מיטביים‪ ,‬פותחה גישה יסודית חדשה הנקראת הנדסת ביצועי תוכנה‬ ‫‪ SPE .(Software Performance Engineering) SPE‬מתייחסת לתהליך‬ ‫המבטיח שמערכת תוכנה תעבור תכנון‪ ,‬יישום‪ ,‬הטמעה‪ ,‬ותחזוקה באופן העולה‬ ‫בקנה אחד עם הדרישות העסקיות והביצועיות‪ .‬בדיקת ביצועים ועומסים הינה‬ ‫תת‪-‬קבוצה ומנגנון אימות מרכזיים של הנדסת ביצועי תוכנה‪.‬‬ ‫בדיקת ביצועים ‪ -‬מהי?‬ ‫בדיקת ביצועים מתייחסת באופן כללי למידול השימוש הצפוי בתוכנה‪,‬‬ ‫באמצעות סימולציה של גישה בו‪-‬זמנית של משתמשים רבים אל שרותי‬ ‫התוכנה‪ .‬בדרך כלל שירותים אלה מקבילים למקרי השימוש )‪ (use case‬או‬ ‫לתהליכים העסקיים של המערכת‪ ,‬ומכונים תרחישי בדיקה‪.‬‬ ‫ככאלה‪ ,‬בדיקות ביצועים ובדיקות עומסים הן הרלוונטיות ביותר עבור‬ ‫מערכות מרובות‪-‬משתמשים‪ ,‬אשר נבנות לרוב באמצעות מודל שרת‪/‬‬ ‫לקוח‪ ,‬כגון ישומי אינטרנט‪ .‬דוגמאות נוספות למערכות מרובות‪-‬משתמשים‬ ‫הן מערכות ותיקות )‪ ,(legacy systems‬מחשבים מרוחקים‪ ,‬יישומי דואר‬ ‫אלקטרוני‪ ,‬וכו‘‪.‬‬

‫הפופולאריות הגוברת של יישומי‬ ‫רשת והגידול במספר המשתמשים‬ ‫הפוטנציאליים ביישומי רשת מהווים‬ ‫אתגר למהנדסי מערכות‪ ,‬למפתחים‬ ‫בדיקת ביצועים ‪ -‬לשם מה?‬ ‫ישנן סיבות טכניות ועסקיות רבות לכך שתרצה להבטיח את ביצועי היישום שלך‪.‬‬ ‫ולבודקים‪ .‬עם הגידול במהירות הגלישה‪,‬‬ ‫אולם‪ ,‬תהא הסיבה אשר תהיה‪ ,‬ישנו גורם סיבתי משותף לכולם והוא‪ :‬מערכות‬ ‫מרובות‪-‬משתמשים מתוכננות‪ ,‬מפותחות ונבדקות בסביבת משתמש יחיד‪ .‬לרוב‪,‬‬ ‫משתמשים אינם מוכנים עוד להשלים עם‬ ‫אין המפתחים או צוות ה‪ QA-‬מודעים לאינטראקציות בביצועים‪ ,‬למגבלות או‬ ‫לדרישות החומרה במסגרת מערכת מרובת‪-‬משתמשים‪ .‬מה עוד שהאפיון של‬ ‫מהירות תגובה איטית או כשל של היישום‪.‬‬ ‫מערכות רבות אינו כולל דרישות ברורות או ברות‪-‬מדידה לביצועים‪ ,‬להסתלמות‪,‬‬ ‫כתוצאה מכך אנו עדים לסטנדרטים‬ ‫או לאמינות‪ ,‬ולמרות היעדרן‪ ,‬פרויקטים נידונים ככישלונות כאשר בעיות ביצועים‬ ‫צצות במציאות‪ .‬ישנן סיבות רבות לבצע בדיקות‪ ,‬אך המניעים העיקריים הם‪:‬‬ ‫גבוהים ולדרישה מוגברת לפיתוח‬ ‫‪ ‬מניעת כשלים עתירי‪-‬עלות ביישום קריטי‬ ‫יישומים אפקטיביים יותר‪ ,‬וכן לדחיפת‬ ‫‪ ‬סימולציה של עומס העבודה במציאות‬ ‫‪ ‬מציאת גבולות היכולת של המערכת שלך‬ ‫ההסתלמות )‪ (scalability‬והביצועים‬ ‫‪ ‬איתור בעיות פוטנציאליות לפני שיעשה זאת הלקוח‬ ‫עד גבול היכולת‪ .‬המחיר שחברה עלולה‬ ‫‪ ‬קיצור מחזור הפיתוח וזמן היציאה לשוק )‪(TTM‬‬ ‫‪ ‬חיזוי של עלויות תשתית והקטנתן‬ ‫לשלם במקרה שתימנע מלקיחת היבטי‬ ‫‪ ‬הבטחת הסכם רמת השרות )‪(SLA‬‬ ‫הביצועים בחשבון יכול להיות גבוה‬ ‫מקרה הבוחן‬ ‫ביותר‪ .‬מקרה הבוחן יתאר תהליך בדיקה‬ ‫רקע‬ ‫ואופטימיזציה של יישום רשת בקנה מידה‬ ‫האגודה להערכה ולהסמכה )‪ (AQA‬היא הגדולה מבין שלושת הגופים‬ ‫המעריכים באנגליה‪ :‬היא המעניקה ‪ 49%‬מתעודות הבגרות ברמת ‪GCSE‬‬ ‫גדול‪ .‬הדוגמאות תוספנה תובנה על אילוצי‬ ‫ו‪ 42% -‬מהבגרויות ברמה הגבוהה )‪ .(A-level‬בסך הכל האגודה בוחנת יותר‬ ‫מ‪ 3.5 -‬מליון תלמידים מדי שנה‪.‬‬ ‫המציאות‪ ,‬הקשיים‪ ,‬האתגרים ועבודת‬ ‫‪ AQA‬פיתחה אתר אקסטרה‪-‬נט בקנה מידה גדול המאפשר למורים לגשת‬ ‫הצוות‪ .‬מקרה הבוחן מכוון אל מתחילים‬ ‫למידע ייחודי לבית הספר או לאוניברסיטה שלהם ולראות ניתוח מיידי של‬ ‫ומומחים‪ ,‬ואל צוות ניהולי וטכני כאחד‪.‬‬ ‫תוצאות המבחנים‪.‬‬ ‫‪ 28‬׀ מגזין חושבים בדיקות ׀ ינואר ‪2011‬‬

‫‪27-Dec-10 11:07:53 AM‬‬

‫‪Yesumim.indd 28‬‬


‫פיתוח יישומים מתקדמים‬ ‫לתוצאות עסקיות‬ ‫טובות יותר‪.‬‬ ‫פתרונות התוכנה החדשים של‬ ‫תוכננו על מנת לשפר‪:‬‬ ‫> איכות‬ ‫> יכולת ניבוי‬ ‫> מוכנות לשינויים‬

‫‪HP‬‬

‫פרטים על הגרסה החדשה של‬ ‫‪:HP Applications Solutions‬‬ ‫‪www.hp.co.il/alm‬‬

‫עלויות נמוכות יותר‪.‬‬ ‫גמישות גבוהה יותר‪.‬‬ ‫איכות טובה יותר‪.‬‬ ‫‪LET’S DO AMAZING‬‬

‫‪www.hp.com/go/alm‬‬


‫איך )‪ (NOT‬לפשל באוטומציה‬ ‫זכור‪ ,‬בחירת הכלי המתאים אינה מדע מדוייק‪ ,‬אך תהליך מקדים וחשוב‪ .‬גם‬ ‫אם הוא צורך זמן יקר של למידה‪ ,‬חקירה ובדיקת היתכנות תעזור לך מאוד‬ ‫בביטחון שהכלי הנבחר הוא המתאים ביותר למשימה‪.‬‬

‫הנהלה ‪ vs‬אוטומציה‬

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

‫מגזין‬

‫חושבים‬ ‫חושבים‬ ‫חו‬

‫קות‬ ‫ת‬ ‫בדיקו‬

‫אז מה הפתרון שאנו מציעים?‬

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

‫סיכום‬

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

‫קישורים מומלצים‪:‬‬

‫‪Watir – http://www.watir.com‬‬ ‫‪WatiN – http://watin.sourceforge.net‬‬ ‫‪Selenium – http://www.seleniumhq.org‬‬ ‫‪STAF – http://staf.sourceforge.net‬‬ ‫‪AutoIT – http://www.autoitscript.com‬‬ ‫‪Subversion – http://subversion.apache.org‬‬ ‫‪QA Forums – http://www.qaforums.com‬‬ ‫‪Advanced QTP – http://www.advancedqtp.com‬‬

‫רוצה ליצור תוכן מעניין ולשתף‬ ‫את קהל הבודקים בישראל?‬

‫גם אם אין לכך ניסיון בכתיבה או אם אתה מתקשה לבטא‬ ‫הרעיון שלך בכתב‪ ,‬אנחנו כאן לעזור!‬ ‫כותבים המעונינים לקחת חלק בכתיבה עבור הגליונות הבאים‬ ‫מוזמנים ליצור קשר‪info@thinktesting.co.il :‬‬

‫‪www.ThinkTesting.co.il‬‬ ‫‪27-Dec-10 11:00:21 AM‬‬

‫‪Optimisation (NOT).indd 26‬‬


‫ל‬

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

‫אז מה הפתרון שאנו מציעים?‬

‫על מנת לבצע הערכות ריאליות יותר‪ ,‬ולעמוד בהם מומלץ ביותר‪:‬‬ ‫‪ ‬לברר האם השלב בחיי הפיתוח של המוצר הינו ראוי להפוך‬ ‫לאוטומטי‪ .‬בדר”כ‪ ,‬בשלבים המוקדמים של הפיתוח‪ ,‬התוכנה‬ ‫משתנה בתדירות גבוהה שינויים גדולים (שינויים מבניים‪,‬‬ ‫פונקציונאליים וויזואליים)‪ ,‬והדבר עשוי להיות מתסכל ביותר‪.‬‬ ‫אוטומציה שעבדה מצוין אתמול‪ ,‬כבר לא רלוונטית היום‪.‬‬ ‫‪ ‬לבדוק איך ניתן לבצע אוטומציה לאותה טכנולוגיה בה‬ ‫משתמשים לפיתוח המוצר‪ .‬האם יש צורך לרכוש ‪ /‬להטמיע‬ ‫כלים חדשים? האם ניתן ללמוד מנסיון של קבוצות אחרות‬ ‫שכבר חוו אוטומציה של טכנולוגיה דומה וניתן ללמוד‬ ‫מהטעויות שלהם? לבטח אלו מאיתנו אשר ניסו לאטמט‬ ‫לאחרונה אפליקצייה מבוססת ‪ Flex‬יסכימו‪.‬‬ ‫‪ ‬להכין פרוייקט היתכנות קצר‪ ,‬שידגים בצורה ממשית‬ ‫אוטומציה של חלק קטן מהמוצר‪ .‬פרוייקט פיילוט כזה יכול‬ ‫לתת מושג הרבה יותר ודאי ופחות מסוכן לגבי הערכות‬ ‫הזמנים של הפרוייקט כולו‪.‬‬ ‫‪ ‬לחשב את יחס ההשקעה – תפוקה של הפרוייקט (‪ROI‬‬ ‫‪ .)Return On Investment‬במידה ואת התרחיש המועמד‬ ‫מריצים רק פעמיים בשנה לדוגמה‪ ,‬האוטומציה שלו אמורה‬ ‫להתבצע מהר מאוד‪ ,‬אחרת ההשקעה תהפוך להיות מאוד‬ ‫לא כלכלית על פני חלופה של המשך ביצוע בצורה ידנית‪.‬‬ ‫‪ ‬תחזוקה של הקוד האוטומטי – להבדיל מפרויקט פיתוח‬ ‫תוכנה‪ ,‬פיתוח אוטומציה‪ ,‬במיוחד בשכבה העליונה של מנשק‬ ‫המשתמש‪ ,‬דורשת תחזוקה יקרה לאורך זמן‪ .‬שינויי תוכנה‬ ‫דורשים התאמות עקביות של האוטומציה‪ ,‬דבר המצריך‬ ‫משאבי תחזוקה יקרים‪ .‬האם יש בידך המשאבים והיכולת‬ ‫לתחזק ולשמר את קוד האוטומציה לאורך חיי התוכנה?‬ ‫נדגיש‪ ,‬כי ניתן להפוך כל תהליך פורמלי לאוטומטי‪ .‬לאו דווקא‬ ‫בדיקות‪ .‬לעיתים רבות‪ ,‬הבדיקות עצמן מאוטמטות בהצלחה‪,‬‬ ‫אולם כדי להריץ אותן‪ ,‬יש צורך לדאוג לתצורת מערכת‬ ‫מסוימת‪ ,‬אותה יש לבצע ידנית‪ .‬תרחיש כזה רחוק מלהיות‬ ‫אידיאלי‪ .‬המטרה היחידה‪ ,‬מאז ומעולם של אוטומציה‪ ,‬הינה‬ ‫לפנות משאבים אנושיים לפעולות יקרות ואיכותיות יותר‪.‬‬ ‫עלינו לדאוג שהרובוט לא מצפה שנמשיך להחזיק את ידו‪.‬‬

‫בחירת הכלי המתאים‬

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

‫מאת ערן נלינגר ואסף סער ‪http://www.‬‬

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

‫אז מה הפתרון שאנו מציעים?‬

‫להלן מספר שאלות‪ ,‬התשובות עליהן עשויות לעזור לך מאוד‬ ‫בצמצום האפשרויות והכוונה בבחירת הכלי הראוי‪:‬‬ ‫‪ ‬האם יש בידך תקציב לכלי מסחרי כדוגמת ‪IBM Rational‬‬ ‫‪ Test‬או ‪ HP QTP‬או שאתה מחויב בבחירת כלי מבוסס‬ ‫קוד פתוח כגון ‪ Selenium‬או ‪?WATIR‬‬ ‫‪ ‬מי יהיו מפתחי האוטומציה? האם יש ביכולתם לפתח ולהרחיב‬ ‫פלטפורמה קיימת או אף פיתוח מערכת חדשה מהיסוד?‬ ‫‪ ‬רשום לפחות שלושה עוגנים‪ ,‬כל פלטפורמה אופציונלית‬ ‫תהיה חייבת לעמוד בהם‪ .‬עוגנים לדוגמא‪ :‬יכולת לאטמט‬ ‫אפליקציות ‪ ,Flex‬פיתוח תסריטי אוטומציה בשפת ‪,Java‬‬ ‫אוטומציה מונחה נתונים‪ ,‬רשיון קוד פתוח‪ ,‬חינמי‪ ,‬יכולת‬ ‫לאטמט דפדנים שונים‪ ,‬אינטגרציה למערכות קיימות‪.‬‬ ‫‪ ‬האם האפליקציה אותה אתה שואף לאטמט משתמשת‬ ‫בטכנולוגיה סטנדרטית או ייחודית למוצר? לדוגמא‬ ‫איטמוט ‪ Java Applet‬פרי פיתוח פנימית אשר מזוהה‬ ‫כקופסא שחורה לכלי האוטמציה‪ ,‬ללא יכולת זיהוי ותפעול‬ ‫מנשק התוכנה‪.‬‬ ‫‪ ‬האם אתה מאמין שהקלטת סקריפט וניגונו בצורה‬ ‫אוטומטית תעבוד? (רמז‪ :‬היא לא‪)...‬‬ ‫‪ ‬מהי רמת התמיכה הטכנית המסופקת על ידי יצרן התוכנה‬ ‫‪ /‬קהילת הפיתוח?‬ ‫לאחר צמצום מספר האפשרויות מגיע שלב המחקר‬ ‫ובדיקת ההיתכנות (‪ )POC = Proof Of Concept‬של‬ ‫הכלים המוצעים‪ .‬שלב זה מאופיין‪ ,‬ראשית‪ ,‬בלימוד‬ ‫וחקירת יכולותיו‪ ,‬ייתרונותיו ומגבלותיו של כל כלי‪ .‬הקדש‬ ‫זמן ללימוד הכלים‪ .‬היה סמוך ובטוח שרבים וטובים‬ ‫כבר בדקו‪ ,‬חקרו וניסו את הפתרונות המוצעים‪ .‬שיטוט‬ ‫בפורומים רלוונטים‪ ,‬קריאת בלוגים של מומחים בתחום‬ ‫ואתרים מקצועיים בנושא הם נכס שלא יסולא בפז‪.‬‬ ‫השלב השני‪ ,‬והחשוב ביותר‪ ,‬הוא בדיקת היתכנות‪ ,‬בחר‬ ‫תסריט נפוץ (רצוי לא פשוט) באפלקיציה שלך ואטמט‬ ‫אותו‪ .‬בצע זאת עם כל הכלים הפיינליסטים שלך‪ .‬אין‬ ‫תחליף ללמידה בידיים‪ .‬הקשיים‪ ,‬האתגרים המכשולים‬ ‫וההצלחות עם כל כלי יעזרו לך מאוד בבחירה‪.‬‬

‫ערן נלינגר‬ ‫ערן נלינגר הצטרף לקבוצת הבטחת‬ ‫האיכות של ‪ SAP Labs‬ישראל כסטודנט‬ ‫להנדסה (אוניברסיטת בן גוריון)‪ ,‬בתוכנית‬ ‫לסטודנטים מצטיינים בשנת ‪.2005‬‬ ‫לאחר תפקידי בדיקות שונים בתחומי‬ ‫הבדיקות הידניות‪ ,‬האוטומטיות‬ ‫ומבוססות הקוד‪ ,‬ערן בנה והוביל צוות‬ ‫חדש שפיתח תשתית לבדיקות ‪SDK‬‬ ‫בסביבת ‪.J2EE‬‬ ‫כיום ערן מוביל פרוייקט פיתוח של‬ ‫תשתית אוטומציה הנותנת מענה ל‪6 -‬‬ ‫פרוייקטי תוכנה המפותחים במעבדה‪,‬‬ ‫וכולל פתרונות אוטומטיים לבדיקות‬ ‫פונקציונאליות‪ ,‬בדיקות ‪,Performance‬‬ ‫ואלמנטים נוספים במחזור חיי התוכנה‪.‬‬ ‫ערן נשוי לקרולינה ומתגורר בכפר‪-‬יונה‪.‬‬

‫אסף סער‬ ‫אסף סער עוסק בתחום בדיקות התוכנה‬ ‫מזה ‪ 14‬שנה‪ .‬לאסף נסיון רב בניהול‬ ‫בדיקות תוכנה בחברות בינלאומיות‪,‬‬ ‫בינוניות וקטנות בארץ ובארה”ב‪ .‬במהלך‬ ‫השנים אסף הקים קבוצות בדיקות‪ ,‬ניהל‬ ‫פרוייקטי תוכנה‪ ,‬פיתח ויישם תשתיות‬ ‫בדיקות והטמעת פרוייקטי אוטומציה‬ ‫בחברות השונות‪.‬‬ ‫מזה ‪ 4‬שנים אסף עובד בחברת ‪Labs‬‬ ‫‪ SAP‬ברעננה‪ ,‬בתפקידו הנוכחי הינו מנהל‬ ‫קבוצת ‪Quality Engineering SAP‬‬ ‫‪ Portals‬העוסקת בבדיקות פונקציונליות‪,‬‬ ‫בדיקות ביצועים‪ ,‬פיתוח ויישום תשתיות‬ ‫אוטומציה תומכות תהליכי פיתוח בחברה‪.‬‬ ‫אסף נשוי למירב‪ ,‬אב לשלושה ילדים‬ ‫ומתגורר בתל מונד‪.‬‬ ‫הבלוג של אסף ‪http://www.asaf.co.il‬‬

‫מגזין חושבים בדיקות ׀ ינואר ‪ 2011‬׀ ‪25‬‬ ‫‪27-Dec-10 11:00:00 AM‬‬

‫‪Optimisation (NOT).indd 25‬‬


‫איך (‪ )NOT‬לפשל‬ ‫כבודקי תוכנה מנוסים‪ ,‬למדנו ושמענו כי בדיקות אוטומטיות‬ ‫יכולות להיות הפתרון להרבה מבעיות היום‪-‬יום שלנו‪ ,‬בין אם‬ ‫מדובר בביצוע בדיקות חוזרות ונשנות של תסריטי הרגרסיה‪,‬‬ ‫כיסוי לא הגיוני של מטריצת הבדיקות או עמידה בלוחות‬ ‫זמנים לא סבירים‪ .‬תשתיות וכלי אוטומציה חדשים צצים‬ ‫כמו פטריות אחרי הגשם‪ .‬אנו למדים כי בדיקות אוטומטיות‬ ‫הן חלק בסיסי ויסודי במתודולוגיות ‪ Lean‬ו‪ ,Scrum -‬כנסים‬ ‫מקצועיים בהם אנו נוכחים עמוסים לעייפה בסיפורי הצלחה‬ ‫של הטמעות אוטומציה ועוד‪ .‬אנחנו משוכנעים‪ :‬אם זה עובד‬ ‫עבורם‪ ,‬זה חייב לעבוד גם לנו!‬ ‫תוכניות לחוד ומציאות לחוד‪ :‬השקעה והטמעה של פרוייקטי אוטומציה היא‬ ‫אתגר לא פשוט‪ .‬נסיון העבר שלנו מלמד כי הדרך להצלחה רצופה במכשולים‪.‬‬ ‫להלן סוגיות נפוצות בכשלון אוטומציה‪ ,‬אותן חווינו לאורך דרכנו המקצועית‪,‬‬ ‫המלצות והצעות בדרך ליישום מוצלח‪.���‬

‫הנדסה של תהליכי אוטמציה‬

‫בהקשר של הכתבה הזו‪ ,‬החיבור בין אוטומציה לתהליכי פיתוח תוכנה‪ ,‬עשוי‬ ‫להתפרש בשני מובנים‪ .‬הראשון ידבר על אוטומציה ככלי תומך להשבחת‬ ‫האיכות של התוכנה המפותחת; השני‪ ,‬לעומת זאת‪ ,‬מתייחס לאוטומציה עצמה‬ ‫כאל התוכנה שיש לפתח‪.‬‬ ‫כמהנדס‪ ,‬אתה ודאי יודע שעולם פיתוח התוכנה המודרני‪ ,‬כולל כבר מימושים‬ ‫רבים לכלים ולתהליכים ההנדסיים שתומכים בו‪ .‬ניהול קוד מקור על גרסאותיו‬ ‫הרבות‪ ,‬כלים לבניית ואריזת הקוד‪ ,‬סביבות פיתוח‪ ,‬ועוד מושגים רבים יימצאו‬ ‫אינספור פעמים בחיפוש פשוט ברשת‪ ,‬ויציעו לנו כמעט כל מה שנוכל לדמיין‪,‬‬ ‫בחינם‪ ,‬וגם באלפי דולרים‪ .‬לעומת זאת‪ ,‬פיתוח של אוטומציית הבדיקות הינו‬ ‫תחום עולה‪ ,‬שנמצא ללא ספק לפני שיא או מיצוי‪.‬‬ ‫אם נשים לב לדבר‪ ,‬נוכל להבחין שמאפיינים של משימת פיתוח אוטומציה‪,‬‬ ‫דורשים ברמה ההנדסית‪ ,‬את אותה התשתית בדיוק כמו כל משימת פיתוח‬ ‫אחרת‪ :‬קוד המקור (או סקריפט המקור) נדרש להיות מאוחסן במערכת ניהול‬ ‫תצורה‪ ,‬כגון ‪ Perforce‬הקנייני או ‪ Subversion‬בעל רשיון הקוד הפתוח)‬ ‫אמיתית ולא על דיסק פשוט בלבד‪ ,‬גרסאות הבדיקות האוטומטיות צריכות‬ ‫להיות מנוהלות בצורה אוטומטית (ולמעשה במקביל בדיוק לגרסאות המוצר‬ ‫אותו הן נועדו לבדוק)‪ ,‬תשתית כלשהי אמורה לתמוך בתיאום הקוד במידה‬ ‫ויותר ממהנדס אחד (או יותר מתחנת עבודה אחת) מטפל באוטומציה‪.‬‬ ‫ארגונים רבים נוטים לשייך את משימות פיתוח האוטומציה לכאלה בעלות אופי‬ ‫טכני של בדיקות‪ ,‬יותר מאשר כאלה של פיתוח‪ .‬כתוצאה‪ ,‬התשתית ההנדסית‬ ‫הנדרשת לא נלקחת בחשבון‪ ,‬והמהנדסים האחראים‪ ,‬לדאבונם‪ ,‬מגלים שעליהם‬ ‫לטפל גם בניהול הקוד‪ ,‬העתקה ופיצול של הגרסאות השונות ועוד‪ .‬הדבר יביא‬ ‫במהרה לכישלון של פרוייקט אוטומציה‪.‬‬

‫אז מה הפתרון שאנו מציעים?‬

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

‫לחלוטין!)‪ ,‬גרסאות פרויקט האוטומציה צריכות להיגזר בדיוק מגירסאות‬ ‫המוצר‪ .‬להיעתק‪ ,‬להתפצל‪ ,‬להיפתח ולהיסגר בהתאם‪.‬‬

‫מפתח או בודק?‬

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

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

‫אז מה הפתרון שאנו מציעים?‬

‫גישה שיכולה להצליח מאוד היא “לגדל” מפתחי אוטומציה מתוך המאגר הקיים‬ ‫של מהנדסי הבדיקות‪ .‬היתרונות ברורים‪ :‬מתוך הקבוצה הקיימת יותר קל לזהות‬ ‫בודקים בעלי יכולות פיתוח‪ ,‬ובעלי רצון ויכולת ללמוד ולהצליח גם בתור מפתחי‬ ‫אוטומציה‪ .‬בכל קבוצת בדיקות ממוצעת ניתן לזהות מהנדסים כאלו‪ ,‬ואם מנהלים‬ ‫את החלוקה בצורה נכונה‪ ,‬ניתן גם דרך מסלול קריירה זה להציע לבודקים אפשרויות‬ ‫פיתוח אישיות בתוך הקבוצה ולהימנע מתופעה כאובה אחרת — מעבר של בודקים‬ ‫מוכשרים ומנוסים לקבוצת הפיתוח על מנת להתנסות באתגרים חדשים‪ .‬עלינו‬ ‫להיות זהירים‪ ,‬ולהצליב כאן יכולת אל מול רצון‪ :‬בודקים רבים ומנוסים לעיתים לא‬ ‫מעוניינים לבצע בדיקות לא – ידניות‪ ,‬והסבה של דמויות כאלה לפיתוח אוטומציה‬ ‫כנראה תיכשל‪ .‬מהנקודה בה זוהה מועמד‪ ,‬על המנהלים והחונכים המקצועיים‬ ‫לוודא שמוגשים לו כל הכלים הדרושים כדי להצליח בתפקיד‪ .‬האם אותו מהנדס‬ ‫מכיר את שפת התכנות ‪ /‬סקריפטינג בה אנו מממשים אוטומציה? האם יש‬ ‫צורך בקורס בסיסי על מנת להקנות עקרונות בסיסיים בפיתוח ‪ /‬אוטומציה לפני‬ ‫שיוצאים לדרך? האם הוקצה מספיק זמן לחניכה?‬ ‫מנסיוננו‪ ,‬מהנדס שהתחיל לממש בדיקות אוטומטיות לאחר הכשרה בסיסית‪,‬‬ ‫צורך זמן רב לפני שהוא שולט ברזי המקצוע‪ ,‬ולכן עלינו לוודא שהוא מקבל את‬ ‫הזמן והמרחב הדרושים כדי להסתגל למשימות החדשות‪ .‬גישות של חלוקת‬ ‫המשרה לחלקים קטנים בהם מוקצים רק יום או יומיים של עבודה בשבוע‬ ‫לאוטומציה‪ ,‬לרוב ייכשלו‪ ,‬עקב העובדה הפשוטה שלא יאפשרו מספיק זמן‬ ‫רצוף להפוך את המהנדס למקצוען בתחום‪.‬‬

‫מה לאטמט?‬

‫אחת השאלות המעניינות ביותר בתחום‪ ,‬היא‪“ :‬האם ניתן בכלל לאטמט (‪to-‬‬ ‫‪ )automate‬את זה??”‪ .‬אפליקציות מודרניות‪ ,‬בעלות ממשק משתמש חדשני‪,‬‬ ‫עם יכולות מגע‪ ,‬גרירה ושאר היכולות האינטואיטיביות למשתמש‪ ,‬הופכות קשות‬ ‫יותר ויותר לאוטומציה‪ .‬למעשה‪ ,‬ובאופן פרדוקסלי‪ ,‬ככל שממשק המשתמש הוא‬ ‫קל יותר למשתמש‪ ,‬הוא בדר”כ יהיה קשה יותר לאוטומציה‪ .‬כמו בכל דרישה‬ ‫אחרת בעולם ההנדסה‪ ,‬התשובה היא תמיד חד משמעית – ניתן להפוך כל תהליך‬ ‫פורמאלי לאוטומטי‪ .‬המשתנה היחיד הוא כמות המשאבים המושקעת בדבר‪.‬‬

‫‪ 24‬׀ מגזין חושבים בדיקות ׀ ינואר ‪2011‬‬

‫‪27-Dec-10 10:59:54 AM‬‬

‫‪Optimisation (NOT).indd 24‬‬


‫חדשנות‪ ,‬מובילות‪ ,‬יצירתיות‬ ‫לעבוד בחברת בדיקות מתמחה שמסתכלת קדימה‬ ‫ומרחיבה את שרותיה לעולמות חדשים ומרתקים‬ ‫עולם הבדיקות למובייל‬ ‫מגוון מכשירים ניידים במקום אחד‬ ‫שימוש בסימולטורים ואוטומציה‬ ‫עולם בדיקות אבטחת מידע‬ ‫‪Penetration Testing‬‬ ‫‪Security Auditing & Scanning‬‬ ‫עולם בדיקות ‪ BI‬ו‪DWH -‬‬

‫‪ - Quality Gates‬כלי ייחודי לבדיקות נתונים‬ ‫בדיקות אוטומטיות וידניות למגוון מערכות‬ ‫עולם הבדיקות ב‪cloud-‬‬ ‫בדיקות ביצועים ועומסים במודל ‪SAAS‬‬ ‫בדיקות אוטומציה במודל ‪SAAS‬‬

‫של טאקט בדיקות‪ ,‬לראות משרות פתוחות לפני כולם‬ ‫היכנסו לדף ה‪-‬‬ ‫להנות ממגוון הפתעות והטבות או לשמוע עוד על מגוון השירותים החדשים שלנו‬

‫‪www.tact.co.il | 08-9146000 | www.facebook.com/TactQA‬‬


‫סיקור ‪ -‬תחרות ”הצטיינות ישראלית בתחום הבדיקות“ של ‪ITCB‬‬

‫ישראלית בתחום הבדיקות“‬ ‫”הצטיינות‬ ‫תחרות‬ ‫של ‪ITCB‬‬ ‫האם תחום בדיקות התוכנה מוסדר בארץ באיזשהו אופן? האם יש כנסים?‬ ‫האם יש הסמכות? האם יש ארגונים מקצועיים? ומה לגבי מצטיינים בתחום‪,‬‬ ‫האם הם מקבלים הכרה מקצועית?‬ ‫הכירו את ‪ ITCB .ITCB‬הינה העמותה לקידום הסמכת בודקי התוכנה‬ ‫בישראל‪ .‬החברים בארגון הינם אנשי מקצוע מובילים בתחום הבדיקות‬ ‫הפועלים בהתנדבות וללא מטרות רווח‪ .‬העמותה שמה לה כמטרה‬ ‫עיקרית את קידום תחום בדיקות התוכנה והמערכות הממוחשבות‬ ‫כמקצוע מוכר בישראל על ידי הכשרת בודקים והענקת הסמכות והכרה‬ ‫מקצועיות‪.‬‬ ‫החל מאפריל ‪ 2004‬ארגון ‪ ITCB‬הינו שלוחה מוכרת ומאושרת של ארגון‬ ‫‪ ISTQB‬המעניק הסמכה בינלאומית בתחום הבדיקות‪ .‬חברי ארגון ‪ITCB‬‬ ‫הישראלי לוקחים חלק פעיל ומשפיע בוועדות ההיגוי והעשייה השונות‬

‫בארגון הבינלאומי‪ .‬עד כה‪ ,‬הוסמכו למעלה מ‪ 160,000 -‬מוסמכים ב ‪ISTQB‬‬ ‫ברחבי העולם ולמעלה מ‪ 2100 -‬בארץ‪.‬‬ ‫תחרות ”מצוינות בתחום הבדיקות בישראל“‪ ,‬המופעלת ברציפות מאז שנת‬ ‫‪ 2008‬ע“י ‪ ITCB‬ו‪ SIGiST-‬ישראל‪ ,‬נועדה להעניק הכרה לבודקים מקצועיים‬ ‫אשר תרמו תרומה משמעותית לתחום בדיקות התוכנה בישראל‪ .‬התחרות באה‬ ‫לקדם מנהיגות‪ ,‬תרומה ואפקטיביות בתהליכי בדיקות והטמעת בדיקות‪.‬‬ ‫את הרעיון לתחרות הגו חברי ‪ ITCB‬ו‪ SIGiST -‬שראו בתחרות קרקע פוריה‬ ‫לבניית בסיס מידע מקצועי של גישות‪ ,‬פתרונות ויישומים‪ .‬תהליך התחרות‬ ‫כלל הגשת מועמדות ע“י יחידים או קבוצות‪ ,‬בחינת המועמדויות ע“י הוועדה‬ ‫המקצועית והכרזה על הזוכים בטקס הרשמי שהתקיים ב‪ 15-‬בדצמבר‬ ‫בתל אביב בהשתתפות בודקי תוכנה מוסמכים ובכירים נוספים‪ .‬להלן תיאור‬ ‫פועלם של המועמדים הסופיים ושל הזוכים‪ ,‬שלום מיץ ואבי פרוכטר‪.‬‬

‫שלום מיץ ואבי פרוכטר‪NDS ,‬‬

‫הכלי שפיתחו שלום ואבי יועד לביצוע בדיקות אוטומטית עבור מערכות ‪ .Set Top Box‬בהתחלה ענה הכלי‬ ‫על האתגרים המיידיים של בדיקות תוכנה וחומרה משתנים‪ ,‬אך ככל שהתרחב השימוש‪ ,‬השפיע הכלי על‬ ‫פיתוח המערכת‪ .‬לדוגמה‪ :‬זיהוי גורמים בהתקנה ובקונפיגורציה של המערכת שהם מורכבים מידי ודורשים‬ ‫נסיון רב להתקנה; זיהוי גורמים בממשק משתמש שניתן לעשות פשוטים ומובנים יותר; מעקב אחרי מספר‬ ‫הבדיקות האוטומטיות שביצעו לקוחות שהשתמשו בכלי‪.‬‬ ‫כיום משתמשים בכלי כ‪ 20-‬מלקוחותיה הגדולים של ‪ NDS‬לצורך בדיקות טרום הכנסת מערכות חדשות‪.‬‬ ‫עקב קלות התחזוקה וההרחבה של הכלי‪ ,‬גופי בדיקות נוספים בחברה משתמשים בו וכיום מעל ‪50%‬‬ ‫מפעילות הבדיקות בחברה נעשות בעזרת הכלי‪.‬‬

‫‪1‬‬

‫אחת מקבוצות הבדיקה דיווחה על אוטומציה של בדיקות ביצועים שלא ניתן להריץ בצורה ידנית‪ ,‬והגיע‬ ‫לזמן מצטבר של הרצת ~‪ 4300‬שעות בדיקה‪.‬‬

‫לירון צור‪ ,‬אינטל‬

‫לירון פיתח את מערכת ‪ (Automated Test Lab Solution) ATLaS‬לבדיקה של מוצרי תקשורת אלחוטית בתקן ‪ .802.11‬מערכת‬ ‫‪ ATLaS‬שהחלה כהוכחת היתכנות בלבד‪ ,‬מציעה פתרון מקצה לקצה‪ .‬המערכת משמשת כיום להרצה לילית של בדיקות רגרסיה‬ ‫וסבבי בדיקות של משפחת מוצרי האלחוט כשהיא מתמודדת עם מעל ל‪ 70-‬אפשרויות קונפיגורציות בדיקה שונות‪ .‬המערכת‬ ‫מזהה תוכנה חדשה אותה צריך לבדוק‪ ,‬מגדירה אוטומטית את סביבת הבדיקות ואת סדרת הבדיקות הנדרשת ולאחר מכן מבצעת‬ ‫את הבדיקות על המערכות הרלוונטיות‪ .‬המערכת אוספת מידע על בדיקות שנכשלו ושולחת דו“חות לאנשים המתאימים‪.‬‬

‫אלי מרגולין‪KDTesting ,‬‬

‫אלי וצוות הבודקים שלו פיתחו כלי בדיקות אוטומטיות שיאפשר לאנשי בדיקות ללא ידע בתכנות לפתח ולהריץ בדיקות‬ ‫אוטומטיות כראות עיניהם‪ .‬אלי אפיין את הכלי על פי גישת ה‪ (Keyword Driven Testing) KDT -‬תוך שימוש במחסן מילים‬ ‫נרחב וגישה ישירה לרכיבי ממשק המשתמש )‪ .(GUI‬הכלי שפותח מכסה ‪ 95%‬מהמערכת הנבדקת‪ ,‬הן בצד התשתיות והן‬ ‫בצד האפליקציה‪.‬‬

‫פולינה לנגרמן‪ITG ,‬‬

‫פולינה פיתחה כלי לתכנון וביצוע בדיקות אוטומטיות שמיישם את גישת ‪ Keyword driven testing‬כך שהמשתמשים‬ ‫לא נדרשים להיות בעלי יכולות פיתוח‪ .‬ניתן להוסיף למערכת בדיקות חדשות ולערוך אותן בעזרת עורך טקסט מבלי‬ ‫לשנות את הקוד‪ .‬הכלי שפותח הותאם למוצרי ‪ ITG‬השונים וניתן היה לפתח בדיקות שונות לפרויקטים השונים מבלי‬ ‫לשנות את סביבת העבודה‪ .‬הטמעת הכלי בחברה אפשר לחברה לעבור ממתודולוגית ”מפל מים“ למתודולוגיה ‪,Agile‬‬ ‫תוך שינוי צורת המחשבה של האנשים‪ .‬כך‪ ,‬כל פרויקט חדש כולל דרישות ליכולות בדיקה ואוטומציה של המערכת‪.‬‬

‫‪ 22‬׀ מגזין חושבים בדיקות ׀ ינואר ‪2011‬‬

‫‪27-Dec-10 11:01:55 AM‬‬

‫‪ITCB.indd 22‬‬


‫המורכבת של פירוט צעדי הבדיקות לכל התסריטים‪ .‬בתהליך המתואר כאן יש למנהל‬ ‫הבדיקות שליטה מדויקת גם בהתקדמות כתיבת תסריטי הבדיקות (ברוב המערכות‬ ‫לניהול בדיקות ניתן להבדיל בין תסריטים ריקים ותסריטים עם צעדי בדיקות)‪.‬‬

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

‫המלצות לכתיבה נכונה של דרישות לבדיקה‬ ‫ותסריטי בדיקות‬

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

‫בעת כתיבת הדרישות לבדיקה‪ ,‬גם אם הן נכתבות ע”י הבודק‪ ,‬יש לכתוב‬ ‫ולהקפיד על מספר כללים‪:‬‬ ‫‪ ‬תיאור ברור ומדויק ככל הניתן של הדרישה‪.‬‬ ‫‪ ‬תיחום גבולות הדרישה לצורך בדיקה מדויקת ושימוש בערכים נכונים‪.‬‬ ‫‪ ‬וידוא יכולת לבדיקת הדרישה או הוספת דרישה ליכולת זו‪.‬‬ ‫‪ ‬אישור הדרישות כפי שנכתבו מול הגורם המפתח ‪ /‬מאשר לפני תחילת‬ ‫התכנון המפורט של הבדיקות‪.‬‬ ‫כאשר ניגשים לכתוב את תסריטי הבדיקות כדאי לזכור מספר כללים‪:‬‬ ‫‪ ‬כתיבת תיאור הבדיקה כדי להקל על התמצאות בעץ הבדיקות בהמשך וגם‬ ‫לצורך שימוש חוזר באותו תסריט (אחרי חודשיים‪-‬שלושה של בדיקות אפילו‬ ‫הבודק שכתב את התסריט אינו זוכר את מהות הבדיקה על פי שם התסריט)‪.‬‬ ‫‪ ‬חלוקת תסריטי הבדיקות לתסריטים בעלי ‪ 5-10‬צעדי בדיקה לכל היותר‬ ‫(ברור שיש מקרים יוצאים מן הכלל‪ )..‬כדי לאפשר יכולת ניהול טובה יותר‬ ‫לריצות התסריטים בהמשך‪.‬‬ ‫‪ ‬רצוי שתסריט בדיקות יהיה ממוקד במטרה ספיציפית וברורה כגון אימות‬ ‫ספציפי של פונקציה או דרישת מערכת‪.‬‬ ‫‪ ‬כדאי לוודא שלכל תסריט יש ‪ 3‬צעדי בדיקה לכל הפחות‪:‬‬ ‫ תנאי מקדים להרצת התסריט כצעד ראשון בתסריט (לחילופין ניתן‬‫להוסיפו לתיאור הכללי של תסריט הבדיקות עצמו)‪.‬‬ ‫ מומלץ לכלול באופן קבוע צעד לניווט עד למיקום תחילת הבדיקה כי לא‬‫תמיד אפשר להעריך מראש מתי נריץ או מי יריץ את אותו התסריט‪.‬‬ ‫ כדאי מאוד שלא נשכח פעולה נבדקת אחת לפחות‪....‬‬‫‪ ‬רצוי לאמץ גישה של כתיבת תסריטי תבנית (תוך שימוש בפרמטרים)‬ ‫עבור פעולות שכיחות (‪ Login‬למערכת לדוגמא) לצורך שימוש חוזר‬ ‫ושילוב בתסריטים אחרים‪.‬‬ ‫‪ ‬רצוי לאמץ שפה אחידה לכתיבת צעדי הבדיקות בתסריטים בלשון ציווי‬ ‫(לחץ על‪ ...‬הקלד את‪ ...‬וכו’ וכו’)‪.‬‬ ‫‪ ‬רצוי להקפיד על כתיבת צעד בדיקה נפרד עבור כל פעולה נבדקת‬ ‫ולהקפיד על רישום תוצאה צפויה לכל צעד בדיקה‪.‬‬ ‫‪ ‬רצוי לקיים אחידות בטרמינולוגיה הקשורה למוצר הנבדק או לארגון עצמו‬ ‫(לדוגמא‪ :‬שרת ‪ /‬מכונה ‪“ /‬ברזל” או שמות מושגים בעברית ‪ /‬אנגלית)‬ ‫‪ ‬כדאי לוודא שתסריט הבדיקות מתאים ליכולות בודקי המערכת והסביבה‬ ‫בה נבדקת המערכת‪.‬‬ ‫‪ ‬יש להקפיד על עקיבות תסריטי הבדיקות ולוודא שתסריט בדיקות יהיה‬ ‫קשור ויכסה דרישה אחת לבדיקה או יותר‪.‬‬

‫תכנון וביצוע ריצות סבבי הבדיקות מתוך תוכנית הבדיקות‬

‫יש לתכנן את ריצות תסריטי הבדיקות לפי סבבי פיתוח המערכת ותכולת‬ ‫השינויים ולאחר מכן חלוקה למנות הרצה (‪ )Test Sets, Test Labs‬לפי‬ ‫הקשר לוגי כלשהו שמתאים לכל ארגון או מערכת‪ ,‬לדוגמא‪:‬‬ ‫‪ ‬לפי מודולים במערכת‬ ‫‪ ‬לפי סוגי בדיקות‬ ‫‪ ‬לפי חלוקה לבודקים‬ ‫‪ ‬לפי סדר עדיפות‬ ‫‪ ‬לפי שילובים שונים משונים ואחרים‬

‫דקות אלו אמנם עשויות להיות יקרות באותו רגע אבל ללא כל ספק ישתלמו‬ ‫לנו בעתיד הקרוב‪...‬‬

‫ניהול שינויים ותחזוקת תוכנית הבדיקות‬

‫החיים האמיתיים של תוכנית הבדיקות מתחילים למעשה מיד לאחר השלמת‬ ‫הקמתה ו”עלייתה לאויר” לסבב הבדיקות הראשון‪.‬‬ ‫מאותו רגע ואילך תוכנית הבדיקות תשתנה ותותאם למציאות המשתנה של‬ ‫המערכת הנבדקת‪.‬‬ ‫תוכנית בדיקות תשמש תמיד כבסיס לניהול הידע המצטבר על המערכת‬ ‫הנבדקת וכל שינוי והתאמה יתחילו מדרישה מסוימת‪:‬‬ ‫‪ ‬במידה ומדובר בדרישה חדשה למערכת‪ ,‬כדאי לוודא שאין דרישות דומות‬ ‫או מקבילות שניתן אולי להשתמש בתסריט בדיקות קיימים כבסיס או‬ ‫כחלק מבדיקת הדרישה‪.‬‬ ‫‪ ‬במידה ומדובר בשינוי לדרישה קיימת‪ ,‬חובה לוודא שתסריטי הבדיקות‬ ‫הקיימים רלוונטיים ונכונים ולשנות אותם בהתאמה לשינויים וכמובן‬ ‫להוסיף תסריטים חדשים ואולי לגרוע תסריטים מסוימים‪.‬‬ ‫כל הפעולות שהוזכרו דורשות מערכת לניהול בדיקות שתתמוך בניהול‬ ‫גרסאות רוחבי ומותנה בכך שניתן יהיה לחזור לגרסאות קודמות של דרישות‬ ‫ותסריטי הבדיקות‪.‬‬ ‫במידה ולמערכת ניהול הבדיקות אין יכולות ניהול שינויים ניתן לחשוב על‬ ‫פתרונות אחרים (החל משכפולים ועד מעבר למערכת טובה יותר‪.)...‬‬ ‫הכלל החשוב שצריך לזכור ולשמור הוא שהמערכת צריכה להיות רלוונטית בכל‬ ‫רגע נתון וחייבת לשמור על קו שיפור מתמיד‪.‬‬

‫מדידת יעילות ואפקטיביות תוכנית הבדיקות‬

‫מומלץ לבצע מדידות של נתוני מערכת ניהול הבדיקות‪ ,‬להציף את המידע‬ ‫ולהסיק מסקנות‪.‬‬

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

‫לסיכום‬

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

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

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

‫בסיום התהליך‪ ,‬תהיה לנו מערכת בדיקות שתשמש כמערכת ניהול ידע‪,‬‬ ‫שניתן יהיה לשלוף ממנה בהווה ובעתיד את נכסי הבדיקות של הארגון‬ ‫כנדרש ובנוסף ניתן יהיה למנוע כתיבת תסריטים מיותרת ולנהל את השימוש‬ ‫החוזר (‪ )Reuse‬בנכסי הבדיקות הקיימים בארגון בצורה מיטבית‪.‬‬

‫מגזין חושבים בדיקות ׀ ינואר ‪ 2011‬׀ ‪21‬‬ ‫‪27-Dec-10 10:53:19 AM‬‬

‫‪Test_Planing.indd 21‬‬


‫הדרך הארוכה והקצרה‬ ‫לבניית תוכנית‬ ‫בדיקות טובה‬ ‫ומנוהלת‬

‫אסף האוזר‬

‫אסף האוזר עוסק בתחום איכות‬ ‫ובדיקות תוכנה מעל ל‪ 13-‬שנה‪.‬‬ ‫יועץ עצמאי ומרצה לבדיקות תוכנה‪,‬‬ ‫מוכר כמומחה ל‪HP Quality Center-‬‬ ‫ולמתודולוגיות ‪ ,ALM‬בשנים האחרונות‬ ‫משמש כמנהל תשתיות לבדיקות באחד‬ ‫מהמוסדות הפיננסיים הגדולים במדינה‪.‬‬ ‫ניתן ליצור קשר עם אסף באתר‪:‬‬ ‫‪www.qaconsultant.co.il‬‬

‫מי לא מכיר את הפתגם “סוף מעשה במחשבה תחילה”?‬ ‫הפתגם הזה כל כך נכון ורלוונטי כאשר עוסקים בתכנון‪.‬‬ ‫במאמר הזה אתייחס כמובן לתכנון ובניה של תוכנית‬ ‫מנוהלת לבדיקות תוכנה‪.‬‬

‫כל תוכנית בדיקות טובה תתחיל באיסוף וניהול ‪TR‬ים שישמשו כמסגרת‬ ‫לכתיבת תסריטי הבדיקות‪ .‬איסוף ה‪TR‬ים יהווה כלי נהדר לניהול כיסוי המערכת‬ ‫בתסריטי בדיקות ויסייע לניהול כיסוי ריצות הבדיקה למול המערכת הנבדקת‬ ‫(‪.)Test Coverage Analysis‬‬

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

‫במקרה הטוב‪ ,‬נקבל את דרישות המערכת הנבדקת או האיפיון שלה וניתן‬ ‫יהיה להקליד את הדרישות שהתקבלו לתוך מערכת (לדוגמא ‪HP Quality‬‬ ‫‪ )Center‬או לייצא אותן מאופיס לתוך המערכת‪.‬‬

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

‫מהי בכלל תוכנית בדיקות טובה איכותית ומנוהלת?‬

‫כאשר רוצים להשיג מטרות בחיים‪ ,‬כדאי מאוד להגדיר אותן בצורה טובה‬ ‫וברורה מראש‪.‬‬ ‫‪‬‬ ‫‪‬‬

‫‪‬‬ ‫‪‬‬

‫תוכנית בדיקות טובה צריכה “לכסות” את דרישות לקוחות המערכת‬ ‫(‪ )Validation‬וגם חלקים מהאפיון המפורט (‪.)Verification‬‬ ‫בנוסף לאמור‪ ,‬רצוי להרחיב את כיסוי התוכנית לדרישות לבדיקה נוספות‬ ‫הנובעות מהנסיון המצטבר של בודקי המערכת בבדיקות תוכנה בכלל‪ ,‬עם‬ ‫סוג ‪ /‬משפחת המערכת הנבדקת ועם המערכת הנבדקת עצמה‪.‬‬ ‫תוכנית בדיקות טובה תהיה כתובה בצורה יעילה‪ ,‬ברורה וחסכונית‬ ‫(שימוש חוזר)‪.‬‬ ‫יכולת ניהול שינויים והתאמת תוכנית הבדיקות לאורך חיי המערכת הינה‬ ‫פרמטר חשוב ביותר וראוי להתייחסות רצינית‪.‬‬

‫כדי להשיג מטרות אלו נהיה חייבים להשתמש במערכת לניהול בדיקות‬ ‫תוכנה‪.‬‬

‫הקמה וניהול של תוכנית בדיקות‬

‫תנאי מקדים להתחלת הקמת תוכנית בדיקות טובה ומנוהלת הוא הקמת‬ ‫תשתית ראויה ונוחה לניהול שוטף של עבודתם היומית של בודקי המערכת‪.‬‬ ‫קיימות לא מעט מערכות לניהול בדיקות (‪ )Test Management‬בשוק‬ ‫שמספקות את היכולת לניהול הבדיקות למול דרישות המערכת הנבדקת‬ ‫ולמול דרישות נוספות לבדיקה‪ .‬במאמר אשתמש מעט במושגי ‪:ISTQB‬‬ ‫‪ — TR (Test Rule( ‬כללים לבדיקה או למעשה דרישות לבדיקה‪.‬‬ ‫‪ — TC (Test Case( ‬מקרים לבדיקה או למעשה תסריטי הבדיקות‪.‬‬

‫במקרה טוב יותר ובהיעדר מערכת לניהול דרישות‪ ,‬נצליח לשכנע את מנהל המוצר ‪/‬‬ ‫מנתח המערכת לעבור לשימוש במערכת הבדיקות לניהול דרישות המערכת עצמן‪.‬‬ ‫אבל‪ ,‬אם נחזור למציאות‪ ,‬כנראה שנצטרך לבצע בעצמנו פירוק פונקציאנלי‬ ‫(‪ )Functional Breakdown‬של המערכת הנבדקת ובהמשך לנהל את‬ ‫השינויים והתוספות לאורך חיי המערכת הנבדקת‪ ,‬ללא ספק המאמץ הראשוני‬ ‫ישתלם לנו בהמשך‪.‬‬ ‫כאמור בפרק הקודם‪ ,‬מומלץ לשלב ולהוסיף דרישות נוספות לבדיקה הנובעות‬ ‫מהידע והערך המוסף של הבודקים עצמם‪.‬‬ ‫ישנן מערכות לניהול בדיקות (לדוגמא ‪ )HP Quality Center‬אשר מאפשרות‬ ‫כבר היום ניהול התכולות לבדיקה (‪ )Release Management‬ולמעשה‬ ‫מייצרות מבטים וחיתוכים על פי שיוך ל‪ Release-‬זה או אחר‪.‬‬ ‫לאחר שהשלמנו את עץ דרישות המערכת צריך להתחיל לחשוב על ‪TC‬ים‬ ‫ש”יכסו” את דרישות המערכת הנבדקת (‪TR‬ים)‪ .‬את ה‪TC‬ים שלנו נכתוב‬ ‫בשלב ראשון ככותרות (ללא צעדי בדיקה) אבל מומלץ לכתוב להם תיאור קצר‬ ‫(‪ )Description‬המתאר את מהלכם כדי שנוכל לשקפם בצורה יעילה לגורמים‬ ‫נוספים ורלוונטיים בארגון מאחר ובהמשך‪ ,‬כאשר נחזור ונכתוב צעדי בדיקה‬ ‫לא תמיד נזכור את ההקשר לכותרת התסריט‪.‬‬ ‫כאמור‪ ,‬התחלנו למלא את עץ הבדיקות בתסריטים וניתן לבנות את העץ‬ ‫כהעתק של עץ הדרישות אבל בדרך כלל אמליץ לנצל את יכולות המערכות‬ ‫הקיימות בשוק ו”להרויח” מימד נוסף כמו חלוקה לרמות בדיקה‪ ,‬לסוגי בדיקה‬ ‫וכו’‪ ,‬כל זאת בהנחה שיש למערכת ניהול הבדיקות יכולת לקשור (‪)Link‬‬ ‫בין דרישות (‪TR‬ים) לתסריטים (‪TC‬ים) ולנהל את הקשר הזה בצורה חכמה‬ ‫ולמעשה לנהל את הידע לטובת הבודקים‪.‬‬ ‫את תסריטי הבדיקות חשוב לשקף ולאשר מול הגורם המפתח ו‪/‬או המשתמש‬ ‫כדי לקבל פידבק והערות ‪ /‬הארות שיוכלו לשפר את תוכנית הבדיקות לפני‬ ‫תחילת פירוט התסריטים‪.‬‬ ‫בהנחה שסיימנו למלא את עץ הבדיקות בתסריטים‪ ,‬קישרנו את התסריטים לדרישות‪,‬‬ ‫קיבלנו את אישור הגורם המפתח והתייחסנו להערותיו‪ ,‬אפשר להתחיל במשימה‬

‫‪ 20‬׀ מגזין חושבים בדיקות ׀ ינואר ‪2011‬‬

‫‪27-Dec-10 10:53:19 AM‬‬

‫‪Test_Planing.indd 20‬‬


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

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

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

‫מדברי אחד המנהלים על בוגר התוכנית‪“ :‬חשוב לו שהמסמך‬ ‫יהיה מאוד מדויק‪ .‬לא מעביר דברים לא מדויקים‪ .‬קשה לו עם‬ ‫חוסר דיוק‪ .‬אם יש הנחיה שצריך לחבר ‪ 4‬מחשבים ויש לו רק‬ ‫‪ ,2‬אז יכניס הערה שבדק רק עם שניים‪ .‬לא מעביר דברים ולא‬ ‫מעגל פינות‪”.‬‬

‫לאחר קליטת בוגר התוכנית בחברה‪ ,‬מקיימת ‪ AQA‬ליווי שוטף‬ ‫ומתמשך‪ ,‬הן של המנהל והצוות בחברה הקולטת והן של העובד‬ ‫וזאת לצורך וידוא של השתלבות והתנהלות שגרתית וחלקה‪.‬‬ ‫היקף הליווי בחודש‪-‬חודשיים הראשונים הוא כמעט יומיומי‬ ‫ואח”כ יורד לפעם בשבוע‪-‬שבועיים בעיקר לצורך מעקב וכיוונון‪.‬‬ ‫כמובן שהליווי חשוב גם בהמשך במצבים של שינויים בפרויקט‬ ‫‪ /‬בצוות ‪ /‬בצורת העבודה וכו’‪.‬‬

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

‫תוצאות בשטח‬

‫ראשוני הבוגרים החלו להשתשלב בחברות השונות לפני כשנתיים‪.‬‬ ‫מאז נוספו חברות רבות וכיום ניתן למנות ‪ 15‬חברות שפתחו את הדלת‬ ‫וקלטו בוגרים כגון‪HP Mercury ,AT&T ,Rosetta Genomics :‬‬ ‫‪ HP ,Kodak ,Mellanox ,Bynet ,Toptix ,Mediaboost‬ועוד‪.‬‬ ‫בוגרי התוכנית משולבים כחלק מהצוות בחברות השונות וניתן‬ ‫לראות כי בתחום תכנון וביצוע בדיקות חדשות הם מתפקדים כמו‬ ‫שאר אנשי הצוות‪ ,‬ואילו בבדיקות רגרסיה‪ ,‬יכולתיהם היחודיות נותנות‬ ‫להם יתרון והם בד”כ טובים יותר‪ .‬יכולת ההתמדה והמון מוטיבציה‬ ‫מביאות דייקנות ואיכות גבוהה בביצוע‪ .‬הצורך שלהם בהקפדה‬ ‫גורר בדיקות יסודיות לפי מסמך הבדיקות ובכל מקום שנמצאו‬

‫לסיכום‬

‫בכל חברה בה קיימת נכונות לשלב פעילות עסקית עם עשייה‬ ‫חברתית‪ ,‬ניתן לבחון הקצאת תפקידים ומשימות לבודקי תוכנה‬ ‫עם תסמונת אספרגר‪ .‬כך ניתן לאפשר לאדם אחר לתת ביטוי‬ ‫ליכולותיו וכן להבטיח לחברה יציבות תעסוקתית‪.‬‬ ‫ועוד מסר מדברי אחד המנהלים בחברות הקולטות‪“ :‬זה גם‬ ‫עושה משהו בלב”‪.‬‬ ‫לפרטים נוספים ויצירת קשר עם אסתר‪ :‬נייד‪052-6755124 :‬‬ ‫מייל‪ester.zabar@aqa.co.il ,www.aqa.co.il :‬‬

‫מערכת מגזין חושבים בדיקות נרתמת לטובת פרוייקטים המהווים תרומה לקהילה וקשורים לבדיקות תוכנה‪ .‬המגזין ישמח לתת‬ ‫במה לסיפורים אחרים בתחום‪ .‬להעברת סיפורים נוספים‪ ,‬אנא פנו למערכת‪info@thinktesting.co.il :‬‬

‫‪27-Dec-10 10:43:48 AM‬‬

‫אסתר צבר‬ ‫בוגרת הטכניון בהנדסה כימית‬ ‫(‪.)M.Sc.‬‬ ‫‪ 12‬שנות ניסיון בפיתוח תוכנה‬ ‫בתעשייה האווירית‪.‬‬ ‫‪ 11‬שנות ניסיון בניהול בדיקות‬ ‫תוכנה [‪.]ECI & BMC‬‬ ‫חברה ב‪Advisory Board -‬‬ ‫של הארגון הישראלי להסמכת‬ ‫בודקי תוכנה (‪ )ITCB‬מיום‬ ‫הקמתו‪.‬‬ ‫מזה שנתיים וחצי מובילה‬ ‫מיזם להכשרה ושילוב של‬ ‫אנשים עם תסמונת אספרגר‬ ‫בבדיקות תוכנה‪.‬‬

‫‪AQA.indd 19‬‬


‫תרומה לקהילה‬

‫אחרת‬ ‫קצת‬ ‫בודקים‪,‬‬ ‫בעלי תסמונת אספרגר ‪-‬‬ ‫בודקי תוכנה מיוחדים‬

‫“הוא כבר חלק מהצוות”‪“ ,‬אנחנו רואים אותו משתלב במשימות כמו כל אחד אחר”‪“ ,‬מעריכים אותו וסומכים עליו” – אלו דברים‬ ‫שנאמרים על בוגרי ההכשרה בבדיקות תוכנה של ‪ .AQA‬מדובר בתוכנית הכשרה המציעה כלים מקצועיים‪ ,‬חברתיים וידע רב‬ ‫המאפשר לבעלי תסמונת אספרגר להשתלב בתחום בדיקות התוכנה תוך שימוש ביכולות הייחודיות להם‪.‬‬ ‫תסמונת אספרגר‬

‫תסמונת אספרגר קרויה על שם ד”ר הנס אספרגר אשר בשנות ה‪ 40-‬זיהה שיש‬ ‫אנשים עם אינטליגנציה גבוהה אך עם קשיים חברתיים מולדים‪ .‬הקשיים באים‬ ‫לידי ביטוי בעיקר בהתייחסות קונקרטית לנאמר אליהם תוך כדי התעלמות‬ ‫מההקשר‪ ,‬מהאינטונציה‪ ,‬מהבעות הפנים ושפת הגוף הנלווים לנאמר‪ .‬לדוגמה‪:‬‬ ‫קושי בהבנת הומור‪ ,‬ציניות וסרקזם‪ .‬הלוקים בתסמונת מתאפיינים בתחומי‬ ‫עניין צרים‪ ,‬העדר קשרים חברתיים‪ ,‬נוקשות וקושי בשינוי שגרה וכן קושי‬ ‫באמפתיה — הבנת נקודת מבט של הצד השני‪.‬‬ ‫כתוצאה מכך‪ ,‬למרות היכולות שלהם‪ ,‬הם מתקשים לעבור ראיונות עבודה‪ ,‬ומי‬ ‫שמצליח בכל זאת להתקבל — חווה קושי בהשתלבות החברתית ובשמירה על‬ ‫מקום עבודתו‪.‬‬ ‫האתגר החברתי הוא למצוא את הדרך לשלב אנשים אלו במעגל העבודה‬ ‫ולתת ביטוי ליכולותיהם‪.‬‬

‫החיבור בין אספרגר לבדיקות תוכנה‬

‫טורקיל סונה‪ ,‬איש ‪ IT‬ואב לבן עם אספרגר‪ ,‬זיהה בבנו תכונות מיוחדות שיכולות‬ ‫לתת יתרון בבדיקות תוכנה‪ .‬תשומת לב לפרטים‪ ,‬דייקנות‪ ,‬קפדנות‪ ,‬חיבור חזק‬ ‫למערכות שיש בהן לוגיקה וחוקים ברורים מאפיינים אנשים עם אספרגר‪ .‬כמו‬ ‫כן‪ ,‬מאפיין אותם צורך בחזרתיות ויכולות קוגניטיביות גבוהות‪ .‬תכונות אלו יכולות‬ ‫להתאים לביצוע בדיקות תוכנה‪ ,‬בעיקר בתחומים של בדיקות רגרסיה‪ ,‬בדיקות‬ ‫נתונים ומשימות שמחייבות דייקנות רבה‪ ,‬תשומת לב לפרטים וחזרתיות‪.‬‬ ‫על בסיס המסקנה הזו‪ ,‬הקים טורקיל ב‪ 2004 -‬את ארגון ספשיאלסטרן‪,‬‬ ‫שמשמעות שמה בדנית‪ :‬אנשים מיוחדים עם יכולת מיוחדת‪ .‬ארגון זה‬ ‫מכשיר ומשלב אנשים עם אספרגר בתעשיית בדיקות התוכנה הדנית‪ .‬כיום‬ ‫כבר משולבים כמה עשרות בוגרים בחברות הייטק בדנמרק‪ ,‬כולל‪ :‬אורקל‪,‬‬ ‫מיקרוסופט וכו’‪.‬‬

‫הקמת ‪AQA‬‬

‫ב”יורוסטאר” ‪ 2006‬הציג טורקיל את הפעילות שלו‪ .‬אסתר צבר‪ ,‬אז מנהלת ‪QA‬‬ ‫ב‪ ,BMC-‬שמעה והתלהבה‪ .‬היא ראתה בנושא הזה הזדמנות למנף את הידע‬ ‫והניסיון המקצועי שצברה בתחום בדיקות תוכנה‪ ,‬בפעילות שיש בה אמירה‬ ‫חברתית מובהקת‪.‬‬ ‫לאחר יצירת קשר עם החברה הדנית ספשיאלסטרן‪ ,‬היא הוזמנה לבקר‬ ‫בדנמרק‪ .‬במהלך הביקור נידונו חשיבות מימוש הפוטנציאל‪ ,‬הענקת ערך עצמי‬ ‫ויכולת לפרנסה הולמת עבור אנשים עם תסמונת אספרגר‪ .‬לאחר בדיקת‬ ‫כשירותה להקים פעילות דומה בישראל‪ ,‬ווידוא שערכים חברתיים אלו מרכזיים‬ ‫גם עבורה‪ ,‬היא קיבלה ליווי שוטף וסיוע מקצועי מהארגון‪.‬‬ ‫במאי ‪ 2008‬הקימה אסתר את (‪ AQA (Asperger doing QA‬מתוך מטרה‬ ‫להתאים אותו למאפייני תחום בדיקות התוכנה בישראל‪ .‬הלוגו של ‪ AQA‬מציג‬

‫דמות שזוקפת את ראשה ואת קומתה עקב ההזדמנות שניתנת לה להיות חלק‬ ‫מהרקמה החברתית‪.‬‬

‫איתור המועמדים‬

‫איתור המועמדים עבור התוכנית נעשה דרך אלו”ט‪ ,‬אפ”י (עמותת הורים‬ ‫שלילדיהם יש אספרגר) ואס”י (קהילת אנשי הספקטרום האוטיסטי בישראל —‬ ‫בוגרים שנמצאים בספקטרום האוטיסטי)‪ .‬כמו כן‪ ,‬ע”י הצגת הנושא בכנסים‬ ‫מקצועיים ורפואיים‪.‬‬ ‫בנוסף‪ ,‬גם הביטוח הלאומי הכיר בתוכנית ומפנה אליה מועמדים למטרת‬ ‫שיקום מ��צועי‪.‬‬

‫תהליך ההכשרה‬

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

‫ההכשרה מתבצעת בקבוצה קטנה של ‪ 4-6‬משתתפים ואורכת כחודשיים‬ ‫וחצי‪ .‬ההכשרה מתבססת על למידת עקרונות מקצוע בדיקות התוכנה לפי‬ ‫סילבוס ‪ .ISTQB‬בהמשך‪ ,‬עבודה מעשית הכוללת תרגול כתיבת בדיקות‪,‬‬ ‫הרצתן ודיווח התקלות‪ ,‬נעשית באמצעות שימוש בתוכנת ניהול בדיקות של‬ ‫חברת ‪ .PractiTest‬כתיבת הבדיקות והרצתן נעשית מתוך הגרסה הקיימת‬ ‫מול גרסאות חדשות של המוצר‪.‬‬ ‫פן חשוב של ההכשרה עוסק בעבודה על הכישורים החברתיים הנדרשים‬ ‫להשתלבות בעבודה בחברות הייטק‪ .‬פן זה משלב הן כללי התנהגות ולבוש‪ ,‬והן‬ ‫כללי עבודה בכלי אופיס כגון‪ :‬כתיבת מייל‪ ,‬הכנת מסמך וכו’‪.‬‬ ‫חשוב לציין שתהליך ההכשרה הינו מסנן‪ ,‬כך שרק אלו העומדים בבחינות‬ ‫ובעבודה המעשית בהצלחה‪ ,‬ישולבו בעבודה‪.‬‬

‫ההכנה והשילוב בעבודה‬

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

‫‪ 18‬׀ מגזין חושבים בדיקות ׀ ינואר ‪2011‬‬

‫‪27-Dec-10 10:43:44 AM‬‬

‫‪AQA.indd 18‬‬


‫מעניינים באמצעותה‪ .‬למשל לשנות מראה של מערכת‪ ,‬לגנוב פרטים‬ ‫רגישים של משתמש ולבצע פעולות רגישות בשמו‪ .‬במקרה האחרון‪ ,‬ניתן‬ ‫לחשוב על סיטואציה בה משתמש אחד משאיר סקריפט זדוני בפורום‬ ‫המבצע הפקדה של כסף בחשבון שלו דרך מספר חשבון של משתמש‬ ‫אחר‪ .‬כל פעם שמשתמש זה יבקר בפורום יופעל הסקריפט על הדפדפן‬ ‫שלו ויגרום לכך שהכסף יופקד בחשבונו של התוקף‪ .‬כמובן שניתן לבצע עוד‬ ‫המון דברים מעניינים באמצעות ‪ .XSS‬אם מעניין אתכם מה ניתן לעשות‬ ‫באמצעות מתקפה זו ומהן הדרכים הנוספות בהן ניתן לממש את המתקפה‪,‬‬ ‫אני ממליץ לגשת למקורות המידע הרבים הקיימים באינטרנט‪ ,‬חפשו ‪XSS‬‬ ‫ב‪ ”Google“ -‬תתפלאו כמה תשובות תמצאו‪.‬‬ ‫‪SQL INJECTION‬‬ ‫מתקפה זו נפוצה מאד ואכזרית‪ .‬היא מאפשרת לתוקף לשנות מבנה שאילתות‬ ‫הנשלחות אל בסיס המידע‪ .‬תוקף עלול לנצל מתקפה זו על מנת לבצע פעולות‬ ‫שונות ומגוונות כגון — חשיפת כל המידע הקיים בבסיס המידע‪ ,‬מחיקה של‬ ‫נתונים‪ ,‬הרצת פקודות על השרת ועוד‪.‬‬ ‫בדוגמה הבאה אציג כיצד ניתן לבדוק האם המערכת חשופה למתקפת ‪SQL‬‬ ‫‪ .INJECTION‬באמצעותה ננסה לעבור את מסך זיהוי המשתמש ללא ידיעת‬ ‫פרטי הזהות של משתמש במערכת‪.‬‬

‫כל מה שצריך לבצע על מנת לדעת האם ניתן לבצע גישה לדפים הדורשים‬ ‫הזדהות ללא הזדהות זה את הצעדים הבאים‪:‬‬ ‫‪ .1‬גישה למערכת עם פרטי הזדהות תקינים‪.‬‬ ‫‪ .2‬גלישה במערכת והעתקת הקישורים משורת‬ ‫הכתובות בכל דף פנימי הנמצא במערכת‪.‬‬ ‫‪ .3‬ביצוע יציאה מסודרת מהמערכת (אם קיים‬ ‫לחצן יציאה‪ ,‬אם לא ע”י סגירת הדפדפן)‪.‬‬ ‫‪ .4‬פתיחת דפדפן חדש וביצוע ניסיון גישה ישירה‬ ‫לכתובות אותן אספנו משלב קודם ללא הזנת‬ ‫נתוני הזדהות במסך הכניסה‪.‬‬ ‫בדיקה נוספת בנושא הרשאות‪:‬‬ ‫‪ .1‬ביצוע צעדים ‪ 3–1‬עם שני משתמשים שונים‬ ‫בעלי הרשאות שונות‪ ,‬למשל משתמש רגיל‬ ‫ומשתמש מנהל‪.‬‬ ‫‪ .2‬ביצוע צעד ‪ 4‬עם משתמש רגיל וניסיון לבצע‬ ‫גישה לדפים של מנהל המערכת‪.‬‬ ‫‪SQL‬‬ ‫‪INJECTION‬‬

‫בשלב ראשון ארצה לבדוק האם המערכת פגיעה למתקפה‪ ,‬והדרך הכי‬ ‫פשוטה היא לנסות להזין תו בשפת ‪ SQL‬לתוך שדות קלט‪ ,‬ולראות מה תהיה‬ ‫תגובתה של המערכת‪.‬‬ ‫התו המועדף עלי לבדיקה זאת הוא גרש ' או הערה ‪. --‬‬ ‫במסך הכניסה של מערכת ‪ ,HacmeBank‬אזין בשדה של שם המשתמש גרש‬ ‫במקום להזין שם משתמש וסיסמה חוקים‪ ,‬וכתוצאה מפעולה זו יופיע המסך‬ ‫המעניין הבא‪:‬‬ ‫התוצאה היא הודעת שגיאה שהחזיר בסיס המידע למערכת בגלל שחוקיות‬ ‫שפת ה ‪ SQL‬הופרה‪ ,‬בגלל הזרקת התו ‘ במקום לא מתאים‪ .‬הודעת שגיאה‬ ‫זו חושפת מידע רב על מבנה השאילתה ומאפשרת לתוקף לגשת לצעד‬ ‫הבא‪:‬‬ ‫סביר להניח שהשאילתה אותה מפעילה המערכת לצורך בדיקת אימות המשתמש‬ ‫בבסיס המידע כתובה בצורה הבאה‪:‬‬ ‫'" ‪SELECT * FROM FSB_USERS WHERE USER_ID = '" + userName +‬‬ ‫";'" ‪AND PASSWORD = '" + password +‬‬ ‫במקום סיסמה אזין את הקלט ‪' OR 1=1--‬‬ ‫התוצאה היא כניסה אל המערכת בשם המשתמש הראשון כפי שהוא מופיע‬ ‫בבסיס הנתונים‪ ,‬כלומר הצלחנו לעקוף את מנגנון ההזדהות ע”י מתקפת ‪SQL‬‬ ‫‪.INJECTION‬‬ ‫הסיבה להצלחת המתקפה היא בעקבות הזרקת הקלט הזדוני שהצליח לשנות‬ ‫את משפט ה ‪ SQL‬הנשלח לבסיסי המידע לתצורה הבאה‪:‬‬ ‫‪SELECT * FROM FSB_USERS WHERE USER_ID ='' OR 1=1-‬‬‫כלומר ע”י הוספת הגרש שברנו את המשפט ונכנסנו באמצע‪ ,‬הזנו תנאי‬ ‫שתמיד מתקיים ‪ , 1=1‬וסגרנו עם – שבשפת ‪ SQL‬משמש כסימון להערה‪ ,‬מה‬ ‫שגרם לכך שכול החלק השני של השאילתה הפך להערה‪ ,‬ובסיס המידע לא‬ ‫יבצע הרצה שלו‪.‬‬ ‫‪Authentication Bypassing‬‬ ‫בדיקת נושא הזדהות והרשאות הוא משימה מורכבת‪ ,‬עם זאת ישנן מספר‬ ‫בדיקות פשוטות אותן ניתן לבצע ולקבל תחושה האם המערכת מממשת‬ ‫מנגנונים אלו‪.‬‬

‫סיכום‪:‬‬

‫דרכי הבדיקה והמתקפות שהוצגו במאמר זה הינן בסיסיות למדי‪ ,‬עם‬ ‫זאת ניתן לקבל תחושה כי ישנן בדיקות אבטחה אותן בודק ‪ QA‬יכול לבצע‬ ‫בקלות יחסית ולאתר בעיות אבטחה בסיסיות הקיימות במערכות ‪WEB‬‬ ‫לפני שמתבצעות בדיקות נרחבות יותר ע”י מומחי אבטחת מידע‪.‬‬ ‫הדרך הנכונה להפוך למומחה בתחום אבטחת המידע היא ללמוד על‬ ‫המתקפות השונות‪ ,‬לתרגל מימוש שלהן ולימוד שיטות ולימוד שיטות‬ ‫שונות כגון עקיפת מנגנוני בדיקות קלט — ‪ evasion techniques‬כך‬ ‫שיהיה ניתן לבצע בדיקות אבטחה ברמה גבוהה יותר‪.‬‬ ‫חשוב ללמוד ולהתנסות עם הטכנולוגיות השונות‪ ,‬חולשותיהן ודרכי‬ ‫המתקפה בהן‪.‬‬

‫מגזין חושבים בדיקות ׀ ינואר ‪ 2011‬׀ ‪17‬‬


‫בדיקות אבטחת מידע לבודקי תוכנה‬ ‫להלן מספר דרכים פשוטות לבדיקת מתקפות מסוג ‪ XSS1‬ו ‪.XSS2‬‬ ‫‪XSS1‬‬ ‫בדיקת ‪ XSS‬בסיסית יחסית וניתן לבצעה בקלות יחסית‪ .‬כל מה שנדרש‪ ,‬זה‬ ‫לנסות להזין סקריפטים במקורות הקלט (טפסים‪ ,‬שדות וכו’) של דף המערכת‬ ‫אותו אנו בודקים‪.‬‬ ‫הסקריפט הבסיסי ביותר שיכול לתת לנו תשובה מהירה אם המערכת חשופה‬ ‫למתקפה‪ ,‬הינו סקריפט מהסוג‪.>script>alert(‘I am XSS ‘)</script< :‬‬ ‫הזרקת קוד זה לשדות קלט במערכת שחשופה למתקפת ‪ XSS‬תגרום‬ ‫במקרים רבים להקפצת חלון עם ההודעה ‪( I am XSS‬ישנם מקרים בהם‬ ‫יידרש לבצע שינויים שונים בסקריפט על מנת להצליח להזריק אותו ולגרום לו‬ ‫לפעול‪ ,‬על שינויים אלו לא אפרט מפאת מורכבותם‪ ,‬אך אתן טיפ קטן‪ .‬אנא‬ ‫הציצו בדף הבא‪.)http://ha.ckers.org/xss.html :‬‬

‫‪XSS1‬‬

‫לצורך המחשה פשוטה למימוש בדיקה זו‪ ,‬נבצע את הבדיקה על אתר‬ ‫‪http://xss.progphp.com/xss1.html‬‬ ‫כפי שאנו רואים‪ ,‬הדף מכיל שדה קלט אחד ולחצן “‪ ”Submit Query‬המאפשר‬ ‫שליחה של הטופס אל השרת‪ .‬כל מה שצריך על מנת לבדוק את הדף זה להזין‬ ‫בשדה הקלט את הסקריפט‪ >script>alert(‘I am XSS ‘)</script< :‬ללחוץ‬ ‫על הלחצן ולראות מה תהייה התוצאה‪:‬‬ ‫במערכת זו נתוני הטופס נשלחים מצד המשתמש לצד השרת ע”י בקשת‬ ‫‪ ,post‬ולכן היינו צריכים לבצע את הזרקת הסקריפט בפרמטרים של הטופס‪.‬‬ ‫ישנם מקרים בהם נוכל לבצע את אותה הבדיקה על מערכות שמעבירות נתוני‬ ‫קלט ע”י בקשת ‪ ,GET‬ואת הסקריפט הזדוני נצטרך במקרים אלו להזריק‬ ‫בשורת הכתובת עצמה‪ ,‬להלן הדגמה‪:‬‬ ‫_‪http://xss.progphp.com/xssGet.php? my‬‬ ‫>‪value=<script>alert(‘I am XSS ‘)</script‬‬ ‫שליחת בקשה מסוג זה‪ ,‬תגרום להקפצת חלון כפי שהודגם מקודם‪.‬‬ ‫‪XSS2‬‬ ‫השיטה לצורך בדיקת חשיפה למתקפת ‪ XSS‬מסוג שני דומה מאוד לבדיקה‬ ‫הראשונה‪.‬‬ ‫ההבדל היחיד הוא שלעיתים נדרש לבצע מספר פעולות עד שמגלים אם‬ ‫המערכת חשופה‪.‬‬ ‫להלן דוגמה פשוטה‪:‬‬ ‫‪ 1‬הזרקת סקריפט בשדה “הערות” במערכת פורומים‪.‬‬ ‫‪ 2‬ביצוע גישה לאחר מכן להערה שכתבנו‪.‬‬ ‫אדגים באמצעות מערכת ‪HacmeBank‬‬ ‫לאחר ביצוע הזדהות‪ ,‬נבצע גישה לדף ‪Posted Messages‬‬ ‫‪http://localhost/HacmeBank_v2_Website/aspx/main.‬‬ ‫‪aspx?function=PostMessageForm‬‬ ‫בשדה ‪ Subject‬נזין “‪ ”Test Reflected XSS‬ובשדה ‪ MESSGAE‬נזין‬ ‫<‪ .>script>alert(‘I am Reflected XSS ‘)</script‬לאחר מכן נבצע‬ ‫שליחה של הטופס‪ .‬מרגע זה בכול פעם שניכנס לדף ‪Posted Messages‬‬ ‫נהיה חשופים להרצת הסקריפט בדפדפן שלנו‪:‬‬ ‫אומנם הקפצת חלון נחמד עם הודעה לא מרגיש כמו מתקפה מתוחכמת‪,‬‬ ‫אך חשוב להבין שמדובר רק ב ‪ POC‬למתקפה‪ .‬אחרי שתוקף יודע‬ ‫שהמערכת חשופה למתקפות מסוג ‪ XSS‬הוא יכול לעשות הרבה דברים‬ ‫‪ 16‬׀ מגזין חושבים בדיקות ׀ ינואר ‪2011‬‬

‫‪XSS2‬‬


‫חשיבות ביצוע בדיקות אבטחת מידע הינה גבוהה‬ ‫ואף קריטית‪ ,‬לא פחות מחשיבות ביצוע בדיקות‬ ‫שפיות אותן מבצע בודק ה ‪ QA‬של מערכת‪ ,‬בדיקות‬ ‫שאותן מקובל לבצע כבר שנים רבות והינם במרבית‬ ‫המקרים תנאי מקדים לפני הפצת מערכת‪.‬‬

‫‪get data from DB (SQL) or‬‬ ‫‪from local resource‬‬

‫‪get/post URL‬‬ ‫‪and params‬‬

‫‪2‬‬

‫‪1‬‬

‫ניתן לצור קשר עם ירון בכתובת‪:‬‬ ‫‪yaron@qrity.com‬‬

‫‪SQL‬‬ ‫‪Internet‬‬

‫‪DB‬‬

‫‪2.1‬‬

‫‪HTTP‬‬

‫‪Web Application‬‬

‫‪return data from DB‬‬

‫‪Browser‬‬

‫‪3‬‬

‫ירון חקון‬ ‫ירון הינו ארכיטקט אבטחת‬ ‫מידע‪ ,‬ומנהל מחלקת הייעוץ‬ ‫בחברת ‪ Q.rity‬המתמחה‬ ‫במתן שירותי אבטחת מידע‬ ‫מתקדמים‪ .‬כמו כן‪ ,‬מנהל ירון‬ ‫את קבוצת ‪.Net Security‬‬ ‫‪ User Group‬בה מועברות‬ ‫הרצאות רבות בנושאי אבטחת‬ ‫מידע בסביבת ‪ ,Net.‬נושאי‬ ‫‪ hacking‬ונושאים נוספים‬ ‫מתחום אבטחת המידע‪.‬‬

‫‪Web User‬‬

‫‪return HTTP page containing‬‬ ‫‪the data user requested‬‬

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

‫חלק ב’‬

‫להלן המתקפות אותן אסקור במאמר זה ותיאור קצר עבור כל מתקפה‪:‬‬ ‫‪ — (Cross Site Scripting) XSS 1‬הזרקת קוד עוין למערכת דרך ממשקי קלט‬ ‫הקיימים כגון ממשק משתמש‪.‬‬ ‫‪ — SQL Injection 2‬הזרקת קוד בשפת ‪ SQL‬למערכת כך שישפיע על‬ ‫השאילתות המופעלות מהמערכת אל בסיסי המידע‪ ,‬בעצם התערבות בדרך‬ ‫הגישה לבסיסי המידע‪.‬‬ ‫‪ – Authentication bypassing 3‬ביצוע גישה ישירה לפונקציונאליות במערכת‬ ‫תוך עקיפת מנגנוני הזדהות והרשאות של המערכת‪.‬‬ ‫אינני מתכוון לפרט ולהסביר לעומק משמעות של כל מתקפה אותה אני מציג‪,‬‬ ‫עם זאת קיימת חשיבות רבה לנסות ולהבין לעומק את המתקפות על מנת‬ ‫שיהיה ניתן לבצע בדיקה שלהן כאשר מדובר במערכת קצת יותר מורכבת או‬ ‫שונה מהמערכת המוצגת במאמר זה‪ .‬לצורך העמקת הידע לגבי מתקפות אלו‬ ‫מומלץ לקרוא מידע נוסף הקיים באינטרנט‪ ,‬מקום מצוין להתחיל הוא באתר‬

‫‪ OWASP‬המציג פירוט‪ ,‬משמעות ודרכי מימוש והגנה אל מול מתקפות אלו‬ ‫ומתקפות נוספות‪.‬‬

‫‪XSS‬‬ ‫בחרתי להציג מתקפה זאת ראשונה‪ ,‬גם בגלל שהיא מקוטלגת בין המתקפות‬ ‫הנוראיות ביותר מבחינת עולם ה‑ ‪ Web‬וגם בגלל שהיא מאפשרת ביצוע‬ ‫מתקפות נוספות באמצעותה‪.‬‬ ‫למתקפה זו קיימים שלוש תצורות בהן ניתן לממש אותה‪ .‬לכול צורה קיימת‬ ‫השפעה קצת שונה‪ ,‬להלן תיאור קצר של הסוגים‪:‬‬ ‫‪ — Reflected 1‬הזרקת הסקריפט הזדוני מתבצע ע”י שליחת בקשות ‪HTTP‬‬ ‫למערכת‪ ,‬הגורמות למערכת להחזיר את הסקריפט העוין כחלק מהתשובה‬ ‫המוחזרת מהשרת בצורה חד פעמית‪.‬‬ ‫‪ — Persisted 2‬הזרקת הסקריפט הזדוני מתבצעת פעם אחת בצורה כל שהיא‬ ‫(למשל דרך פורום) למערכת‪ .‬לאחר מכן‪ ,‬כאשר משתמש ניגש לדף שנפגע‬ ‫מהמתקפה הוא חשוף להרצה של סקריפט זדוני אצלו בדפדפן‪.‬‬ ‫‪ — DOM Base 3‬מתקפה זו מבוססת על התקפת הסקריפטים הרצים‬ ‫בצד המשתמש (לעומת שני הסוגים הראשונים שמבוססים על עיבוד בצד‬ ‫השרת)‪ ,‬הזרקת סקריפטים ישירות אליהם וביצוע מניפולציה של ה ‪DOM‬‬ ‫(ראה מאמר מצוין בנושא ‪http://www.webappsec.org/projects/‬‬ ‫‪.(articles/071105.shtml‬‬

‫מגזין חושבים בדיקות ׀ ינואר ‪ 2011‬׀ ‪15‬‬


‫בדיקות אבטחת מידע לבודקי תוכנה‬

‫בדיקות‬

‫אבט ת מידע‬ ‫לבודקי תוכנה‬

‫חלק א’‬

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

‫ההבנה הרווחת היום בקרב מנהלי מערכות מידע ומי שאחראי על פריסתן‬ ‫היא שיש להגן על מערכות מידע אלו בדרך שבה לא יתאפשר שימוש העלול‬ ‫להוביל לנזק לארגון או למשתמשי המערכת (כלומר פגיע במערכת מידע‬ ‫עלולה להוביל במקרים רבים לפגיעה בארגון ובנכסיו או בפרטיות המשתמשים‬ ‫במערכת)‪.‬‬ ‫חשיבות ביצוע בדיקות אבטחת מידע הינה גבוהה ואף קריטית‪ ,‬לא פחות‬ ‫מחשיבות ביצוע בדיקות שפיות אותן מבצע בודק ה ‪ QA‬של מערכת‪ ,‬בדיקות‬ ‫שאותן מקובל לבצע כבר שנים רבות והינם במרבית המקרים תנאי מקדים‬ ‫לפני הפצת מערכת‪.‬‬ ‫מאחר וחשיבות בדיקות אבטחה גדלה עם השנים‪ ,‬קיים הצורך להכשיר בודקי‬ ‫‪ QA‬כך שיוכלו לשלב חלק מבדיקות אבטחת המידע עוד בשלב ביצוע ה ‪ QA‬ובכך‬ ‫לחסוך זמן ומשאבים כאשר מחליטים לבצע בדיקות ע”י מומחה אבטחת מידע‪.‬‬ ‫כמובן שלא ניתן לצפות מבודק ‪ QA‬לבצע את אותן הבדיקות שמבצע מומחה‬ ‫אבטחת מידע‪ ,‬מומחיות הדורשת ניסיון רב והכרה של שיטות‪ ,‬מתודולוגיות‬ ‫וטכניקות שונות אותן ניתן לרכוש רק ע”י ניסיון והעמקת ידע בתחום‪ .‬עם זאת‪,‬‬ ‫ישנן מספר בדיקות פשוטות וטריוויאליות אותן כל בודק ‪ QA‬יכול לבצע בקלות‬ ‫יחסית ולשלב בבדיקות ה ‪ QA‬שהוא מבצע במערכת‪ ,‬ועם הזמן אף להרחיב‬ ‫את הידע ולבצע בדיקות אבטחת מידע ברמה גבוהה יותר‪.‬‬ ‫בדיקות אבטחת מידע מתבצעות עלפי מתודולוגיות שונות‪ ,‬מביניהן מקובלת‬ ‫מאוד השיטה ההוליסטית הכוללת ביצוע בדיקות בשלושה רבדים‪ ,‬רשת‪,‬‬ ‫מערכת הפעלה ואפליקציה‪ .‬ע”י ביצוע בדיקות ברבדים אלו ניתן לדעת האם‬ ‫מערכת מידע בטוחה לשימוש לא רק מבחינת בעיות בקוד המערכת‪ ,‬אלה‬ ‫גם מבחינת הצורה בה המערכת הוטמעה בסביבת הרשת וכן סביבת מערכת‬ ‫ההפעלה בה הותקנה (במידה ונדרש)‪.‬‬ ‫במאמר זה אתמקד במספר דרכים בהן ניתן לבצע בדיקות אבטחת מידע פשוטות‬ ‫ברמה האפליקטיבית‪ ,‬לממשקי משתמשים ושירותים המפותחים בטכנולוגיית‬ ‫‪ ,WEB‬בהתאם לקטגוריית בדיקות כפי שהן מקוטלגות ע”י ארגון ‪OWASP‬‬ ‫_‪(http://www.owasp.org/index.php/Category:OWASP_Top_Ten‬‬ ‫‪ ) Project‬העולמי בפרויקט בשם ‪( TOP 10‬רק עבור חלק מהמתקפות אותן‬ ‫סוקר הפרויקט)‪.‬‬ ‫‪ 14‬׀ מגזין חושבים בדיקות ׀ ינואר ‪2011‬‬

‫מאת ירון חקון‬

‫לצורך תרגול המתקפות במאמר זה‪ ,‬ביצעתי שימוש במספר כלים חינמיים‬ ‫באמצעותן ניתן לתרגל בעיות אבטחה באפליקציות כולל‪:‬‬ ‫‪ ‬אתר ‪ online‬לבדיקת ‪http://xss.progphp.com XSS‬‬ ‫‪ ‬התקנה של אתר ‑ ‪ HacmeBank‬המאפשר תרגול מתקפות ‪ ,WEB‬ניתן‬ ‫להוריד התקנה של האתר מהכתובת הבאה‪http://www.foundstone. :‬‬ ‫‪com/us/resources/termsofuse.asp?file=hacmebank2_install.‬‬ ‫‪ zip‬באמצעות מערכת זו תוכלו לבצע תרגול נוסף מעבר למופיע במאמר זה‪.‬‬ ‫בנוסף‪ ,‬יכול בודק ‪ QA‬לבצע הרצה של כלי בדיקה אוטומאטיים חינמיים‬ ‫שיכולים לחשוף לא מעט בעיות אבטחה במערכות מבוססות טכנולוגיית‬ ‫‪ ,WEB‬להלן קישור לעמוד בו ניתן למצוא מספר כלים למטרה זו‬ ‫‪http://www.webresourcesdepot.com/10-free-web-application‬‬‫‪( security-testing-tool‬במאמר זה לא אראה שימוש בכלי סריקה)‪ .‬חשוב‬ ‫להבין שהרצת כלים אלו אינם מחליפים בדיקות ידניות של בודק אבטחה‬ ‫מוסמך‪.‬‬ ‫תחילה‪ ,‬רקע קצר על אפליקציות ‪.WEB‬‬

‫תיאור הסרטוט‪:‬‬

‫מערכות המתבססות על טכנולוגיית ה ‪ WEB‬בנויות כך‪ ,‬שמשתמש המעוניין‬ ‫לקבל אינפורמציה משירות שולח בקשה על גבי פרוטוקול ‪( HTTP‬שלב ‪)1‬‬ ‫לכיוון השרת‪ .‬השרת מבצע עיבוד של הבקשה‪ ,‬ובמקרים רבים יבצע גם פעולות‬ ‫נוספות כגון גישה לבסיסי מידע (שלב ‪ )2‬בדרך כלל ע”י הפעלת שאילתות ‪SQL‬‬ ‫(או בדרך אחרת כגון ‪ stored procedures ,LINQ‬וכו’) ויקבל בחזרה נתונים‬ ‫מבסיסי המידע (שלב ‪ .)2.1‬בנוסף‪ ,‬יכולה המערכת לבצע גישה למשאבים‬ ‫מקומיים כגון מערכת הקבצים לצורך קריאת קובץ‪ .‬לבסוף‪ ,‬המערכת תאסוף‬ ‫את הנתונים‪ ,‬תכין אותם בתצורת ‪ HTML‬ותחזיר לצד המשתמש (שלב ‪)3‬‬ ‫לצורך הצגה בדפדפן של תוצאות הבקשה‪.‬‬ ‫אחת החולשות הנפוצות‪ ,‬אותן מנצל תוקף לצורך פריצה למערכות מידע‬ ‫קשורה לקלט המועבר מצד המשתמש אל צד המערכת‪ .‬הכלל החשוב‬ ‫ביותר מבחינת מפתח המערכת הוא לבצע בדיקות אימות קלט לפני שהוא‬ ‫מבצע שימוש כל שהוא בקלט אותו הוא מקבל מצד המשתמש‪ ,‬על מנת לא‬ ‫להיות חשוף למתקפות הקלט ‑ ‪ injection attack‬אותן הציג בחלק שני של‬ ‫המאמר‪.‬‬ ‫תוקפים רבים מבצעים שימוש בכלי ‪ PROXY‬כדי שיהווה חוצץ בין צד המשתמש‬ ‫לצד השרת‪ ,‬בגלל שכתוקף‪ ,‬נרצה להביט על המידע הזורם בין צדדים אלו‪.‬‬ ‫אנו לא רוצים להיות מוגבלים למידע הנחשף רק ע”י ממשק המשתמש או‬


‫אני ממליץ לבודק תוכנה מתחיל ללכת לעבוד במקומות‬ ‫בהם יוכל ללמוד שיטות עבודה מסודרות‪ .‬ללמוד קודם את‬ ‫ה"מקצוע" מלמטה ובצורה הנכונה‪ .‬מקומות בהם ניתן‬ ‫ללמוד את העבודה לפי הספר‪.‬‬ ‫נהלי עבודה אחידים‪ .‬בנוסף‪ ,‬הסבנו ‪ DB‬קיימים ל‪ DB -‬אחיד ב‪Quality -‬‬ ‫‪ .Center‬מהלך זה מאפשר יעילות גבוהה בעת מעבר של כח אדם ממקום‬ ‫למקום וכן מספק נתונים כמותיים המאפשרים להשוות בין פרויקטים‪ ,‬צוותי‬ ‫בדיקות ומשימות‪ .‬כך ניתן לעלות על נקודות תורפה בקלות‪.‬‬

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

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

‫‪ .11‬מאיפה אתה לומד על חידושים בתחום הבדיקות?‬ ‫קורא חומרים מקצועיים?‬

‫‪ .9‬אילו תכונות אתה מחפש כשאתה מראיין בודק תוכנה?‬

‫‪ .10‬מה היית ממליץ לבודק תוכנה שנמצא בתחילת‬ ‫הקריירה שלו?‬ ‫אני ממליץ לבודק תוכנה מתחיל ללכת לעבוד במקומות בהם יוכל ללמוד‬

‫פגישות ושיחות עם עמיתים למקצוע‪ .‬שוטטות באינטרנט‪ .‬קורסים‬ ‫והשתלמויות מקצועיות‪.‬‬

‫‪ .12‬אם לא הייתי בודק תוכנה היום‪ ,‬באיזה תחום היית?‬ ‫לאורך הקרירה בחרתי להתעסק בדברים שהיו לי מעניינים‪ .‬עברתי בין מספר‬ ‫תחומים‪ ,‬ביניהם רכש תוכנה וחומרה‪ ,‬מתודולוגיות‪ ,‬הדרכה‪ ,‬ניהול פרויקטים‬ ‫בהיקפים גדולים מאוד וכו'‪ .‬אני עובר בין תחומים לפי העניין והאתגר‪ .‬אני מאמין‬ ‫שאם לא הייתי מגיע לתחום הבדיקות‪ ,‬הייתי ממשיך לעסוק בתחום הפיתוח‪.‬‬

‫רוצה חשיפה לקהל הבדיקות‬ ‫המקצועי והרחב ביותר?‬

‫מודעת הפרסום שלך‬

‫יכולה להיות‬ ‫כאן‬

‫‪23-Dec-10 11:30:25 AM‬‬

‫מגזין‬

‫לפרטים‪info@thinktesting.co.il :‬‬

‫חושבים‬

‫בדיקות‬ ‫‪Interview.indd 13‬‬


‫פרופיל אישי‬

‫ראיון עם מנהל‬ ‫בדיקות‬ ‫אביעד‬ ‫בן יצחק‬

‫שם‪ :‬אביעד בן יצחק‬ ‫מצב משפחתי‪ :‬נשוי ‪3 +‬‬ ‫מגורים‪ :‬מודיעין‬ ‫תפקיד‪ :‬מנהל תחום‬ ‫הבדיקות בבנק לאומי‬ ‫קרירה‪ 24 :‬שנים בצה"ל‬ ‫(סגן אלוף) במגוון תפקידים‬ ‫באגף התקשוב ‪/‬חייל הקשר‪.‬‬ ‫תפקיד אחרון בחיל‪ :‬מפקד‬ ‫בית הספר למחשבים‪6.5 .‬‬ ‫שנים בבנק לאומי‪ 3 .‬שנים‬ ‫אחרונות בתפקיד מנהל‬ ‫תחום הבדיקות‪.‬‬ ‫השכלה‪ :‬תואר ראשון‬ ‫בכלכלה ומדע המדינה‪ .‬תואר‬ ‫שני במנהל עסקים‪.‬‬

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

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

‫האני מאמין שלי – ארגוני בדיקות כארגוני‬ ‫איכות צריכים לתפקד ברמה הגבוהה‬ ‫ביותר‪ .‬עניין של דוגמא אישית‬ ‫שייספק שירותי בדיקות לאגפים השונים‪ .‬הצעה זו‬ ‫והאתגר הטמון בה הכניסו אותי לתחום הבדיקות‪.‬‬ ‫תוך שנה וחצי ריכזנו את כל הבודקים תחת גוף אחד‬ ‫שפועל בהתאם למתודולוגיה אחידה ועל בסיס תשתית‬ ‫‪ Quality Center‬אחידה‪ .‬מבנה זה מאפשר ויסות וניוד‬ ‫עובדים תוך התרכזות במערכות העיקריות‪ .‬הוכחנו‬ ‫שניתן להפיק יותר מכוח האדם הקיים ואף לשפר באופן‬ ‫ניכר את איכות העבודה‪.‬‬

‫‪ .2‬אילו נושאים נוספים בארגון תחת‬ ‫אחריותך?‬ ‫בנוסף לניהול תחום הבדיקות אני אחראי על עוד שני‬ ‫נושאים‪ .‬אני מנהל את המהדורה הסניפית – חבילת‬ ‫תוכנות הבנק המותקנות בסניפים‪ .‬במסגרת זו אני‬ ‫מסנכרן את כל גורמי הפיתוח ומאשר כל גרסה לפני‬ ‫שהיא מועברת לסניפי הבנק‪.‬‬ ‫בנוסף‪ ,‬אני עוסק בהקמת גוף לטיוב נתונים אשר מטרתו‬ ‫לשפר את איכות מאגרי המידע לסוגיהם ‪.‬‬

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

‫‪ .5‬מה דעתך על תחום הבדיקות בארץ?‬ ‫אני מוטרד מעודף התחרות בשוק הבדיקות בישראל‪.‬‬ ‫התחום הזה לא מאוד גדול‪ .‬הרצון להוריד עלויות מצד‬ ‫המתחרים על הלקוחות ומצד הלקוחות עצמם – יוביל‬ ‫להפסד של כל המעורבים‪ .‬הלקוחות יקבלו בודקים פחות‬ ‫טובים ואילו החברות יפסידו בגלל קצב תחלופה גדולה‬ ‫של בודקים‪ .‬אני אישית מוכן שחברות הבדיקות ירויחו‬ ‫קצת יותר כדי שאוכל לקבל אנשים טובים ומרוצים יותר‪.‬‬

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

‫‪ .7‬איך לדעתך יראה תחום הבדיקות בעוד‬ ‫‪ 5-10‬שנים? במה הוא יהיה שונה מהיום?‬ ‫אני מאמין שבעתיד יפותחו מגוון פתרונות טכנולוגיים אשר‬ ‫יצמצמו את עבודת ההרצה הסיזיפית של הבודקים‪ .‬פתרונות‬ ‫אלו יביאו להקטנת הזמן המושקע כיום בהרצת בדיקות‪ .‬בכל‬ ‫מקרה לא יהיה תחליף לתכנון התסריטים על ידי הבודק‪.‬‬

‫‪ .8‬האם יש שיטות בדיקה‪ ,‬מתודולוגיות‪,‬‬ ‫רעיונות מקוריים או טיפים בתחום הבדיקות‬ ‫עליהם היית ממליץ?‬ ‫בתקופה האחרונה סיימנו מהלך של בניית תבנית בדיקות‬ ‫אחידה לכל הפרויקטים ב‪ Quality Center-‬כולל פיתוח‬

‫‪ 12‬׀ מגזין חושבים בדיקות ׀ ינואר ‪2011‬‬

‫‪23-Dec-10 11:30:18 AM‬‬

‫‪Interview.indd 12‬‬


‫רשמים מכנס ‪ STP‬בלאס וגאס איל זילברמן‬ ‫רק עבור תקלות אשר זמן תיקונן ארוך יותר (לדוגמא תקלה שתיקונה דורש‬ ‫מעל שעתיים עבודה)‪ .‬עוד חשוב לציין כי חלק גדול מהתקלות שנמצאות‬ ‫מתוקנות ע”י אנשי הבדיקות עצמם‪ ,‬שכן להם ידע רב יותר בקוד המערכת‬ ‫מבודקים רגילים‪.‬‬

‫‪Kick Ass Test Design Techniques from‬‬ ‫)‪Combinatorial Testing (Justin Hunter‬‬

‫ההרצאה התמקדה בשיטות לבחירת מקרי בדיקה‪ .‬ברוב המערכות‬ ‫הקיימות כיום בשוק יש רצף אינסופי של מצבים ואפשרויות‪ ,‬כאשר אין‬ ‫יכולת לצוות הבדיקות לכסות את כל מקרי הבדיקה האפשריים‪ .‬לפיכך‬ ‫נוצרו שיטות מתקדמות כגון שיטת ה‪( Pair wise-‬ידועה גם כשיטת ‪All‬‬ ‫‪ )pairs‬הגישה מצמצמת כמות גדולה של מצבים תוך לקיחת הנחת בסיס‬ ‫כי באמצעות בדיקת כל המצבים של כל צמד פרמטרים ניתן להגיע לכיסוי‬ ‫של ‪ 85%‬מהמקרים בהם יתגלו תקלות במערכת‪ .‬לדוגמא‪ :‬אם ניקח מערכת‬ ‫בסביבת ‪ Web‬המסוגלת לעבוד על ‪ 8‬מערכות הפעלה‪ 6 ,‬סוגי דפדפנים ו‪3-‬‬ ‫סוגי ‪ .Anti-Virus‬כמות הבדיקות של כל המצבים האפשריים היא עצומה‪.‬‬ ‫בשיטת ה‪ Pair Wise-‬נבדוק כל ‪ 2‬קונפגורציות אפשריות ובכך נצמצם‬ ‫אפשרויות בצורה משמעותית‪.‬‬ ‫כל איטרציה מתחילה בפגישת תכנית איטרציה (‪IPM – Iteration Planning‬‬ ‫‪ .)Meeting‬בפגישה נסקרת האיטרציה האחרונה (בין השאר דנים בתוצאות‬ ‫בדיקות הקבלה ומסיקים מסקנות) ודנים בסיפורים (‪ )Stories‬לאיטרציה הבאה‪.‬‬

‫להרחבה בנושא זה‪ ,‬ראה את מאמרו של טלמון בן כנען במגזין הנוכחי‪.‬‬

‫‪Test Language – Introduction to Keyword‬‬ ‫)‪Driven Testing (Ayal Zylberman‬‬

‫במהלך האיטרציה‪ ,‬כל הצוותים עובדים במקביל‪ .‬לדוגמא‪ :‬הפיתוח מבוצע קצת מוזר לסכם הרצאה שלי‪ ,‬אבל אני אנסה‪ .‬בהרצאה דיברתי על הסיבות‬ ‫העיקריות לכשלון של בדיקות אוטומטיות וחילקתי את הסיבות ל‪ 3-‬קטגוריות‪:‬‬ ‫במקביל לבדיקות ולכתיבת האפיונים‪.‬‬ ‫תהליך (חברות אשר לא משנות את תהליך‬ ‫העבודה על מנת להתאים אותו לעובדה שחלק‬ ‫משימות הבדיקות הן‪:‬‬ ‫יקות לג’רי ויינברג‪.‬‬ ‫מהבדיקות רצות בצורה אוטומטית)‪ ,‬ארגוניות‬ ‫הגדרת קריטריון מעבר (‪Acceptance‬‬ ‫רומה לענף הבד‬ ‫הכנס ניתן אות ת‬ ‫הבדיקות בעולם‪.‬‬ ‫במהלך‬ ‫(בעיקר תקשורת לקויה בין אנשי האוטומציה‬ ‫‪ :)Criteria‬מבוצע בדר”כ ע”י הלקוח בסיוע‬ ‫הבולטים בתחום‬ ‫אחד מהאישים‬ ‫את אבני היסוד‬ ‫ג’רי הינו‬ ‫לבודקים ידניים) ובעיות טכניות (הכלי האוטומטי‬ ‫הבדיקות והפיתוח‪ .‬נועד לייצר שקיפות ולתאם‬ ‫אשר חלקם יצקו‬ ‫סם מספר ספרים‬ ‫היום‪ .‬בין ספריו‬ ‫הוא פר‬ ‫לא מזהה אובייקטים‪ ,‬נפילות של הרצת‬ ‫ציפיות‪ .‬חשוב להשתמש בשפה של הלקוח‬ ‫אנו מכירים אותו‬ ‫ש‬ ‫לם הבדיקות כפי‬ ‫‪Secrets of Co‬‬ ‫של עו‬ ‫אוטומטיה עקב בעיות בסקריפטים וכו’)‪.‬‬ ‫לצורך הגדרת הקריטריון‪.‬‬ ‫‪nsulting, Qua‬‬ ‫‪lity Software‬‬ ‫‪Management,‬‬ ‫הבולטים‪:‬‬ ‫‪Perfect Softwar‬‬ ‫‪e: And Other Ill‬‬ ‫את הגליון הראשון‬ ‫‪usions‬‬ ‫לאחר מכן הצגתי את תפיסת ה‪Test-‬‬ ‫‪ – Test Driven Development‬גישה האומרת‬ ‫שהצגתי בפני ג’רי‬ ‫‪ about Te‬ועוד‪ .‬כ‬ ‫וא כל מילה ברגע‬ ‫‪sting‬‬ ‫‪ .Language‬העיקרון הבסיסי של התפיסה‬ ‫שעבור כל חלק תוכנה שנכתב נכתבת תכנית‬ ‫רגש והבטיח לקר‬ ‫זין הוא ממש הת‬ ‫של המג‬ ‫לבדיקת אותו קוד‪ .‬ברוב המקרים‪ ,‬תכנית הבדיקה‬ ‫הוא שהאחריות על תכנון בדיקות אוטומטיות‬ ‫די העברית שלו‪...‬‬ ‫וא יסיים את לימו‬ ‫נכתבת לפני כתיבת הקוד עצמו‪ .‬בדר”כ מבוצע ע”י‬ ‫והרצתן מבוצע ע”י הבודקים הידניים במקום‬ ‫שה‬ ‫המפתחים בסיוע של הבודקים‪ .‬הבדיקות נכתבות‬ ‫אנשי האוטומציה‪.‬‬ ‫בשפה שבה נכתב קוד המערכת ומורץ עם כל‬ ‫קומפילציה ועם כל ‪.Build‬‬ ‫תפקידם של אנשי האוטומציה הופך להיות מ”תרגום” מפרטי בדיקות‬ ‫לסקריפטים להכנת תשתית בדיקות אשר עליה מפתחים אנשי הבדיקות‬ ‫בדיקות קבלה אוטומטיות – מבוצע על מנת לוודא כי עמדנו בציפיות הלקוח הידניות תסריטי בדיקות באמצעות שימוש במילות מפתח אשר הוגדרו מראש‬ ‫וכן כי המערכת ממשיכה לתפקד עם התקדמות הפיתוח‪ .‬מטרה נוספת יכולה (‪ .)Keywords‬היתרון העיקרי של הגישה הוא החיסכון בעבודה כפולה של‬ ‫להיות סיוע באפיון דרישות המערכת‪ .‬מבוצע ע”י הלקוח בסיוע ה‪ .QA-‬כלים כתיבת מסמכי הבדיקות ולאחר מכן הסבתם לאוטומציה ובפתרון בעיות של‬ ‫מומלצים לבדיקות אוטומטיות הם ‪ FIT‬ו‪ .)http://fitnesse.org) Fitnesse -‬העברת והבנת ידע בין אנשי האוטומציה לבודקים הידניים‪.‬‬ ‫‪ – Exploratory Testing‬בגישת ה‪ ,Agile-‬ביצוע בדיקות בגישה המסורתית‬ ‫(‪ )Scripted Testing‬כמעט ואינו אפשרי‪ ,‬שכן מסמכי האפיון מוכנים רק לאחר‬ ‫סיום הפיתוח‪ .‬מומלץ לבצע ‪( Pair Testing‬בודק מבצע הבדיקות והמפתח יושב‬ ‫מאחוריו מוסיף רעיונות)‪.‬‬

‫לסיום המצגת נתתי לכלל המשתתפים (מתברר שההרצאה הייתה מבטיחה כי‬ ‫באולם היו מעל ‪ 100‬משתתפים) תרגיל שבמהלכו הם היו אמורים לכתוב בדיקות‬ ‫באמצעות ה‪ – Funtasy-‬כלי ניהול בדיקות אוטומטיות של קווליטסט המהווה‬ ‫פלטפורמה לבודקים ידניים לכתיבת בדיקות אוטומטיות ללא צורך בשימוש בקוד‪.‬‬

‫‪( Usability Testing‬בדיקות שמישות) – נועדו לבדוק שהלקוח ‪ /‬משתמש‬ ‫יכול להשתמש במערכת בצורה אפקטיבית‪ .‬בדיקות שמישות בפיתוח ‪Agile‬‬ ‫היא בעבודה הצמודה מול מאפייני המערכת‪ .‬בניגוד למודלים אחרים בהם‬ ‫האחריות על שמישות המערכת היא של המאפיינים‪ ,‬לבודקים יש משקל רב‬ ‫יותר שכן הם “מייצגים” את נקודת ההשקפה של המשתמש‪.‬‬

‫סיכום‬

‫דיווח תקלות ווידוא תיקון – פה יש לציין שבצוותי ‪ Agile‬לא כל תקלה מתועדת‪.‬‬ ‫חלק גדול מהתקלות מתוקנות “במקום” ע”י המפתחים‪ .‬דיווח תקלות נעשה‬

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

‫מגזין חושבים בדיקות ׀ ינואר ‪ 2011‬׀ ‪11‬‬ ‫‪23-Dec-10 11:06:54 AM‬‬

‫‪STP.indd 11‬‬


‫ם‬ ‫י‬ ‫מ‬ ‫ש‬ ‫ר‬ ‫מכנס ‪STP‬‬

‫בלאס‪-‬וגאס‬

‫במהלך חודש אוקטובר הוזמנתי ע”י ארגון ‪Software Test) STP‬‬ ‫‪ (Professionals‬להרצות בכנס הבדיקות השנתי שלהם בלאס‪-‬וגאס‪ .‬הכנס‬ ‫הינו אחד הגדולים בארה”ב בתחום הבדיקות והשנה השתתפו בו מעל ‪1000‬‬ ‫אנשי בדיקות‪ .‬המרצים בהרצאה היום הגורואים המובילים בתחום הבדיקות‬ ‫בארה���ב ובעולם כולו כגון ג’רי ויינברג‪ ,‬מייקל בולטון‪ ,‬סקוט ברבר ועוד‪.‬‬ ‫הלקח החשוב ביותר מהנסיעה ללאס‪-‬וגאס הוא הכלל שאם הרווחת ביום‬ ‫הראשון בקזינו‪ ,‬תפסיד ביום השני‪ .‬עד עכשיו אני לא מבין לאן נעלמו ה‪400-‬‬ ‫דולר שהרווחתי ביום הראשון תוך שעתיים ביום השני ואליהם הצטרפו עוד ‪300‬‬ ‫דולר מהם נפרדתי בצער ביום השלישי‪.‬‬ ‫בין לבין הייתי במספר הרצאות‪ .‬להלן תמצות של ההרצאות שמצאתי‬ ‫כמעניינות ביותר‪.‬‬

‫‪Testers! Get Out of the Quality Assurance‬‬ ‫)‪Business (Michael Bolton‬‬

‫הרצאה של מייקל בולטון (בודקים‪ :‬אל תתקרבו לעסקי הבטחת האיכות)‪.‬‬ ‫מייקל ניסה בהרצאה להגדיר את המושג איכות‪ .‬ההגדרה של מייקל לאיכות‬ ‫היא‪ :‬נקודת השקפה (‪ )Perception‬של אדם לגבי התאמת מוצר לצרכים‬ ‫שלו‪ .‬ההגדרה רק מסבכת את נושא הבטחת האיכות שכן השקפת עולם‬ ‫היא דבר סובייקטיבי עבור כל משתמש‪ .‬בתור דוגמא נתן מייקל גיבור ילדים‬ ‫(הגרסא האמריקאית ליובל המבולבל)‪ .‬הדמות הזו נחשבת “איכותית” לילד‬ ‫בן ‪ ,8‬אבל כשהוא שאל בקהל מי אוהב אותו רוב התשובות היו שליליות (אני‬ ‫מעולם לא הבנתי מה ילדים מוצאים ביובל המבולבל‪ ,‬אבל כנראה שנולדתי‬ ‫בתקופה לא נכונה‪)...‬‬ ‫לדעתו של מייקל‪ ,‬הבטחת איכות לא יכולה להתממש בפועל ע”י אנשי בדיקות‬ ‫שכן לא ניתן בפועל להבטיח איכות‪ .‬לפיכך ההגדרה של מייקל היתה שהמטרה‬ ‫של אנשי הבדיקות היא לחקור (‪ )Investigate‬את המוצר על מנת לאתר‬ ‫נושאים אשר יפגעו בהשקפת העולם של המשתמש על המוצר‪.‬‬

‫)‪Hands-On Quicktests (Matt Heusser‬‬ ‫מטרת ההרצאה היא לספק כלים לביצוע בדיקות מהירות (‪)Quick Tests‬‬ ‫כאשר ישנו לחץ של זמן‪ .‬לדוגמא‪ ,‬כאשר נדרש לבצע בדיקות מהירות כאשר‬ ‫פרק הזמן שניתן הינו פחות מיממה או אפילו שעה אחת‪.‬‬ ‫אחד העקרונות הבסיסיים של ביצוע בדיקות מהירות הינו הבנת התהליך‬ ‫העסקי מתוך המערכת ולפנות למסמכי הדרישות (במידה והם קיימים או‬ ‫מעודכנים) רק כאשר נמצא חוסר הגיון לוגי בין המערכת לתהליך העסקי‪.‬‬ ‫במהלך ההרצאה ניתנה לכל המשתתפים גישה למערכת ניהול חניה בשדה‬ ‫תעופה‪ .‬המשתתפים היו אמורים לבצע בדיקות מהירות‪ .‬במהלך הבדיקות‬

‫תורגלו ‪ 2‬נושאים‪:‬‬ ‫ביצוע ‪ Modeling‬לתוכנה – אחת מהיכולות החשובות הנדרשות לבודק –‬ ‫היכולת להסיק מסקנות לוגיות לגבי אופן תפקוד התוכנה רק באמצעות‬ ‫חקירה (‪ )Exploration‬של התוכנה (לימוד המערכת כאשר אין מסמכי‬ ‫אפיון ומקור המידע היחיד הוא “לשחק” עם המערכת ולנסות להבין‬ ‫בצורה לוגית איך היא אמורה לעבוד)‪.‬‬ ‫הנושא השני הוא היכולת שלנו להתמקד בבדיקות חשובות באמת (ניהול‬ ‫סיכונים בבדיקות)‪ .‬משתתפים אשר מצאו באגים בתוכנה באמצעות‬ ‫הכנסת ערכים לא ריאליים הודרכו למקד את המאמצים שלהם ביצירת‬ ‫בדיקות אשר הסיכוי למימושם ע”י המשתמשים בפועל גבוה יותר‪.‬‬ ‫מאט הציג כלי ממש מדליק שנועד לבדוק את היכולות שלכם כבודקים‬ ‫באמצעות ה‪ .Testometer-‬הכלי מציג מספר אפליקציות ומבקש מכם‬ ‫לבדוק אותן‪ .‬באמצעות הבחירה שלכם את מקרי הבדיקה ורמת הכיסוי‬ ‫שלכם הוא נותן לכם ציון‪ .‬המלצה‪ :‬תחשבו כמו מפתחים ותנסו לענות על השאלה‬ ‫איפה המפתח יכול היה לטעות‪ ...‬ניתן למצוא מספר דוגמאות באתר ‪www.‬‬ ‫‪( TestingGeek.com‬חפשו ‪ Testometer‬תחת טאב ‪.)General Testing‬‬

‫)‪G Forces in the Organization (Kent Beck‬‬ ‫קנט בק נתן הרצאה אשר סקרה את ההתפתחויות האחרונות בעולם‬ ‫הבדיקות‪ .‬ההתפתחות המשמעותית ביותר הוא גידול משמעותי בקצב‬ ‫שחרור הגרסאות של ארגונים‪ .‬משחרור גרסא אחת לשנה‪ ,‬רוב הארגונים‬ ‫עובדים היום ברמה של מספר גרסאות בשנה‪ .‬הצפי של קנט הוא כי תהליך‬ ‫זה ימשיך‪ ,‬ובשנת ‪ 2030‬רוב הארגונים יעבדו בתצורה של גרסה חדשה‬ ‫שתשוחרר כל שבוע!!!‪.‬‬ ‫לתהליך זה השפעה משמעותית על עולם הבדיקות‪ .‬מצד אחד קצב העבודה עולה‪,‬‬ ‫לתחום הבדיקות האוטומטיות יהיה משקל קריטי בהצלחת הארגון ויהיה צורך‬ ‫להגיע ל‪ 100%-‬כיסוי אוטומטי של בדיקות רגרסיה‪ .‬מודל העבודה יעבור יותר ויותר‬ ‫לכיוון של ‪ .Agile‬גם גישת הבדיקות הולכת להשתנות‪ .‬הוצגו מספר דוגמאות‪:‬‬ ‫במקום דרישה לתיעוד מלא ותהליך עבודה מובנה‪ ,‬ייעשה יותר שימוש בלוחות‬ ‫מחיקים‪.‬‬ ‫במקום פגישות ארוכות ודיונים ‪ -‬פגישות של ‪ 15‬דקות (‪Stand-up meetings‬‬ ‫– חדרי פגישות ייעודיים ללא כסאות) במקום פגישות ארוכות‪.‬‬ ‫מקום עבודה בצוותים גדולים‪ ,‬העבודה תיעשה בצוותים קטנים (לדוגמא ‪Pair‬‬ ‫‪ – Development-Testing‬גישה בה עובד המפתח בצמוד לבודק התוכנה‬ ‫וכל פעולה נעשית ביחד)‪.‬‬ ‫במקום הגדרת תפקידים ברורה ייעשה שילוב אחריות ותפקידים (מפתח לא‬ ‫רק מפתח אלא גם בודק‪ ,‬בודקים לא רק מוצאים באגים אלא גם מתקנים‬ ‫אותם)‪.‬‬ ‫השפעת תהליך המעבר למודל ‪ Agile‬ניכרת בהרבה ארגונים‪ .‬גם בישראל‪,‬‬ ‫אפילו חברות שלא עברו באופן רשמי לפיתוח במודל זה‪ ,‬מקצרות בצורה‬ ‫עקבית את זמני הפיתוח שלהם וקצב שחרור הגרסאות לשוק‪.‬‬

‫)‪Testing in an Agile Environment (Rob Walsh‬‬ ‫ניתנה סקירה על פיתוח בגישת ה‪ .Agile-‬בעיקרון הרעיון הוא לחלק את‬ ‫המוצר לאבני בניין (‪ .)Building Blocks‬כל אבן בניין מכילה פיצ’ר אחד‬ ‫במערכת‪ .‬צוות הפיתוח מחולק לצוותים קטנים (‪ 4-5‬אנשים)‪ .‬כל צוות מכיל‬ ‫מפתחים‪ ,‬בודקים‪ ,‬מאפיינים ונציגי הלקוח (לקוח יכול להיות גוף פנימי בארגון‬ ‫או המשתמש הסופי)‪ .‬הפיתוח מחולק לאיטרציות‪ ,‬כאשר כל איטרציה נמשכת‬ ‫בין שבוע לחודש‪ .‬פיתוח גרסה מחולק למספר איטרציות עבור כל אבן בניין‪ .‬כל‬ ‫‪ 24‬שעות מבוצעת פגישת סטטוס על מנת לעבור על מה שבוצע ביום האחרון‬ ‫ומה שמתוכנן ליום הבא‪.‬‬

‫‪ 10‬׀ מגזין חושבים בדיקות ׀ ינואר ‪2011‬‬

‫‪23-Dec-10 11:06:53 AM‬‬

‫‪STP.indd 10‬‬


‫‪7‬‬

‫טעות מספר ‪ :7‬לא ניתן לאמוד את היקף העבודה‬ ‫הדרוש לביצוע ‪Exploratory Testing‬‬

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

‫‪8‬‬

‫טעות מספר ‪ :8‬אתה חייב לבחור‪:‬‬ ‫או ‪ Exploratory Testing‬או‬ ‫בדיקות ידניות‬

‫אין דבר כזה ‪ 100%‬בדיקות ידניות‪ .‬אפילו כאשר תהליך הבדיקה‬ ‫משמעותו יצירת מקרי בדיקה וביצוע אותם מקרי בדיקה )ורק‬ ‫אותם(‪ ,‬עדיין ייעשה שימוש ב ‪ .ET‬אמנם‪ ,‬לא בשלב ההרצה )אלא‬ ‫אם כן נמצאו באגים ואז בדרך כלל בחינת הבאג דורשת חקירה על‬ ‫ידי הבודק(‪ ,‬אלא לשם התכנון והעיצוב של מקרי הבדיקה‪.‬‬ ‫ניסיוננו מוכיח שגם בארגונים המבצעים בדיקות ידניות בלבד )או‬ ‫לפחות כך הם חושבים‪ ,‬מאחר ובדיקות ידניות טהורות אינן קיימות(‪,‬‬ ‫כאשר שואלים את השאלה ”כמה מהפגמים שמצאת התגלו על ידי‬ ‫ביצוע התסריטים?“ התשובה לעולם איננה ”כולם“‪ .‬למעשה‪ ,‬חלק‬ ‫גדול מהבאגים מתגלים דווקא בזמנם ”החופשי“ של הבודקים‬ ‫כאשר הם מבצעים בדיקות נוספות שאינן מוגדרות מראש‪.‬‬ ‫יהיה זה יהיר לומר שלעולם אין צורך בבדיקות מתועדות מראש‪.‬‬ ‫בדיקות מתועדות מראש בהחלט עשויות להועיל לבודקים‬ ‫כקו מנחה ועל מנת להבטיח כיסוי‪ ,‬כל עוד שומרים על חופש‬ ‫הפעולה והאחריות של הבודקים‪ .‬באחד הפרויקטים הקודמים‬ ‫שלי‪ ,‬שילבתי בדיקות מתועדות מראש יחד עם ‪ ET‬על ידי‬ ‫הקצאת ‪ 15‬הדקות הראשונות בכל ‪ Session‬לביצוע בדיקה‬ ‫ידנית שכיסתה את הפונקציונאליות הבסיסית )בדיקת שפיות(‬ ‫בעוד ששאר המקטע הוקדש לביצוע ‪ .ET‬על מנהל בדיקות‬ ‫נבון מוטל למצוא את האיזון בין ‪ ET‬לבדיקות מתועדות מראש‬ ‫אשר יוביל לתוצאה הטובה ביותר עבור הפרויקט שלו‪.‬‬

‫‪9‬‬

‫טעות מספר ‪ :9‬יש סיכון גדול‬ ‫בעבודה בלי תסריטים מוגדרים מראש‬

‫הבעיה בביצוע תסריטים מוגדרים מראש היא ההנחה שאנו כבר‬ ‫יודעים היכן בתוכנה הבאגים מסתתרים‪ ,‬לפני שהתחלנו לבדוק‪.‬‬ ‫לתהליך כזה צריך בעצם לקרוא אימות‪ .‬בדיקות של ממש‬ ‫משמעותן חקירת התנהגות המוצר והקצאת אזורי סיכון על ידי‬ ‫ניתוח נתונים ומידע שאנו אוספים במהלך החקירה‪ .‬אם ברצוננו‬ ‫לחקור היטב‪ ,‬אסור לנו להניח שהסיכון הקריטי ביותר כבר זוהה‪.‬‬ ‫בנוסף‪ ,‬ביצוע בדיקות מתועדות מראש גורם למצב של עיוורון לא‬ ‫מכוון )‪ .(Inattentional Blindness‬מצב זה נגרם מכיוון שאנו כה‬ ‫שקועים בקריאה והבנה של תסריטי הבדיקות עד שאנו מפספסים‬ ‫באגים שפשוט ”נמצאים מול העיניים“‪.‬‬

‫!‬

‫‪10‬‬

‫טעות מספר ‪ :10‬אי אפשר‬ ‫ליישם ‪Exploratory Testing‬‬ ‫במערכות מורכבות‬

‫ככל שהמערכת מורכבת יותר‪ ,‬כך ניתן ליצור יותר מקרי בדיקה‬ ‫לבדיקת המערכת‪ .‬זו הסיבה שלמערכות מורכבות מבצעים‬ ‫ניתוח סיכונים ברמה זו או אחרת כאשר עומדים להחליט‬ ‫אילו מקרי בדיקה יתוכננו ואילו לא‪ .‬אולם‪ ,‬ברגע שהבדיקות‬ ‫תוכננו‪ ,‬הן אלה שתבוצענה‪ .‬כתוצאה מכך‪ ,‬קיימת האפשרות‬ ‫שתהליך הבדיקה לא יזהה פגמים החבויים בתחומי הבדיקות‬ ‫שלא תוכננו‪.‬‬ ‫אחד היתרונות העיקריים של השימוש ב‪ ET -‬הוא החופש‬ ‫הניתן לבודק לבחור תרחישים שונים בכל מחזור בדיקה‪ .‬כך‬ ‫משיגים כיסוי טוב יותר של המערכת — יותר פגמים מאותרים‪,‬‬ ‫ומתקבלת איכות גבוהה יותר של המערכת הנבדקת‪ .‬השורה‬ ‫התחתונה היא‪ :‬ככל שהמערכת מורכבת יותר‪ ,‬היא מתאימה‬ ‫יותר ליישום ‪.ET‬‬

‫לסיכום‬

‫בודקים רבים חוששים להטמיע ‪ ET‬במסגרת תוכנית הבדיקות שלהם‪ .‬החשש נובע‬ ‫מסיבות כגון‪ :‬העדר תיעוד‪ ,‬יכולת בקרה מוגבלת‪ ,‬בעיית כיסוי של המערכת הנבדקת‬ ‫ועוד סיבות שונות ומגוונות‪.‬‬ ‫במאמר סקרנו את ‪ 10‬הטעויות השכיחות ביותר בנוגע ל‪ ET -‬מתוך מטרה להראות‬ ‫שטכניקה זו יכולה להיות יעילה לא פחות מכל טכניקה אחרת ואף טובה יותר‪.‬‬ ‫לא מספיק להריץ בדיקות חופשיות ולקרוא להם ‪Exploratory Testing .Exploratory‬‬ ‫‪ ,Testing‬למרות הדיעה הרווחת בקרב הרבה אנשי בדיקות בישראל‪ ET ,‬הינה גישה‬ ‫מאוד מוסדרת ומתועדת והניסיון ”לבלגן“ אותה יוביל לתוצאות לא אופטימליות‪.‬‬ ‫אנו מאמינים שבכל פרויקט בדיקות‪ ,‬עבור כל מערכת או גרסה ולכל סוג של ארגון יש‬ ‫להטמיע ‪ ET‬כחלק מתוכנית הבדיקות באופן מסודר‪ .‬במקומות מסויימים זו יכולה להיות‬ ‫הטכניקה המובילה והעיקרית ובמקומות אחרים כטכניקה משנית‪ /‬נוספת‪ .‬אבל היום ברור‬ ‫יותר מתמיד שבאמצעות שיטות בדיקה יוריסטיות כמו ‪ ET‬ניתן למצוא הרבה תקלות‪,‬‬ ‫ב“איכות“ גבוהה ובזמן קצר וזה משהו שכל בודק או מנהל בדיקות שואף להגיע אליו‪.‬‬

‫?‬

‫מקורות‬

‫‪ Article: Exploratory Testing Explained http://www.satisfice.com/articles/‬‬ ‫‪et-article.pdf‬‬ ‫‪ Michael Bolton Blog, Project Estimation and Black Swans: http://www.‬‬ ‫‪developsense.com/blog/2010/10/project-estimation-and-black-swans/‬‬ ‫‪ Michael Bolton website: http://www.developsense.com/resources.html‬‬ ‫‪ James Bach website: http://www.satisfice.com/blog‬‬ ‫‪ Podcast: Chatting with James Bach: http://www.codingqa.com/index.‬‬ ‫‪php?post_id=550220‬‬ ‫‪ Podcast: James Bach - The role of a tester: http://5whys.com/blog/‬‬ ‫‪interview-james-bach-ndash-the-role-of-the-tester.html‬‬

‫מגזין חושבים בדיקות ׀ ינואר ‪ 2011‬׀ ‪9‬‬ ‫‪27-Dec-10 10:37:55 AM‬‬

‫‪Cover_Story_2.indd 9‬‬


‫‪ 10‬הטעויות הנפוצות ביותר בבדיקות חקירה‬

‫‪3‬‬

‫‪4‬‬ ‫טעות מספר ‪ :3‬המיומנויות‬ ‫הדרושות לבודק ‪Exploratory‬‬ ‫‪ Testing‬שונות מאלה של בודק‬ ‫ידני )‪(Scripted Tester‬‬

‫אין דבר כזה ”בודק ‪ ET — “ET‬אינה משנה את הפעולות‬ ‫העיקריות הכרוכות בבדיקות‪ .‬אפשר לנסח זאת כך‪ ET ,‬רק‬ ‫משנה את לוח הזמנים לביצוע הפעולות‪ :‬במקום ללמוד את‬ ‫המוצר‪ ,‬לתכנן את הבדיקות ואחר כך לבצען‪ ,‬כל הפעילויות‬ ‫מתבצעות במקביל‪.‬‬ ‫רוב האנשים הכשירים לתכנון בדיקות מתאימים גם לביצוע‬ ‫‪ .Exploratory Testing‬אולם‪ ,‬אם תעסיק בודק שיש לו‬ ‫מיומנויות ביצוע בלבד )‪ ,(Monkey Tester‬הוא יתקשה לפעול‬ ‫לפי גישת ‪ .ET‬מאידך‪ ,‬הניסיון שלנו מוכיח שאותו בודק יתקשה‬ ‫ליישם גם בדיקות אחרות‪ ,‬בלי קשר לגישת הבדיקות בה‬ ‫משתמשים‪...‬‬

‫‪5‬‬

‫טעות מספר ‪ :4‬אין צורך להכשיר בודקים לעבודה‬ ‫בגישת ‪Exploratory Testing‬‬

‫‪ ET‬הוא כמו שחמט‪ ,‬אפשר ללמוד את המשחק תוך זמן קצר‪ ,‬אך ללמוד לשחק היטב‬ ‫כבר איננו עניין של מה בכך‪ .‬על בודק ‪ ET‬להיות מצויד היטב בטכניקות בדיקה על מנת‬ ‫לבצע ‪ ET‬באופן מוצלח ויעיל‪.‬‬ ‫דיווח הוא דוגמא אחת למיומנות חשובה הדרושה לביצוע ‪ .ET‬בתהליך ‪ ,SBTM‬הבודק נדרש‬ ‫לספק דוח בדיקה הכולל רישום של הבדיקות שביצע ושל הרעיונות והמשימה שעמדו מאחורי‬ ‫הבדיקה‪ .‬גם בודקים מנוסים חסרים את מיומנות הדיווח‪ ,‬ומוצאים שפעילות הרישום מפריעה‬ ‫לרצף החשיבה שלהם‪ .‬יש צורך לתרגל גם את אופן הכתיבה‪ :‬בודקים רבים נוטים לסכם‬ ‫בקצרה את הבדיקות שביצעו במילים‪” :‬בדקתי את המערכת“‪ ,‬אחרים נוטים לפירוט יתר )לחץ‬ ‫”אישור“‪ ,‬הקלד יוסי בשדה שם פרטי‪ ,‬וכו‘(‪ .‬על הרשימות לכסות לא רק את הפעולות שנעשו‪,‬‬ ‫אלא גם לספק מידע מפורט על מה שהיה לך בראש ומה רצית לבדוק בכל בדיקה‪.‬‬ ‫דוגמא נוספת להכשרה הדרושה ב‪ ET-‬היא מיומנות המעבר בין מבט ממוקד למבט‬ ‫מלמעלה )‪ focus‬ו‪ .(de-focus-‬כאשר בודקים מערכת‪ ,‬בודקים עשויים להתמקד‬ ‫במודול מסוים אותו הם בודקים עד כדי התעלמות מהתמונה הכוללת‪ .‬חלק מההכשרה‬ ‫הדרושה לקראת ‪ ET‬היא היכולת להתמקד ולעבור למבט כללי‪ .‬קל מאד להסביר את‬ ‫העניין אך היכולת לפעול כך דורשת הכשרה ותרגול רב‪.‬‬

‫טעות מספר ‪Exploratory Testing :5‬‬ ‫משמעותה העדר שקיפות ויכולת בקרה‬

‫אחת הטענות המרכזיות כנגד ‪ ET‬היא שהגישה אינה מאפשרת להנהלה שליטה‬ ‫על זהות התוכן הנבדק‪ .‬למעשה‪ ,‬אנו מאמינים שזהו הטיעון העיקרי כנגד בדיקות‬ ‫ידניות )‪.(scripted testing‬‬ ‫לרוב בדיקות ידניות מניבות כמויות גדולות של מסמכי בדיקה‪ ,‬לעיתים עד אלפי‬ ‫עמודים ויותר‪ .‬ברוב המקרים‪ ,‬מסמכים אלה אינם נבחנים בצורה יסודית ובפועל‬ ‫נסקר רק מדגם מייצג מתוך הבדיקות‪.‬‬ ‫במהלך ‪ ,ET‬בסיום כל מקטע‪ ,‬מפיקים דוח בדיקה המכיל טופס רישום של תנאי‬ ‫הבדיקה‪ ,‬האזור הנבדק‪ ,‬רשימת הבאגים שנמצאו‪ ,‬רשימות מפורטות לגבי אופן‬ ‫ביצוע הבדיקה‪ ,‬רשימת בעיות )שאלות פתוחות‪ ,‬עניינים הדורשים התייחסות במוצר‬ ‫או בפרויקט(‪ ,‬קבצים ששימשו את הבודק או נוצרו על ידו לצורך הבדיקה‪ ,‬אחוז‬ ‫הזמן שהוקדש לטופס הרישום לעומת חקירת אפיקים חדשים‪ ,‬אחוז הזמן שהוקדש‬ ‫ליצירת בדיקות ולביצוען‪ ,‬לחקירת באגים ולדיווחם‪ ,‬להגדרת המקטע או לפעילויות‬ ‫לא‪-‬בדיקתיות אחרות‪ ,‬וכן שעת פתיחת המקטע ומשך המקטע‪ .‬למרות שרשימת‬ ‫הפריטים הכלולה בדוח הבדיקה נראית ארוכה‪ ,‬היא בדרך כלל אינה ממלאת יותר‬ ‫מאשר עמוד אחד או מספר דפים בודדים‪ ,‬כמות שבקלות ניתן לסקור ולשלוט בה‬ ‫ומאפשרת שיפור יכולת הבקרה והשקיפות של החומר הנבדק‪.‬‬ ‫באחד הארגונים בהם עבדנו הגדרנו את התפקיד ”מוביל בדיקות“ )‪(Test Lead‬‬ ‫שתפקידו העיקרי היה לסקור את דוחות הבדיקה‪ .‬בסיום כל מקטע‪ ,‬מוביל‬ ‫הבדיקות ביצע תחקור מסודר של דוח הבדיקה‪ .‬המטרה היתה לוודא ביצוע תקין‬ ‫של הבדיקה וכן שהבודקים כיסו את כל התרחישים הדרושים‪ .‬רישומי הבודקים‬ ‫הם האמצעי ששימש את מוביל הבדיקות בבואו לוודא שהבודק הבין את‬ ‫המערכת הנבדקת והיה מסוגל להציע היכן היא עלולה להיכשל‪ .‬בפועל‪ ,‬היתה זו‬ ‫הפעם הראשונה שנעשתה סקירה אמיתית של התוכן הנבדק‪...‬‬ ‫על מנת להקל על הדיווח במסגרת ‪ ,ET‬כדאי מאד להשתמש בכלי להקלטת מסך כגון‬ ‫‪ .Spector Pro‬כלי להקלטת מסך רושם ושומר מדי מספר שניות כל פעולה הנעשית‬ ‫על ידי הבודקים כתמונת מפת סיביות )‪ .(bitmap‬כלי זה מאפשר לבודק לצמצם את‬ ‫נפח הדיווח הדרוש ולמקד את מאמציו בהעלאת רעיונות בדיקה חדשים‪.‬‬

‫‪6‬‬

‫טעות מספר ‪Exploratory Testing :6‬‬ ‫דורשת יותר זמן מאשר בדיקות ידניות‬

‫בטרם נשווה את המשאבים הדרושים לביצוע ‪ ET‬לאלה הדרושים לבדיקות‬ ‫ידניות‪ ,‬עלינו לענות על השאלה ”כמה זמן דרוש לנו על מנת לבדוק את‬ ‫המערכת“‪ .‬ובכן‪ ,‬לא נוכל לתת תשובה ממשית לשאלה זו‪ .‬מכל מקום‪ ,‬לפני‬ ‫שננסה לענות עליה‪ ,‬אנו חייבים לענות על שאלה אחרת‪ :‬מהי רמת האיכות‬ ‫אותה אנו מנסים להשיג? אם התשובה היא מערכת נטולת באגים‪ ,‬התשובה‬ ‫לשאלה הראשונה היא כמות אינסופית של משאבים‪ .‬לכל מערכת וארגון ישנן‬ ‫ציפיות איכות שונות ואלה משתקפות בכמות המשאבים המוקצים לאבטחת‬ ‫איכות‪ .‬כמות המשאבים תלויה גם במורכבות המערכת‪ ,‬במספר הגרסאות שיש‬ ‫לבדוק‪ ,‬באיכות הקוד וכו‘‪.‬‬ ‫אם כן‪ ,‬העיקר אינו כמות הזמן הדרושה לבדיקות‪ ,‬אלא עד כמה יעילות‬ ‫תהיינה הבדיקות אותן נבצע‪ .‬את זאת נוכל לאמוד על ידי ספירת הפגמים‬ ‫המאותרים במשך שעת בדיקה‪ ,‬וקביעת חומרתם‪.‬‬ ‫היעילות של ‪ ET‬המבוצע נכון‪ ,‬גבוהה בהרבה מזו של בדיקות מתועדות‬ ‫מראש‪ .‬יש לכך סיבות רבות‪ ,‬חלקן מובאות לפניכם‪:‬‬ ‫‪ ‬בעת ביצוע ‪ ,ET‬לרשות הבודק עומד מידע רב יותר לגבי המערכת‬ ‫הנבדקת )גם האפיון וגם מידע המתקבל מהמערכת עצמה( ולכן הוא‬ ‫יכול להמציא יותר מקרי בדיקה ולגלות יותר פגמים‪.‬‬ ‫‪ ‬המידע הנאסף במהלך הבדיקות מסייע לבודקים להתמקד‬ ‫בפונקציונאליות הנמצאת בסיכון גבוה‪.‬‬ ‫‪ ‬בבדיקות ידניות‪ ,‬שלב הלמידה מתבצע הרבה לפני שלב ביצוע הבדיקות‪.‬‬ ‫בזמן החולף בין תכנון הבדיקות לבין ביצוען )לעיתים הבדיקות מבוצעות‬ ‫מספר חודשים אחרי התכנון( הבודק שוכח חלק מן המידע‪ ,‬ולכן יהיה עליו‬ ‫ללמוד מחדש את המוצר‪ .‬במקרים רבים‪ ,‬הבודק שתכנן את הבדיקה אינו‬ ‫זה שיבצע אותה ולכן כל הזמן שהושקע בלימוד המערכת הולך לאיבוד‪.‬‬ ‫‪ ‬קריאת מסמך בדיקות וביצועו לאחר מכן אורכים זמן רב יותר מאשר חשיבה‬ ‫על הבדיקה‪ ,‬ביצועה וכתיבת הערות לגביה במקביל )תוכלו לדמות זאת‬ ‫בעצמכם — פשוט מדדו את הזמן הדרוש לביצוע עשרה מקרי בדיקה כתובים‪.‬‬ ‫לאחר מכן מדדו כמה זמן לוקח לחשוב על עשר בדיקות‪ ,‬לבצע אותן ולכתוב‬ ‫את ההערות(‪.‬‬

‫‪ 8‬׀ מגזין חושבים בדיקות ׀ ינואר ‪2011‬‬

‫‪27-Dec-10 10:37:54 AM‬‬

‫‪Cover_Story_2.indd 8‬‬


‫באחת השיחות שניהלתי עם מנהל ‪ QA‬וותיק בחברת תקשורת גדולה‪,‬‬ ‫ניסיתי להציג בפניו את גישת ה‪ .Exploratory Testing-‬לאחר הצגה‬ ‫ראשונה התגובה הייתה מפתיעה‪” :‬אנחנו כבר עושים את זה בארגון‪ .‬כאשר‬ ‫אנו מסיימים את הרצת מפרטי הבדיקות או כאשר אין לי זמן‪ ,‬אני נותן‬ ‫לבודקים שלי להתפרע וככה אני מוצא את רוב הבאגים במערכת“‪.‬‬ ‫התיאור שלהלן הינו אמנם דרך אחת לעשות ‪ ,Exploratory Testing‬אבל‬ ‫דרך מאוד לא טובה! הרי לא סביר שדווקא הגישה אשר מניבה הכי הרבה‬ ‫תוצאות )באגים( תבוצע באופן לא מבוקר ולא מסודר בעוד שהדגש על סדר‬ ‫וארגון יתבצע דווקא בגישה הפחות יעילה‪...‬‬ ‫השוק הישראלי מפוצל בגישתו לגבי ‪ (ET) Exploratory Testing‬כטכניקות‬ ‫בדיקה מתאימות‪ .‬ישנם כאלו הסוברים כי ‪ ET‬אינן מהוות גישה לגיטימית‬ ‫לבדיקות בטענות שונות כגון אי‪-‬כיסוי מלא של המערכת הנבדקת‪ ,‬חוסר‬ ‫יכולת לבצע בקרה וכו‘‪ .‬מצד שני‪ ,‬רבים‪ ,‬כגון אותו מנהל ‪ ,QA‬טוענים כי ‪ET‬‬ ‫כבר מבוצעות בארגונם‪ ,‬אולם ‪ ET‬מוגדרות כבדיקות אד הוק — דהיינו בדיקות‬ ‫לא מתועדות‪ ,‬לא מבוקרות )מעין ‪ free style‬או ‪.(monkey testing‬‬

‫ההגדרה המוכרת ביותר ל ‪ET‬‬ ‫נטבעה על ידי ג‘יימס באך‬ ‫וקאם קנר )‪James Bach‬‬ ‫‪:(and Cem Kaner‬‬ ‫‪ ET‬הינן פעילות במקביל של‬ ‫למידה‪ ,‬תכנון בדיקות‪ ,‬וביצוען‪.‬‬ ‫לאחרונה שונתה ההגדרה ל‪:‬‬ ‫‪ ET‬מהווה גישה לבדיקות‬ ‫המדגישה את חופש הפעולה‬ ‫והאחריות של כל בודק‬ ‫למקסם את ערך עבודתו‪ .‬זאת‬ ‫ניתן לעשות אם מתייחסים אל‬ ‫למידה‪ ,‬עיצוב בדיקות וביצוע‬ ‫בדיקות כאל פעולות התומכות‬ ‫זו בזו והמתקיימות במקביל‬ ‫לכל אורך הפרויקט“‪.‬‬

‫גישות אלו וכן גישות רבות אחרות נובעות מחוסר הבנה של גישת ה‪Exploratory-‬‬ ‫‪ .Testing‬במאמר זה ננסה להסביר את עקרונות הגישה באמצעות הצגת‬ ‫דיעות מוטעות אותן שמענו לגבי הנושא והסבר לגבי אותן נקודות‪.‬‬

‫‪2‬‬

‫טעות מספר ‪ Exploratory Testing :2‬אינה‬ ‫מבטיחה כיסוי המערכת‬

‫אכן ביצוע של ‪ ET‬באופן לא נכון עלול לגרום לכיסוי חלקי של המוצר‪ ,‬בדיוק‬ ‫כשם שתכנון בדיקות מראש )‪ (Scripted Testing‬לא נכון יכול להביא לאותה‬ ‫תוצאה‪.‬‬ ‫בארגונים רבים‪ ,‬עיצוב בדיקה משמעה בפועל תרגום או שכתוב של מסמכי‬ ‫הדרישות לצורת מקרי בדיקה ומסמכי בדיקות‪ .‬תהליך זה ניתן ליישום באופן‬ ‫ממוכן לחלוטין שאינו דורש חשיבה כלל‪ .‬מנהלים עשויים לחשוב שעל ידי כך‬ ‫הם מבטיחים כיסוי של המערכת הנבדקת‪ ,‬אך ברוב המקרים התהליך מכסה‬ ‫רק את אימות המערכת )‪ (Verification‬ואינו מתקף )‪ (Validate‬פעילות‬ ‫תקינה של המערכת‪ .‬לרוב לא ניתן לחזות באגים מתוך הדרישות מבלי לבצע‬ ‫ניתוח מקיף של המערכת‪ .‬לדוגמא‪ :‬כאשר ”נתרגם“ את רשימת הדרישות‬ ‫למקרי בדיקה לא נוכל למצוא בעיות הנובעות מהשפעה של פעילות במודול‬ ‫אחד על תפקוד של מודול אחר או לבדוק את המערכת בתנאי שטח שאינם‬ ‫מוזכרים במסמכי הדרישות‪ .‬בנוסף‪ ,‬כל מרכיב החסר ממסמך הדרישות‬ ‫ישובץ במוצר מבלי לתת לבודקים הזדמנות למצוא אותו‪.‬‬

‫שימוש במתודולוגית ‪ (Session-Based Test Management) SBTM‬הוא‬ ‫דוגמא לשיטה להבטחת כיסוי של המערכת הנבדקת‪ SBTM .‬מחלק את כל‬ ‫הבדיקות למקטעים )‪ .(Sessions‬לכל מקטע יש משימה )‪(Test Mission‬‬ ‫וטופס רישום )‪ (Charter‬אשר ביחד מגדירים את גבולות הבדיקה )מה‬ ‫נדרש לבדוק(‪ .‬שימוש ב ‪ SBTM‬יכול לסייע לצוותי הבדיקה בהבטחת הכיסוי‬ ‫ובאותה עת משאיר לבודקים חופש להפעיל שיקול דעת שמבטיח כיסוי מלא‬ ‫של המערכת‪ .‬מידע נוסף אודות ‪ SBTM‬ניתן למצוא באתר של ג‘יימס באך‬ ‫‪www.satisfice.com‬‬ ‫שיטה נוספת להבטחת כיסוי הדרישות הינה באמצעות שימוש ב“טבלאות‬ ‫מצב“ )‪ .(State Tables‬נוהל זה מבוסס על קישור ‪) Session Logs‬לוג הנכתב‬ ‫בסיום הרצת כל ‪ Session‬ומפרט את הבדיקות שבוצעו( לדרישות ‪ /‬איפיון‬ ‫המערכת‪ ,‬כך שנוצרות טבלאות עקיבה המצביעות על ה‪ Session-‬שבמהלכו‬ ‫נבדק כל מקרה בדיקה )‪.(Test Case‬‬ ‫חשוב לציין שבדיקת כל מקרי הבדיקה שבדרישות אינה מוכיחה שהמערכת‬ ‫אכן נבדקה‪ .‬אלא‪ ,‬שאם בודקים את כל הדרישות בגישת ‪ ,ET‬מגבירים את רמת‬ ‫הביטחון בכך שרוב הבאגים במערכת אכן נמצאו‪.‬‬

‫אוקטובר ‪2010‬‬ ‫בדיקות ׀ ינואר‬ ‫בדיקות ׀‬ ‫חושבים‬ ‫חושבים‬ ‫מגזיןמגזין‬ ‫‪ 2011‬׀ ‪7‬‬

‫‪27-Dec-10 10:37:54 AM‬‬

‫‪Cover_Story_2.indd 7‬‬


‫‪ 10‬הטעויות‬ ‫הנפוצות ביותר בנושא‬ ‫‪Exploratory‬‬ ‫‪Testing‬‬ ‫רוני וולפינזון‬ ‫ואיל זילברמן‬

‫בחברת ‪.Intel‬‬

‫איל זילברמן‬ ‫איל זילברמן הוא ממיסדי חברת קווליטסט‬ ‫ובעל יותר מ‪ 14-‬שנות ניסיון בבדיקות תוכנה‬ ‫במגוון חברות וארגונים‪ ,‬בארץ ובחו“ל‪.‬‬

‫רוני וולפינזון‬ ‫רוני וולפינזון פועל בתחום בדיקות התוכנה‬ ‫מאז ‪ ,2006‬ועסק בעיקר בתחום המערכות‬ ‫הצבאיות‪ .‬רוני שימש כיועץ ומנהל פרויקטים‬ ‫עבור חברות כמו‪ :‬חיל האויר‪ ,‬אלביט מערכות‬ ‫והתעשיה האוירית לישראל‪ .‬כיום משמש‬ ‫רוני כמנהל בדיקות‬

‫‪1‬‬

‫טעות מספר ‪ Exploratory Testing :1‬היא‬ ‫טכניקה בלתי מובנית ואינה דורשת תיעוד‬

‫רבים סבורים כי ‪ ET‬היא גישה שאינה דורשת תיעוד‪ ,‬אך היא יכולה להיות מתעדת‬ ‫מאד‪ ,‬מובנית במפורש‪ ,‬ומחמירה ביותר‪ .‬ההבדל היחיד בין ‪ ET‬לבין בדיקות‬ ‫ידניות מתועדות מראש )‪ (scripted testing‬הוא שבמסגרת ‪ ,ET‬שלושת‬ ‫פעילויות הבדיקה העיקריות )למידה‪ ,‬תכנון הבדיקות וביצוען( מתבצעות‬ ‫במקביל והינן פעולות התומכות זו בזו‪ ,‬לאו דווקא באופן עוקב‪ .‬הכוונה אינה‬ ‫שאפשר לוותר על אחת מהן או להתחמק מביצועה‪ .‬אלא‪ ,‬שבמקום לקיים‬ ‫את שלוש הפעילויות בנפרד‪ ,‬ב ‪ ET‬מבצעים את שלושתן בתהליך תומך והדדי‪.‬‬ ‫לדוגמא‪ :‬בעת הרצת בדיקה‪ ,‬עשוי לצוץ מידע חדש או רעיון חדש שיש בו לסייע‬ ‫לבודק‪ ,‬הן ליצור בדיקה חדשה והן להבין את המוצר )זו הסיבה שבארגונים‬ ‫רבים הבודקים הם האנשים המתמצאים ביותר ברזי המוצר(‪.‬‬ ‫כל בדיקה היא מובנית )‪ (Structured‬מטבעה! השאלה הנשאלת היא‪:‬‬ ‫כיצד הבדיקה מובנית? לעיתים קרובות‪ ,‬בודקים ‪ ET‬בלתי מיומנים טועים‬ ‫לחשוב שגישת ‪ ET‬אינה מובנית משום שהם בודקים באופן לא עקבי‪ ,‬כלומר‪:‬‬ ‫מבצעים בדיקות שונות בכל מחזור בדיקות‪.‬‬

‫‪ 6‬׀ מגזין חושבים בדיקות ׀ ינואר ‪2011‬‬

‫‪27-Dec-10 10:37:50 AM‬‬

‫‪Cover_Story_2.indd 6‬‬


‫קרוב יותר‬ ‫טוב יותר‬ ‫זול יותר‬

‫פרויקט מרגליות של‬ ‫קווליטסט מעסיק מעל ‪100‬‬ ‫בודקות ומציע את המקצועיות‬ ‫הגבוהה של קווליטסט במודל‬ ‫‪ LOW COST‬מקומי‬

‫למידע נוסף ותיאום פגישת היכרות‪:‬‬ ‫‪Margaliot@QualiTest.co.il‬‬


‫דבר העורך יואל מונטבליסקי‬

‫הכנסו עכשיו‬ ‫לאתר המגזין‬ ‫והרשמו למנוי‬ ‫בחינם!‬

‫‪www.ThinkTesting.co.il‬‬

‫ברוכים הבאים לגליון‬ ‫השני של חושבים‬ ‫בדיקות‪ ,‬מגזין הבדיקות‬ ‫העברי הראשון מסוגו‬ ‫בישראל‪.‬‬

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

‫אני רוצה להתחיל עם מאמר המערכת המדבר על‬ ‫‪ .Exploratory Testing‬המאמר בא לשבור סטיגמות‬ ‫המיוחסות לגישה זו שלא בצדק לטעמי‪ ,‬אלא עקב חוסר‬ ‫הבנה‪ .‬אחד מהדברים שהכי אהבתי זה שבין שורות הכתבה‬ ‫גם ניתן ללמוד מספר טכניקות וטיפים חשובים למי שאינו‬ ‫בקיא ב‪ ET-‬ורוצה לנסות אותה במהלך הבדיקות שלו‪.‬‬

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

‫מאמר נוסף שמאוד נהנתי לקרוא הוא זה של טלמון‬ ‫בן‪-‬כנען על ‪ .Pairwise Testing‬הוא נותן דוגמה‬ ‫קונקרטית ושימושית לטכניקה שהרבה אנשים מכירים‬ ‫אבל ממעטים להשתמש מכיוון שהם חושבים שהשיטה‬ ‫מסובכת ותאורטית מדי‪.‬‬

‫בשלושת החודשים האחרונים דיברנו עם הרבה אנשים‪,‬‬ ‫סקרנו לא מעט תחומים וחיפשנו את החומרים והנושאים‬ ‫שבאמת יעזרו לכם — בודקי תכנה מקצוענים — להתקדם‬ ‫ולהנות מעולמכם המקצועי‪ .‬לשמחתנו מצאנו הרבה‬ ‫נושאים מעניינים ואנשים מוכשרים שרצו לכתוב עליהם‪.‬‬ ‫המגזין מורכב ממספר טורים קבועים )מגמות בבדיקות‪,‬‬ ‫המלצות על ספר ועל בלוג‪ ,‬ראיון עם מנהל בדיקות ויומנו‬ ‫של בודק מתחיל( ומאמרים מקצועיים שנכתבו ע“י‬ ‫בודקים ומנהלי בדיקות מהשטח‪ .‬בכל מהדורה ישנו נושא‬ ‫מוביל שסביבו נכתב המאמר הראשי והסקר המקצועי‪,‬‬ ‫במהדורה זו הנושא המוביל הינו ‪.Exploratory Testing‬‬ ‫לדעתי )אבל אני משוחד!( כל המאמרים מעניינים וקשה‬ ‫להצביע על כמה מהם באופן מסוים‪ ,‬אבל בין כל המאמרים‬ ‫במהדורה אני רוצה להתמקד בשלושה שאני אוהב במיוחד‪.‬‬

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

‫קריאה מהנה‪,‬‬ ‫יואל‪.‬‬

‫לתגובות‪ ,‬הערות‪ ,‬והצעות‪Joel@thinktesting.co.il :‬‬

‫‪ 4‬׀ מגזין חושבים בדיקות ׀ ינואר ‪2011‬‬

‫‪27-Dec-10 10:21:43 AM‬‬

‫‪Editor_02.indd 4‬‬


‫העניינים‬ ‫תוכן‬ ‫גליון מס‘ ‪ 02‬׀ ינואר ‪2011‬‬ ‫‪ 4‬דבר העורך יואל מונטבליסקי‬

‫‪ 22‬תחרות בודק השנה של ‪ICTB‬‬

‫‪ 10 6‬דברים שחשבת שאתה יודע על‬ ‫‪Exploratory Testing‬‬ ‫רוני וולפינזון ואיל זילברמן‬

‫‪ 24‬איך )‪ (NOT‬לפשל באוטומציה‬ ‫אסף סהר‬

‫‪ 10‬רשמים מכנס ‪ STP‬בלאס וגאס‬ ‫איל זילברמן‬ ‫‪ 12‬ראיון עם מנהל בדיקות אביעד בן יצחק‬ ‫‪ 14‬בדיקות אבטחת מידע לבודקי תוכנה‬ ‫ירון חקון‬ ‫‪ 18‬בודקים קצת אחרת‪ .‬בעלי תסמונת‬ ‫אספרגר — בודקי תוכנה מיוחדים‬ ‫אסתר צבר‬ ‫‪ 20‬הדרך הארוכה והקצרה לבניית תוכנית‬ ‫בדיקות טובה ומנוהלת אסף האוזר‬

‫מגזין‬

‫חושבים‬

‫בדיקות‬ ‫‪www.thinktesting.co.il‬‬

‫ינואר ‪ 2011‬גליון מס‘ ‪02‬‬

‫‪ 28‬בדיקות ואופטימיזציה של ביצועי‬ ‫יישום רשת נחום דימר‬ ‫‪ 31‬בחן את עצמך — ‪Exploratory Testing‬‬ ‫‪ Pairwise Testing 32‬מקסימום כיסוי‬ ‫במינימום בדיקות טלמון בן‪-‬כנען‬ ‫‪ 36‬מגמות בעולם הבדיקות —‬ ‫קיצור איטרציות הפיתוח רם יוניש‬ ‫‪ 38‬המלצה על ספר ובלוג‬ ‫איל זילברמן ויואל מונטבליסקי‬ ‫‪ 39‬מיומנו של בודק מתחיל‬

‫‪Editor: Joel Montvelisky‬‬ ‫‪Professional Committee:‬‬ ‫‪Ayal Zylberman, Ram Yonish‬‬ ‫‪and Joel Montvelisky‬‬ ‫‪Production coordinator: Ami Sterling‬‬ ‫‪Design: Red Designer Studio‬‬ ‫‪Website and free subscription:‬‬ ‫‪www.ThinkTesting.co.il‬‬ ‫‪Contact: info@ThinkTesting.co.il‬‬ ‫‪Printing: May Print‬‬ ‫‪” group on LinkedIn‬חושבים בדיקות“ ‪Join‬‬

‫עורך ראשי‪ :‬יואל מונטבליסקי‬ ‫וועדה מקצועית‪ :‬איל זילברמן‪,‬‬ ‫רם יוניש ויואל מונטבליסקי‬ ‫רכז מערכת‪ :‬עמיחי סטרלינג‬ ‫עיצוב‪ :‬סטודיו ‪Red Designer‬‬ ‫אתר והרשמה למנוי חינם‪:‬‬ ‫‪www.ThinkTesting.co.il‬‬ ‫יצירת קשר‪info@ThinkTesting.co.il :‬‬ ‫הדפסה‪ :‬דפוס מאי‬ ‫הצטרף לקבוצת המגזין ”חושבים בדיקות“‬ ‫ב‪LinkedIn-‬‬

‫מגזין חושבים בדיקות ׀ ינואר ‪ 2011‬׀ ‪3‬‬ ‫‪27-Dec-10 10:20:12 AM‬‬

‫‪ToC.indd 3‬‬


‫מגזין‬

‫ים‬ ‫חושב‬ ‫מוגת הזין‬ ‫ה‬ ‫ב‬ ‫ד‬ ‫י‬ ‫ק‬ ‫ראשון‬ ‫קות‬ ‫די‬ ‫ב‬ ‫ב‬ ‫ע‬ ‫ב‬ ‫ר‬ ‫ית‬ ‫‪www.thinktesting.co.il‬‬

‫ינואר ‪ 2011‬גליון מס‘ ‪02‬‬

‫טורים‪ ,‬בלוגים‪ ,‬ספרים‪ ,‬מידע מקצועי‪ ,‬מאמרים‪....‬‬

‫כל מה שחשוב לדעת‬ ‫בתחום הבדיקות‬

‫הפוך למנוי וקבל את העיתון עד המשרד – בחינם‪:‬‬ ‫‪www.ThinkTesting.co.il‬‬


‫מגזין‬

‫חושבים‬

‫בדיקות‬ ‫‪www.thinktesting.co.il‬‬

‫ינואר ‪ 2011‬גליון מס‘ ‪02‬‬

‫‪ 10‬הטעויות‬ ‫הנפוצות ביותר בנושא‬ ‫‪Exploratory‬‬ ‫‪Testing‬‬ ‫בדיקות‬ ‫אבטחת מידע‬ ‫לבודקי תוכנה‬

‫איך )‪(NOT‬‬ ‫לפשל‬ ‫באוטימיזציה‬

‫בדיקות‬ ‫ואופטימיזציה‬ ‫של ביצועי��� ‫יישום רשת‬

‫מקסימום‬ ‫כיסוי במינימום‬ ‫בדיקות‬

‫בחן את עצמך‬ ‫‪Exploratory‬‬ ‫‪Testing‬‬


מגזין חושבים בדיקות. גליון 2, ינואר 2011