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

למידע נוסף ותיאום פגישת היכרות:www.QualiTestGroup.com/FUNTASY [email protected]

יושב מעל רוב כלי האוטומציה כגון QTP, Test Complete ועוד

מאפשר לבודקים ידניים לתכנן ולהריץ בדיקות אוטומטיות

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

משלב בדיקות Non-GUI כגון API הרצת

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

*בתחום בדיקות האוטומציה בלבד...

FUNTASY שלך?מה ה–

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

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

לאכול שם יותר, נהייה פתאום טעים...

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

העתידיות (ואפילו חלק מהמשתמשים...).

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

כרטיסי הסיבוס שלהם.

מה קורה לי? האם איבדתי את היכולת להיות בודק? ודווקא אחרי שהרגשתי בשבועות האחרונים שהולך

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

לעיניים?

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

שמלאו לי 25?

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

מתקלות? לא מתאים לך קצת שקט בחיים?“

המנהל שלי לא חשב פעמיים וענה ”עולם בלי תקלות הוא עולם תקוע!“

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

למצוא תקלות...

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

יצאתי ליום חדש ומלא תקלות...

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

פתאום החבר‘ה מהפיתוח התחילו

לחבב אותי, וזה אחרי שלפני שבועיים

כמעט הלכנו מכות אחרי שאמרתי להם שהם מייצרים יותר

באגים משורות קוד. פתאום מצאתי את

עצמי מחמיא להם על איכות העבודה ונטולת

הבאגים שלהם.

בדיקותמעצור

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

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

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

הבדיקות.

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

פוסטים שאני אוהב במיוחד:

Perfect Sostwareand other illusions about testing Jerry Weinberg

ABAKASהמלצה על בלוג –

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

ExpectedBug Level

http://blog.abakas.com/2010/11/expected-bug-levels.html

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

ואנו חורגים מאותה נורמה.

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

ובמוצר שלהם.

They Don’t HaveTo Justify

http://blog.abakas.com/2010/10/they-dont-have-to-justify.html

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

מחליט לדחות אותו לגרסה הבאה (אם בכלל!).

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

אדם באופן עקרוני.

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

או הצדקות — “Seek confirmation of understanding, not justification”

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

באיכות ובדיקות, ובין הייתר מכסה גם ייעוץ ופסיכולוגיה.

הספר ”Perfect Software“ בא להפריך תפיסות הרסניות על בדיקות ועל בודקים. מעריצים לו הביאו אשר מדהימות ותובנות סיפורים, שנינות, של תערובת עם ברחבי העולם, וינברג מפריד במיומנות בין מה צפוי, משמעותי, ואפשרי בבדיקות

תוכנה. הוא מנפץ מיתוסים ומנווט את הקוראים הרחק מטעויות נפוצות.

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

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

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

כמה באגים במערכת?

שאל או נשאל בדיקות ומנהל בודק שכל אופייניות בשאלות מדובר בעצמו. מלבד להציע תשובות אפשרויות, וינברג מנסה להסביר מה עומד

מאחורי שאלות אלו, והכל בסגנון משעשע כהרגלו.

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

בכל פרויקט.

Book_Review.indd 38 27-Dec-10 11:14:27 AM


שרגילה לפתח מוצר / גרסה בטווח של שנה ועוברת לשיטה שבה בכל 3 שבועות מוציאים “חלקי מוצר” עובדים וגמורים לייצור.

על מנת להצליח לעמוד בלוחות זמנים קצרים כאלו המודלים האג’ילים כוללים פיתוח כגון: והבדיקות הפיתוח לייעול ושיטות טכניקות מעט לא עוד בחובם ,)ATTD( פיתוח בדיקות קבלה במקביל לפיתוח הפיצ’רים ,)TDD( מונחה בדיקותהטמעת לבדיקות, מובילה כשיטה exploratory testing ב- נכבד שימוש תהליכי אוטומציה בפיתוח ובבניית בילדים )continuous integration( והרבה

.)risk based testing( שימוש בתעדוף על בסיס ניתוח סיכונים

כיצד מודלים אלו משפיעים עליי כבודק תוכנה?המודלים האג’ילים, ו-scrum כטכניקה מובילה, למעשה משנים את התפיסה מתבצע הקצרים הזמנים לוחות בשל בנוסף, פיתוח. שלבי של הקלאסית

בדרך כלל מעט מאוד תיעוד בתהליך.

לנו כבודקים המשמעות היא שאין זמן לכתוב תכנית בדיקות או תרחישי בדיקות מפורטים ואין זמן לבצע ריגרסיות מעמיקות. במודל זה הבודקים הם חלק מצוות משימה והאחריות לאיכות התוצר היא של כל הצוות ולא רק של הבודקים )“כולם בודקים”(. בנוסף, הבודקים משתלבים בתכנון וביצוע הבדיקות למן הרגע הראשון נדרשים אנו אלו במודלים עצמו. הפיתוח ובמהלך )user story( “האפיון” של ומחוייבים לבצע הרבה יותר אוטומציה ורצוי גם ממש כחלק ממשימות הפיתוח עצמן )Test Driven Development(. לעיתים הבודקים אחראים לפתח את כלי

האוטומציה או להכשיר את המפתחים לבצע בדיקות בעצמם )ולבקר אותן(.

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

)כמעט ברמה של ראשי צוותים(.

מודלים אחרים/ עתידיים: אז מה העתיד הקרוב/ הרחוק צופן לנו?אחת המגמות המאוד ברורות, שבאה לתת מענה להתקצרות משכי הפיתוח יותר לאיכות המוצרים/ גרסאות לצוותי והבדיקות הינה העברת אחריות רבה הפיתוח והוספת משימות אוטומציה לשלבי כתיבת הקוד. כבר היום אנו רואים )TDD )test driven development, הוספת תסריטי ב- והולך גובר שימוש )continues integration( בילדים ובניית קומפילציה בתהליכי אוטומציה ותכנון תסריטי בדיקות של תהליכים עיסקיים )ATDD( כבר בשלב כתיבת הקוד

וביצוע בדיקות יחידה.

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

ובמקביל גם מוודאים שהוא מפותח בהתאם לאותן דרישות.

כיצד מודלים אלו ישפיעו עליי כבודק תוכנה?נראה יותר ויותר בודקים עם רקע ויכולות של פיתוח תוכנה. בודקים אלו יישבו

כחלק מצוותי הפיתוח ויכתבו תסריטי אוטומציה כחלק מהספרינט עצמו.

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

אוטומציה וכלי בדיקות לניהול בכלי בעיקר משתמשים בארגונים כיום אם יהיו לכל בודק 5-10 כלים “קטנים” שיסייעו לו לעשות בודד, בשנים הקרובות

לבדוק חשוב מה לאתר לו יסייעו אלו כלים יותר. ויעיל מהר הבדיקות את מאמרו )ראו בדיקה מקרי לצמצם באגים(, למצוא יותר גבוה סיכוי יש )היכן )ראו DATA לבדיקות all pairs במגזין הנוכחי(, לבנות בן כנען על של טלמון 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 החדש שנכלל בגרסת הרבה יש הזו “החבילה” שבתוך יודע למעשה HP software של QC 11מאוד יכולות, כמו לדוגמא היכולת לבצע בדיקה ידנית בקונפיגורציה מסויימת 4 סביבות שונות Win XP ,IE7( שתרוץ במקביל על עוד של המערכת )נניח mirroring שנקרא הזה החדש הפיצ’ר .)IE 8 ,9 ,FF ,chrome )לדוגמא:

מאפשר למעשה לבצע פי 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

some requirements/

back logtime box time box time box time box ...repeat as

needed

5)ד( 4)ב( 3)ד( 2)ג( 1)א( 10)ב( 9)ג( 8)ב( 7)א( 6)ב(

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

Globalization.indd 37 23-Dec-10 11:02:23 AM


מנהל פרויקט בכיר, שנחשד בציניות קלה, אמר פעם: “זה מרגיש כאילו אני תקוע בין השמרנים לבין האג’יליסטים אנחנו לא יכולים להשתמש במודלים ובפעם ,)agile( “זריז” מספיק לא זה כי שלבים, בין מעבר של מסורתיים האחרונה, כאשר ניסינו להטמיע scrum נכשלנו כישלון חרוץ. האם אין גישה

נכונה ומתאימה יותר לפרויקטים שלנו?“

במאמרה של ג’ואנה רוטמן )ראו קישור בתחתית הכתבה( היא מתארת את ההתפחות האבולציונית של מודלים למחזור חיי הפיתוח לאורך השנים. ג’ואנה מתאימות: טכניקות התפתחו מהם אחד שלכל שונים מודלים 4 מתארת

Serial model )waterfall, V model(, Iterative model )spiral(,Incremental model and Agile )scrum, xp, kanba...)

מסורתיים / מהמיושנים כרונולגי, סדר לפי מתוארים הבאים המודלים לחדשים יותר.

:(Serial) מודלים סידרתייםמחזור חיים סדרתי הוא כזה שבו כל השלבים מופיעים בסדר כרונולגי ברור. יש לסיים שלב אחד לפני שמתחיל השלב הבא )או לפחות דורשים כי אם אתה

.)N+2 יש להשלים את השלב הנוכחי בטרם יתחיל שלב ,N נמצא בשלב

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

ומתועד ברמת פירוט גבוהה.

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

המודול צריך לעשות בצורה הטובה ביותר ובשלב מוקדם.

בעיקר משתמשים איטרטיבי פיתוח חיי במחזור יתרון יש שכן startup ובחברות מוצר בחברות

ברור להציג אבטיפוס טרם התקדמות בפיתוח המוצר.

:(Incremental) ”מודלים “מצטבריםבמודלים אינקרמנטלים מפתחים את המערכת ב”חבילות”. “החבילות” יכללו בדרך כלל מודולים סגורים של המערכת, שפותחו בצורה מלאה. ככל שמייצרים

יותר מודולים כאלו המערכת שלמה יותר.

בשיטות האינקרמנטליות משך הפיתוח של כל מודול מתקצר וכולל בתוכו את כל השלבים האופייניים למודלים הסדרתיים )דרישות - אפיון – פיתוח – בדיקות(.

החסרון במודלים אלו הינו בכך שמשך בדיקות הרגרסיה המצטבר ארוך יותר חבילות לפתח כל קודם )מסיימים נכון אותם ומבצעים במידה מאידך אך ומשאירים פיצ’רים( כך אחר ורק רוחביים / תשתיתיים להיבטים הקשורות מספיק זמן לבדיקות אינטגרציה ו- E2E אזי המוצר יקבל פידבק מוקדם יותר

ויהיה מתאים יותר לצרכי הלקוח.

המודל האינקרמנטלי מעניין מאוד אבל אין הרבה חברות שמשתמשות בו, או שיש חברות שמשתמשות בו אבל קוראות לו אחרת...

:(agile) ”מודלים “אג‘יליםהמודלים האג’ילים צצו כפטריות שלאחר הגשם בעיקר על מנת לתת מענה לאתגרים של “העת החדשה” כגון הצורך בגמישות רבה מאוד וזריזות בפיתוח

ומענה לצרכי השוק.

בתוך ומוגדרים מאוד מתקצרים הפיתוח משכי )זריזים( האג’ילים במודלים time box של שבועיים עד חודש בדרך כלל. ב- scrum לדוגמא, מגדירים את רשימת הפריטים שיש לפתח )feature back log( ומתעדפים אותם. כל “צוות משימה” בוחר לעצמו את הפריטים אותם הוא מסוגל לפתח ואחראי להצלחת ביחד, המסורתיים” ה”שלבים כל את כולל ספרינט או time box כל הרכיב. כלומר,אפיון הרכיב,פיתוחו ובדיקתו, כך שבסיום הספרינט אותו רכיב למעשה

.Pre-production מוכן להטמעה בסביבת הייצור או כחלק מהמוצר בסביבת

.DSDM -ו KanBan ,Lean ,XP :כגון ,scrum קיימים מודלים נוספים מלבדעל מודלים אלו תוכלו לקרוא במאמר על “בדיקות בסביבת agile שפרסמנו

במהדורה הראשונה של המגזין באוקטובר 2010.

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

מסורתיות, ארגוני IT וחברות מהתחום הביטחוני והרפואי.

הקיבעון הוא אלו מודלים של בהטמעה הבעיות אחת שמבחינתם מנוסים בדיקות אנשי של המחשבתי “ללא מסמך אפיון לא ניתן להתחיל לבדוק”. חשוב מחברה הנדרש והשינוי הבעייתיות את להבין

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

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

(למרות שלחלק מהאנשים זה נשמע ככה).

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

בהווה ובעתיד הקרוב / רחוק.

requirements analysis design code integration test

requirementsprototype:analysis,

design, code

prototype:analysis,

design, code

prototype:analysis,

design, codeintegration test

somerequirements

analysis to choose

overall architecture

design, code,

int’ & test

design, code,

int’ & test

design, code,

int’ & test

final integration

final test

Globalization.indd 36 23-Dec-10 11:02:23 AM

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

מרוצים.

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

התמונות המצורפות מראות איך הגענו לאופטימיזציה בעזרת כלי זה.

רגע, בתיאוריה זה טוב, אבל החיים יותר מסובכים — לא לכל הצירופים יש משמעות עסקית!

נכון. ייתכן ואי אפשר לחתוך פיצה אישית ל 12 חלקים כי היא קטנה מדי.

צירופים ורק אך לייצר כך ידי ועל חוקים עסקיים, להכניס ניתן הכלים ברוב בדיקות של נוספת רשימה לייצר נרצה )אולי עסקית משמעות להם שיש

שליליות(.

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

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

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

לאינטראקציות בין הפרמטרים. לא תמיד המציאות קלה להחלפה במודל.

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

אצלנו עושים בדיקות מדגמיות ורואים שהכיסוי בסדר!מצויין! אבל ליתר בטחון, העתיקו את מקרי הבדיקה שלכם לגליון אלקטרוני,

כאשר כל פרמטר נמצא בטור משלו.

לא אם צירוף. כל מכסים בדיקה מקרי כמה לבדוק ניתן ציר טבלאות דרך תמצאו זוגות בלתי מכוסים, אתם ברי מזל....

אבל אנחנו לא בודקים פיצות, בוודאי, אנחנו רציניים! בואו ננסה להסתכל על העולם שלכם בצורה פרמטרית:

בנקים? סוגי לקוח, סוגי חשבון, היסטוריית תשלומים...

פיתוח אתר Web? סוג ה Browser, תכנת הפעלה, Plug-ins, סוג השרת...דוגמה מעולם התקשורת:

חברת תקשורת המספקת שירותי טלפון נייד, טלפון קווי, אינטרנט וטלויזיה:מערכת ההזמנות )Ordering( מעבירה את פרטי ההזמנה למערכות הטכנאים

האמורים לספק ללקוח ציוד ביתי מתאים או להחליף ציוד קיים.

3 מסלולים 3 סוגי לקוח, 12 סוגי ציוד )מפענחים, מודמים(, הבדיקות הקיפו עסקיים, 3 שיטות אספקה )על ידי טכנאי, משלוח carrier, קנייה בחנות(, שני סוגי הרכשה )מכירה או השכרה( ו 6 סוגי הזמנה )הזמנה חדשה, שינוי הזמנה,

שדרוג ועוד(.

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

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

ואצלך? השימוש בכלי מסובך? מה תכל’ס צריך לעשות בכדי להשתמש בטכניקה הזו?

מספר פעילויות פשוטות יחסית:

1. זהה את הפרמטרים והערכים והכן טבלת Excel כגון טבלת הפיצות למעלה.

.)IBM של FoCuS ב- לשימוש דוגמה )ראה לכלי הטבלה את העלה .2והכנס לכלי. )רשימת כלים אפשר לראות באתר זהה את החוקים העסקיים

)http://www.pairwise.org/tools.asp

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

4. בקש לחולל דו”ח בדיקות. התוצאה תיראה כמו תמונה מספר 3, כאשר כל שורה מתארת מקרה בדיקה יחיד.

All מבוססת בדיקה נתוני טבלת לך והנה ל”אקסל” הטבלה את ייצא .5.pairs

ביבליוגרפיה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

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

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

הערה: הוספת החוק העסקי, שלא ניתן לחתוך פיצה אישית ל 12 פלחים, מגדילה את מספר מקרי הבדיקה ל 123


Pairwise testing.indd 34 27-Dec-10 11:13:10 AM

טלמון בן-כנען

טלמון בן-כנען עובד בחברת “אמדוקס” מזה כ 10 שנים

כמנהל איכות. תפקידו הנוכחי SI- הוא מנהל איכות בגוף ה

Testing; גוף זה מונה כיום כ 1,500 אנשי בדיקות הממוקמים

ביותר מ – 30 אתרים בעולם, ומבצעים בעיקר בדיקות קבלה

עבור לקוחות “אמדוקס”.

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

תהליכי ניהול פרוייקטלי וכן שימש כמנהל תחום מדדי

התכנה ומנהל הטמעת Function Points באמדוקס.

יכולים אתם אתכם, מעניינת לא האחרונה ההצעה אם לעבור לקרוא את המאמר הבא.

כמה מקרי בדיקה ייתנו לנו בטחון שחישוב המחיר מדוייק, ולוודא שההוראות שאנו שולחים לקו היצור מכסות את מה

שנדרש?

רשום כאן את הערכתך לפני שאתה ממשיך לקרוא: _____

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

לכל הפיצה )המחיר נמוך יותר מאשר פעמיים חצי פיצה(.

שלושה של תוצאה יהיה שגיאות של יותר קטן אחוז צירופים או יותר.

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

של כשלים.

“פיצה פיצוץ” — כמה מקרי בדיקה נדרשים? בדיקות כמה אפשרויות. 175,000 לכ- הגענו זוכרים?

נדרשות לכיסוי כל הזוגות? השלשות? הרביעיות?

122 מקרי בדיקה מכסים את כל הצירופים הזוגיים;623 מקרי בדיקה מכסים את כל השלישיות;

לא מספיק? רוצים לכסות כל רביעיה אפשרית? אין בעייה. כמות מקרי הבדיקה היא 2,859.

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

בדיקה.

5431111423

גודל הפיצה

סוג הבצק

תוספת גבינה

תוספות,חצי פיצה

תוספות, חצי פיצה

חיתוךאפייהרוטב

6 פלחיםרגילהללאללאללאללאעבה ופריך, ענקית

8 פלחיםWell Doneרגילפפרוני פפרוני עם תוספתעבה ורך משפחתי גדול

12 פלחיםחריףזיתים ירוקיםזיתים ירוקים4 גבינותדק ופריך משפחתי קטן

מתקתקזיתים שחוריםזיתים שחוריםדק ורךבינונית

חציליםחציליםאישית

פטריותפטריות

פלפל קלויפלפל קלוי

בצל טריבצל טרי

בצל מטוגןבצל מטוגן

תירסתירס

אנשוביאנשובי

השאלה הנדונה בהמשך הינה בעניין של כיסוי נאות:

כמה מקרי בדיקה נדרשים למערך בדיקות אפקטיבי?

מקסימו כיסוי

במינימו בדיקותPairwise

Testing

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



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

אותה ומעבירים לדואר שליחים מהיר ויעיל.

מקווים עדיין )אנחנו ההזמנות תוכנת את לבדוק הוטל עלינו לזכות גם במכרז הבדיקות לקו-היצור(. האתר המהודר של “פיצה תוכנת שלו, הפיצה מרכיבי את לבחור ללקוח מאפשר פיצוץ” ההזמנות מחשבת את המחיר, גובה את התשלום ושולחת הוראות שהמחיר לוודא עלינו במפעל. הרובוטיות למערכות ממוחשבות מחושב נכון, וכן שהוראות הייצור נשלחות ללא שגיאה לכל מרכיבי

הייצור.

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

יש מחיר משלו:משפחתית גדולה, משפחתית )ענקית, הפיצה גודל בחירת

קטנה, בינונית, אישית( סוג הבצק )עבה ופריך, עבה ורך, דק ופריך, דק ורך(

אפשרות לתוספת גבינה צהובה או ל ”4 גבינות”תוספות, שתי או הפיצה, לכל להיות יכולה התוספת תוספות: זיתים )פפרוני, 10 תוספות כולל פיצה. המבחר לכל חצי אחת זיתים שחורים, חצילים, פטריות, פלפל קלוי, בצל טרי, ירוקים,

בצל מטוגן, תירס, אנשובי( או ללא כל תוספת. רוטב: רגיל, חריף, מתקתק, ללא רוטב

Well Done אפייה רגילה או חיתוך ל 6, 8 או 12 פלחים

כמות )כמה פיצות(

מעבר או נוספת, הזמנה או להתחלה, חזרה ההזמנה: המשך לאמצעי התשלום.

לצופה מוצגת הסופי המחיר הצגת ולפני הבחירה תהליך בסיום הרעב תמונה מעוררת תאבון.

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

)להזכיר: הדרישות יכסו את בדיקה מקרי כמה לחשב ננסה הבה לכל אפשרות מחיר אחר והוראות אחרות למערך הייצור(.

כמות את מראים ממול, שבעמוד הטבלה שבראש המספרים הערכים לכל פרמטר.

סך כל האפשרויות: 5x4x3x11x11x4x2x3=174,240

האם נבצע מעל 170 אלף מקרי בדיקה? ואם לא, כמה מקרי בדיקה יתנו כיסוי נאות? 400 יספיקו? אולי 4,000? אולי 40,000?

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

אולי נבדוק הכל; הלקוח יהיה מה זה מרוצה, ויש לנו שישי שבת את יידחה שלנו שהלקוח נבקש אולי לנו; שיעזור ואח ולילה

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

אז בואו נבחר 1,000 ונקווה שיהיה טוב. בואו נייצר רשימה של כל מקרי הבדיקות ונעשה כמה שנספיק.

בואו נחפש פטנט אחר: מינימום מקרי בדיקה במקסימום כיסוי.

השאלה הנדונה בהמשך הינה בעניין של כיסוי נאות:

כמה מקרי בדיקה נדרשים למערך בדיקות אפקטיבי?

מקסימו כיסוי

במינימו בדיקותPairwise

Testing



בחן את עצמך

6?ET מתי כדאי לעשותא. כאשר המערכת הנבדקת היא פשוטה יחסית

ב. עבור כל ארגון וכל מערכתג. בבדיקת מערכות לא קריטיות

ד. רק בארגונים בהם אין מסמכי אפיון טובים

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

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

1

מי מהאנשים הבאים אינו נחשב חסיד 7?ET-של גישת ה

Martin Pol .אJames Bach .בCem Kaner .ג

Michael Bolton .ד

היתרון העיקרי ב-ET הוא2א. כיף יותר מהרצת תסריטי בדיקות מוכנים

ב. מאפשר ”למלא את הזמן“ אחרי סיום הרצת בדיקותג. מאפשר למצוא יותר באגים בפרק זמן נתון

ד. חוסך זמן של תכנון בדיקות

מה הבעיה העיקרית בגישת בדיקות מונחית 8?(Scripted Testing) תסריטים

א. לא מאפשרת מציאת הרבה באגיםב. לא מאפשרת חופש פעולה לבודק תוך כדי הרצת בדיקות

ג. דורשת הרבה מסמכיםד. אינה מאפשרת בדיקות של מצבי קצה

אילו מהמשפטים הבאים אינו נכון?3א. ET מספקת לבודק חופש פעולה בביצוע בדיקות

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

ד. ET אינו מאפשר בקרה על הבדיקות

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

א. כןב. כן בתנאי שהבודק חוקר המערכת תוך כדי הרצה

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

מה ההגדרה המדוייקת ביותר עבור 4?Test Session

א. מסמך המסכם הבדיקות שבוצעו ע“י הבודקב. מקטע באורך 90 דקות בו הבודק נדרש לבדוק נושא מסוים

ג. חלק הבדיקות המתמקד בביצוע בדיקות קצהET שלב ההרצה של בדיקות

10?ET מהם המקורות עליהם מסתמכים בביצועא. אפיון המערכת

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

ג. חקירת המערכת הנבדקתד. ניתוח אופן השימוש במערכת ע“י המשתמשים

5?ET אילו תכונות נדרשות לבודקא. יכולת דיווח טובה

ב. יכולת לחקור ולהבין המערכת באמצעות שימוש בהג. יכולת לקרוא ולהבין מסמכי אפיון

ד. כל התשובות נכונות

התשובות הנכונות נמצאות בעמוד 37!

Exploratory Testing (ET)

גלה האם אתה בודק ET מקצועי או...(הציון בהתאם לכמות התשובות הנכונות שענית)

0-3 איך לומר זאת בעדינות? אין לך מושג! אפילו מבחינה סטטסטית — אם היית מסמן תשובה אחת זהה בכל השאלון — היית מקבל ציון גבוה

יותר. ממש כישרון...

4-6 תפתח את עמוד 6 בגליון שאתה מחזיק. יש לך עוד לא מעט ללמוד בתחום.

לביצוע מוכן ואתה בהחלט תהיה Exploratory עוד קצת 7-8 תראה, Testing. לא רע!

9-10 קודם כל, אנחנו שמחים לראות שהתפנית לכמה דקות מלקרוא מאמרים ולבצע בדיקות בשביל לענות על השאלון הזה. חוץ מזה, נשמח

אם תכתוב משהו עבור הגליון הבא של ”חושבים בדיקות“.


Test_Yourself.indd 31 27-Dec-10 11:10:30 AM

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

.(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) קיבול בתכנון גם

בטוחים לעלויות התשתית.

10 – Conn. Starvation

100 – Apache Limit

500 – Slow DB Queries

1000 – Code, Search, Cache

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

page 1

041 042 043

page 2 page 3 page 4

data

Page

sAp

p. B

ack-

End

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


Yesumim.indd 30 27-Dec-10 11:07:54 AM

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

העליה הדרמטית בפעילות המשתמשים במהלך יום פרסום התוצאות.

שיא הפעילות נרשם בין השעות 8:00 ל 11:00 בבוקר ביום פרסום התוצאות. לפניכם מספר נתונים מספריים:

בסיס הנתונים מונה יותר מ 100 מיליון רשומות 10 מיליון רשומות פעילות

70,000 משתמשים עומס של פחות מ 10 דפים / דקה ביום רגיל

שיא של 300 דפים / דקה ביום פרסום התוצאות

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

שרתים, ”הגרסה הקלה“ צריכה לכלול שרת יחיד עבור כל שכבה בצבר, ולהתאים למפרטי החומרה והתוכנה שבסביבת הייצור האמיתית. גישה זו מודגמת באיור 2.

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

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

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

היה ”בדיקת התוצאות של תלמיד מסוים“. התרחיש כלל את הפעולות הבאות:

1. היכנס למערכת2. מצא בחינה

3. בדוק תוצאות עבור תלמיד מסוים4. צא מן המערכת

נחום דימרנחום דימר הינו יזם IT ומנכ“ל

TEST4LOAD, ספק מוביל של בדיקות עומסים ושירותי

אופטימיזצית ביצועים. מר דימר מעורב בפיתוח, בדיקות

וניהול של מגוון פרוייקטים בתחום תוכנה ומערכות

ארגוניות. יש לו ניסיון עשיר ורקע טכנולוגי מעמיק במגוון

תחומים הכולל תוכנות וביצועים הנדסה, וכן אבטחת איכות של מערכות אינטרנט

וטלקום.

TEST4LOAD עוזר לתכנן, ליישם, לבדוק ולמטב היבטים

ביצועים של מערכות תוכנה מרובת משתמשים. בין לקוחות החברה נמנים חברות מובילות

מהארץ ומהעולם.

3000

2500

2000

1500

1000

500

0

00:0

001

:00

02:0

003

:00

04:0

005

:00

06:0

007

:00

08:0

009

:00

10:0

011

:00

12:0

013

:00

14:0

015

:00

16:0

017

:00

18:0

019

:00

20:0

021

:00

22:0

023

:00

24:0

0

22/08/2007

Requests per

10 minutes

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

איור 1. שיאי פעילות משתמשים ביום פרסום התוצאות



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

באיתור עיכובים בביצועי התוכנה.

אבטחת ביצועים, בדיקות עומסים, בדיקות תוכנה, ביצועי מפתח: מילות .(Performance Engineering) איכות התוכנה, הנדסת ביצועים

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

תת-קבוצה ומנגנון אימות מרכזיים של הנדסת ביצועי תוכנה.

בדיקת ביצועים - מהי?בתוכנה, הצפוי השימוש למידול כללי באופן מתייחסת ביצועים בדיקת שרותי אל רבים משתמשים של בו-זמנית גישה של סימולציה באמצעות התוכנה. בדרך כלל שירותים אלה מקבילים למקרי השימוש (use case) או

לתהליכים העסקיים של המערכת, ומכונים תרחישי בדיקה.

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

אלקטרוני, וכו‘.

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

צצות במציאות. ישנן סיבות רבות לבצע בדיקות, אך המניעים העיקריים הם:

מניעת כשלים עתירי-עלות ביישום קריטי סימולציה של עומס העבודה במציאות

מציאת גבולות היכולת של המערכת שלך איתור בעיות פוטנציאליות לפני שיעשה זאת הלקוח

(TTM) קיצור מחזור הפיתוח וזמן היציאה לשוק חיזוי של עלויות תשתית והקטנתן

(SLA) הבטחת הסכם רמת השרות

מקרה הבוחןרקע

הגופים שלושת מבין הגדולה היא (AQA) ולהסמכה להערכה האגודה GCSE ברמת הבגרות מתעודות 49% המעניקה היא באנגליה: המעריכים יותר (A-level). בסך הכל האגודה בוחנת 42% מהבגרויות ברמה הגבוהה ו-

מ- 3.5 מליון תלמידים מדי שנה.

לגשת למורים המאפשר גדול מידה בקנה אקסטרה-נט אתר פיתחה AQAשל מיידי ניתוח ולראות שלהם לאוניברסיטה או הספר לבית ייחודי למידע

תוצאות המבחנים.

הפופולאריות הגוברת של יישומי רשת והגידול במספר המשתמשים

הפוטנציאליים ביישומי רשת מהווים אתגר למהנדסי מערכות, למפתחים

ולבודקים. עם הגידול במהירות הגלישה, משתמשים אינם מוכנים עוד להשלים עם מהירות תגובה איטית או כשל של היישום.

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

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

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

הביצועים בחשבון יכול להיות גבוה ביותר. מקרה הבוחן יתאר תהליך בדיקה

ואופטימיזציה של יישום רשת בקנה מידה גדול. הדוגמאות תוספנה תובנה על אילוצי

המציאות, הקשיים, האתגרים ועבודת הצוות. מקרה הבוחן מכוון אל מתחילים

ומומחים, ואל צוות ניהולי וטכני כאחד.

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

יישום רשתשל ביצועי

בדיקה ואופטימיזציה

בדיקה

מקרה בוחן



LET’S DO AMAZING

פיתוח יישומים מתקדמים לתוצאות עסקיות

טובות יותר.

HP פתרונות התוכנה החדשים שלתוכננו על מנת לשפר:

< איכות< יכולת ניבוי

< מוכנות לשינויים

פרטים על הגרסה החדשה של

:HP Applications Solutions www.hp.co.il/alm

עלויות נמוכות יותר. גמישות גבוהה יותר.

איכות טובה יותר. www.hp.com/go/alm

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

בביטחון שהכלי הנבחר הוא המתאים ביותר למשימה.

הנהלה vs אוטומציהמלאי תשוקה והתלהבות אודות בדיקות אוטומטיות אנו משכנעים את ההנהלה על ההחזר כי מבטיחים אנו אוטומטיות, בבדיקות להשקיע וכדאי שחשוב

ההשקעה יהיה מיידי: בדיקות הרגרסיה המתישות והמעיקות יכוסו על ידי המכונות האוטומטיות,

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

אפס עלות לחברה

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

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

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

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

מבינים שהבעיה היא שלנו בלבד. הבטחנו אוטומציה, חובה עלינו לקיים.

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

לבסוף, ותחזיר את ההשקעה.

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

והחזר מיידי של ההשקעה. מטבענו, אנחנו רוצים לראות הצלחה, ומהר.

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

ביישום מוצלח של כל פרוייקט פיתוח, ובכלל זה של פרוייקטי אוטומציה.

קישורים מומלצים: Watir – http://www.watir.comWatiN – http://watin.sourceforge.netSelenium – http://www.seleniumhq.orgSTAF – http://staf.sourceforge.netAutoIT – http://www.autoitscript.comSubversion – http://subversion.apache.orgQA Forums – http://www.qaforums.comAdvanced QTP – http://www.advancedqtp.com

ב די קותמגזין חושב ים

גם אם אין לכך ניסיון בכתיבה או אם אתה מתקשה לבטא הרעיון שלך בכתב, אנחנו כאן לעזור!

כותבים המעונינים לקחת חלק בכתיבה עבור הגליונות הבאים [email protected] :מוזמנים ליצור קשר

www.ThinkTesting.co.il

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

איך (NOT) לפשל באוטומציה

ק די קק די ק די די קקוותת בב חומגזין חומגזין חושבים

גם אם אין לכך ניסיון בכתיבה או אם אתה מתקשה לבטא

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

Optimisation (NOT).indd 26 27-Dec-10 11:00:21 AM


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

באוטומציה, ומצד שני ממשיכים להריץ בדיקות ידניות...

אז מה הפתרון שאנו מציעים?על מנת לבצע הערכות ריאליות יותר, ולעמוד בהם מומלץ ביותר:

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

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

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

הזמנים של הפרוייקט כולו. ROI( הפרוייקט של תפוקה – ההשקעה יחס את לחשב Return On Investment(. במידה ואת התרחיש המועמד מריצים רק פעמיים בשנה לדוגמה, האוטומציה שלו אמורה להתבצע מהר מאוד, אחרת ההשקעה תהפוך להיות מאוד

לא כלכלית על פני חלופה של המשך ביצוע בצורה ידנית.פיתוח מפרויקט להבדיל – האוטומטי הקוד של תחזוקה תוכנה, פיתוח אוטומציה, במיוחד בשכבה העליונה של מנשק תוכנה שינויי זמן. לאורך יקרה תחזוקה דורשת המשתמש, המצריך דבר האוטומציה, של עקביות התאמות דורשים והיכולת המשאבים בידך יש האם יקרים. תחזוקה משאבי

לתחזק ולשמר את קוד האוטומציה לאורך חיי התוכנה?

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

עלינו לדאוג שהרובוט לא מצפה שנמשיך להחזיק את ידו.

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

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

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

התחלנו, רק כי לא הושקעה מחשבה מעמיקה בנושא.

לפיכך, השקעה מקדימה, אשר לעתים הינה ארוכה ומגייעת, הכרחית להצלחה.

אז מה הפתרון שאנו מציעים?להלן מספר שאלות, התשובות עליהן עשויות לעזור לך מאוד

בצמצום האפשרויות והכוונה בבחירת הכלי הראוי: IBM Rational האם יש בידך תקציב לכלי מסחרי כדוגמת כלי מבוסס או שאתה מחויב בבחירת HP QTP או Test

?WATIR או Selenium קוד פתוח כגוןמי יהיו מפתחי האוטומציה? האם יש ביכולתם לפתח ולהרחיב

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

לאטמט דפדנים שונים, אינטגרציה למערכות קיימות.האם האפליקציה אותה אתה שואף לאטמט משתמשת לדוגמא למוצר? ייחודית או סטנדרטית בטכנולוגיה מזוהה אשר פנימית פיתוח פרי Java Applet איטמוט כקופסא שחורה לכלי האוטמציה, ללא יכולת זיהוי ותפעול

מנשק התוכנה.בצורה וניגונו סקריפט שהקלטת מאמין אתה האם

אוטומטית תעבוד? )רמז: היא לא...(מהי רמת התמיכה הטכנית המסופקת על ידי יצרן התוכנה

/ קהילת הפיתוח?

המחקר שלב מגיע האפשרויות מספר צמצום לאחר של )POC = Proof Of Concept( ההיתכנות ובדיקת בלימוד ראשית, מאופיין, זה שלב המוצעים. הכלים וחקירת יכולותיו, ייתרונותיו ומגבלותיו של כל כלי. הקדש וטובים שרבים ובטוח סמוך היה הכלים. ללימוד זמן שיטוט המוצעים. הפתרונות את וניסו חקרו בדקו, כבר בלוגים של מומחים בתחום רלוונטים, קריאת בפורומים בפז. יסולא שלא נכס הם בנושא מקצועיים ואתרים השלב השני, והחשוב ביותר, הוא בדיקת היתכנות, בחר ואטמט )רצוי לא פשוט( באפלקיציה שלך נפוץ תסריט אין שלך. הפיינליסטים הכלים כל עם זאת בצע אותו. המכשולים האתגרים הקשיים, בידיים. ללמידה תחליף

וההצלחות עם כל כלי יעזרו לך מאוד בבחירה.

אסף סעראסף סער עוסק בתחום בדיקות התוכנה

מזה 14 שנה. לאסף נסיון רב בניהול בדיקות תוכנה בחברות בינלאומיות,

בינוניות וקטנות בארץ ובארה”ב. במהלך השנים אסף הקים קבוצות בדיקות, ניהל

פרוייקטי תוכנה, פיתח ויישם תשתיות בדיקות והטמעת פרוייקטי אוטומציה

בחברות השונות. Labs מזה 4 שנים אסף עובד בחברת

SAP ברעננה, בתפקידו הנוכחי הינו מנהל Quality Engineering SAP קבוצת

Portals העוסקת בבדיקות פונקציונליות, בדיקות ביצועים, פיתוח ויישום תשתיות

אוטומציה תומכות תהליכי פיתוח בחברה. אסף נשוי למירב, אב לשלושה ילדים

ומתגורר בתל מונד.http://www.asaf.co.il הבלוג של אסף

ערן נלינגרערן נלינגר הצטרף לקבוצת הבטחת

האיכות של SAP Labs ישראל כסטודנט להנדסה )אוניברסיטת בן גוריון(, בתוכנית

לסטודנטים מצטיינים בשנת 2005.לאחר תפקידי בדיקות שונים בתחומי

הבדיקות הידניות, האוטומטיות ומבוססות הקוד, ערן בנה והוביל צוות SDK חדש שפיתח תשתית לבדיקות

.J2EE בסביבתכיום ערן מוביל פרוייקט פיתוח של

תשתית אוטומציה הנותנת מענה ל- 6 פרוייקטי תוכנה המפותחים במעבדה,

וכולל פתרונות אוטומטיים לבדיקות ,Performance פונקציונאליות, בדיקות

ואלמנטים נוספים במחזור חיי התוכנה.

ערן נשוי לקרולינה ומתגורר בכפר-יונה.

מאת ערן נלינגר ואסף סער .http://wwwאיך )NOT( לפשל באוטומציה



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

המלצות והצעות בדרך ליישום מוצלח.

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

כאל התוכנה שיש לפתח.

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

תחום עולה, שנמצא ללא ספק לפני שיא או מיצוי.

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

ויותר ממהנדס אחד )או יותר מתחנת עבודה אחת( מטפל באוטומציה.

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

במהרה לכישלון של פרוייקט אוטומציה.

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

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

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

הנדרשים על מנת להצליח בתפקיד זה?

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

למעשה קשה מאוד למצוא מהנדסים כאלו.

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

שיוצאים לדרך? האם הוקצה מספיק זמן לחניכה?

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

רצוף להפוך את המהנדס למקצוען בתחום.

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

פורמאלי לאוטומטי. המשתנה היחיד הוא כמות המשאבים המושקעת בדבר.

כבודקי תוכנה מנוסים, למדנו ושמענו כי בדיקות אוטומטיות יכולות להיות הפתרון להרבה מבעיות היום-יום שלנו, בין אם מדובר בביצוע בדיקות חוזרות ונשנות של תסריטי הרגרסיה, בלוחות עמידה או הבדיקות מטריצת של הגיוני לא כיסוי צצים חדשים אוטומציה וכלי תשתיות סבירים. לא זמנים כמו פטריות אחרי הגשם. אנו למדים כי בדיקות אוטומטיות הן חלק בסיסי ויסודי במתודולוגיות Lean ו- Scrum, כנסים מקצועיים בהם אנו נוכחים עמוסים לעייפה בסיפורי הצלחה של הטמעות אוטומציה ועוד. אנחנו משוכנעים: אם זה עובד

עבורם, זה חייב לעבוד גם לנו!

איך )NOT( לפשל


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

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

ה מ י ד ק ת ל כ ת ס מ ה ש ח מ ת ת מ ו ק י ד ב ת ר ב ח ב ד ו ב ע לומרתקים ומרחיבה את שרותיה לעולמות חדשים

חדשנות, מובילות, יצירתיות

DWH -ו BI עולם בדיקות

Quality Gates - כלי ייחודי לבדיקות נתוניםבדיקות אוטומטיות וידניות למגוון מערכות

- כלי ייחודי לבדיקות נתונים Quality Gatesבדיקות אוטומטיות וידניות למגוון מערכות

DWH ו- BI עולם בדיקות

כלי ייחודי לבדיקות נתונים Quality Gates

SAAS בדיקות ביצועים ועומסים במודל

SAAS בדיקות אוטומציה במודל

SAAS בדיקות ביצועים ועומסים במודל

SAAS בדיקות אוטומציה במודל

cloud-עולם הבדיקות ב

Penetration TestingSecurity Auditing & Scanning

Penetration TestingSecurity Auditing & Scanning

Penetration Testing

עולם בדיקות אבטחת מידע

מגוון מכשירים ניידים במקום אחד

שימוש בסימולטורים ואוטומציה

עולם הבדיקות למובייל

מגוון מכשירים ניידים במקום אחד

שימוש בסימולטורים ואוטומציה

עולם הבדיקות למובייל

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

האם הם מקבלים הכרה מקצועית?

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

מקצועיות.

ארגון ומאושרת של מוכרת הינו שלוחה ITCB ארגון 2004 החל מאפריל ITCB בינלאומית בתחום הבדיקות. חברי ארגון ISTQB המעניק הסמכה השונות והעשייה ההיגוי בוועדות ומשפיע פעיל חלק לוקחים הישראלי

ISTQB בארגון הבינלאומי. עד כה, הוסמכו למעלה מ- 160,000 מוסמכים בברחבי העולם ולמעלה מ- 2100 בארץ.

בישראל“, המופעלת ברציפות מאז שנת ”מצוינות בתחום הבדיקות תחרות ו-SIGiST ישראל, נועדה להעניק הכרה לבודקים מקצועיים ITCB 2008 ע“י אשר תרמו תרומה משמעותית לתחום בדיקות התוכנה בישראל. התחרות באה

לקדם מנהיגות, תרומה ואפקטיביות בתהליכי בדיקות והטמעת בדיקות.

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

פועלם של המועמדים הסופיים ושל הזוכים, שלום מיץ ואבי פרוכטר.

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

בצד האפליקציה.

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

את הבדיקות על המערכות הרלוונטיות. המערכת אוספת מידע על בדיקות שנכשלו ושולחת דו“חות לאנשים המתאימים.

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

תוך שינוי צורת המחשבה של האנשים. כך, כל פרויקט חדש כולל דרישות ליכולות בדיקה ואוטומציה של המערכת.

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

הבדיקות האוטומטיות שביצעו לקוחות שהשתמשו בכלי.

כיום משתמשים בכלי כ-20 מלקוחותיה הגדולים של NDS לצורך בדיקות טרום הכנסת מערכות חדשות. 50% וכיום מעל בו נוספים בחברה משתמשים בדיקות גופי הכלי, וההרחבה של עקב קלות התחזוקה

מפעילות הבדיקות בחברה נעשות בעזרת הכלי.

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

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

לצורך בדיקות טרום הכנסת מערכות חדשות. לצורך בדיקות טרום הכנסת מערכות חדשות. לצורך בדיקות טרום הכנסת מערכות חדשות. לצורך בדיקות טרום הכנסת מערכות חדשות. 50%50%

אחת מקבוצות הבדיקה דיווחה על אוטומציה של בדיקות ביצועים שלא ניתן להריץ בצורה ידנית, והגיע

1

תחרות ”הצטיינות ישראלית בתחום הבדיקות“ ITCB של

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


ITCB.indd 22 27-Dec-10 11:01:55 AM

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

לניהול בדיקות ניתן להבדיל בין תסריטים ריקים ותסריטים עם צעדי בדיקות(.

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

בעת כתיבת הדרישות לבדיקה, גם אם הן נכתבות ע”י הבודק, יש לכתוב ולהקפיד על מספר כללים:

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

וידוא יכולת לבדיקת הדרישה או הוספת דרישה ליכולת זו. אישור הדרישות כפי שנכתבו מול הגורם המפתח / מאשר לפני תחילת

התכנון המפורט של הבדיקות.

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

חלוקת תסריטי הבדיקות לתסריטים בעלי 5-10 צעדי בדיקה לכל היותר )ברור שיש מקרים יוצאים מן הכלל..( כדי לאפשר יכולת ניהול טובה יותר

לריצות התסריטים בהמשך. רצוי שתסריט בדיקות יהיה ממוקד במטרה ספיציפית וברורה כגון אימות

ספציפי של פונקציה או דרישת מערכת. כדאי לוודא שלכל תסריט יש 3 צעדי בדיקה לכל הפחות:

ניתן )לחילופין בתסריט ראשון כצעד התסריט להרצת מקדים - תנאי להוסיפו לתיאור הכללי של תסריט הבדיקות עצמו(.

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

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

ושילוב בתסריטים אחרים. רצוי לאמץ שפה אחידה לכתיבת צעדי הבדיקות בתסריטים בלשון ציווי

)לחץ על... הקלד את... וכו’ וכו’(.נבדקת פעולה כל עבור נפרד בדיקה צעד כתיבת על להקפיד רצוי

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

)לדוגמא: שרת / מכונה / “ברזל” או שמות מושגים בעברית / אנגלית( כדאי לוודא שתסריט הבדיקות מתאים ליכולות בודקי המערכת והסביבה

בה נבדקת המערכת.יש להקפיד על עקיבות תסריטי הבדיקות ולוודא שתסריט בדיקות יהיה

קשור ויכסה דרישה אחת לבדיקה או יותר.

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

הקשר לוגי כלשהו שמתאים לכל ארגון או מערכת, לדוגמא: לפי מודולים במערכת

לפי סוגי בדיקות לפי חלוקה לבודקים

לפי סדר עדיפות לפי שילובים שונים משונים ואחרים

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

נושא/ איזור מסיום במערכת כאשר לוחות הזמנים צפופים ולוחצים כתמיד.

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

תקלה דומה במידה ועדיין תהיה קיימת.

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

הסיכויים לכך שלא נפספס תקלות שכבר גילינו בסבבים קודמים.

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

לתוכנית ריצות הבדיקה, להריצו ולפתוח את התקלה מתוך ריצת התסריט.

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

ניהול שינויים ותחזוקת תוכנית הבדיקותהחיים האמיתיים של תוכנית הבדיקות מתחילים למעשה מיד לאחר השלמת

הקמתה ו”עלייתה לאויר” לסבב הבדיקות הראשון.

מאותו רגע ואילך תוכנית הבדיקות תשתנה ותותאם למציאות המשתנה של המערכת הנבדקת.

תוכנית בדיקות תשמש תמיד כבסיס לניהול הידע המצטבר על המערכת הנבדקת וכל שינוי והתאמה יתחילו מדרישה מסוימת:

במידה ומדובר בדרישה חדשה למערכת, כדאי לוודא שאין דרישות דומות או כבסיס קיימים בדיקות בתסריט להשתמש אולי שניתן מקבילות או

כחלק מבדיקת הדרישה.לוודא שתסריטי הבדיקות קיימת, חובה ומדובר בשינוי לדרישה במידה וכמובן לשינויים בהתאמה אותם ולשנות ונכונים רלוונטיים הקיימים

להוסיף תסריטים חדשים ואולי לגרוע תסריטים מסוימים.

בניהול שתתמוך בדיקות לניהול מערכת דורשות שהוזכרו הפעולות כל גרסאות רוחבי ומותנה בכך שניתן יהיה לחזור לגרסאות קודמות של דרישות

ותסריטי הבדיקות.

על לחשוב ניתן שינויים ניהול יכולות אין הבדיקות ניהול ולמערכת במידה פתרונות אחרים )החל משכפולים ועד מעבר למערכת טובה יותר...(.

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

מדידת יעילות ואפקטיביות תוכנית הבדיקותהמידע את להציף הבדיקות, ניהול מערכת נתוני של מדידות לבצע מומלץ

ולהסיק מסקנות.

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

תסריטי בדיקות לעומת כלל התסריטים שהורצו ועוד ועוד.

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

נתונים פשוטות מעין אלו.

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

המושלמת בפעם הראשונה ומשתפרים מגירסה לגירסה.

ידע, ניהול כמערכת שתשמש בדיקות מערכת לנו תהיה התהליך, בסיום הארגון של הבדיקות נכסי את ובעתיד בהווה ממנה לשלוף יהיה שניתן כנדרש ובנוסף ניתן יהיה למנוע כתיבת תסריטים מיותרת ולנהל את השימוש

החוזר )Reuse( בנכסי הבדיקות הקיימים בארגון בצורה מיטבית.


Test_Planing.indd 21 27-Dec-10 10:53:19 AM

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

אחלץ את מיטב העצות והטיפים לבניית תוכנית בדיקות מנוהלת וטובה.

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

קיצורי דרך ראויים.

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

שניים.

מהי בכלל תוכנית בדיקות טובה איכותית ומנוהלת?טובה בצורה אותן להגדיר מאוד כדאי בחיים, מטרות להשיג רוצים כאשר

וברורה מראש.

המערכת לקוחות דרישות את “לכסות” צריכה טובה בדיקות תוכנית .)Verification( וגם חלקים מהאפיון המפורט )Validation(

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

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

)שימוש חוזר(. יכולת ניהול שינויים והתאמת תוכנית הבדיקות לאורך חיי המערכת הינה

פרמטר חשוב ביותר וראוי להתייחסות רצינית.

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

הקמה וניהול של תוכנית בדיקותהקמת הוא ומנוהלת טובה בדיקות תוכנית הקמת להתחלת מקדים תנאי

תשתית ראויה ונוחה לניהול שוטף של עבודתם היומית של בודקי המערכת.

בשוק )Test Management( בדיקות לניהול מערכות מעט לא קיימות הנבדקת המערכת דרישות למול הבדיקות לניהול היכולת את שמספקות

:ISTQB ולמול דרישות נוספות לבדיקה. במאמר אשתמש מעט במושגיTR (Test Rule( — כללים לבדיקה או למעשה דרישות לבדיקה.

TC (Test Case( — מקרים לבדיקה או למעשה תסריטי הבדיקות.

כמסגרת שישמשו TRים וניהול באיסוף תתחיל טובה בדיקות תוכנית כל לכתיבת תסריטי הבדיקות. איסוף הTRים יהווה כלי נהדר לניהול כיסוי המערכת בתסריטי בדיקות ויסייע לניהול כיסוי ריצות הבדיקה למול המערכת הנבדקת

.(Test Coverage Analysis(

וניתן שלה האיפיון או הנבדקת המערכת דרישות את נקבל הטוב, במקרה HP Quality )לדוגמא מערכת לתוך שהתקבלו הדרישות את להקליד יהיה

Center) או לייצא אותן מאופיס לתוך המערכת.

במקרה טוב יותר ובהיעדר מערכת לניהול דרישות, נצליח לשכנע את מנהל המוצר / מנתח המערכת לעבור לשימוש במערכת הבדיקות לניהול דרישות המערכת עצמן.

אבל, אם נחזור למציאות, כנראה שנצטרך לבצע בעצמנו פירוק פונקציאנלי את לנהל ובהמשך הנבדקת המערכת של (Functional Breakdown(השינויים והתוספות לאורך חיי המערכת הנבדקת, ללא ספק המאמץ הראשוני

ישתלם לנו בהמשך.

כאמור בפרק הקודם, מומלץ לשלב ולהוסיף דרישות נוספות לבדיקה הנובעות מהידע והערך המוסף של הבודקים עצמם.

ישנן מערכות לניהול בדיקות )לדוגמא HP Quality Center) אשר מאפשרות ולמעשה (Release Management( לבדיקה התכולות ניהול היום כבר

מייצרות מבטים וחיתוכים על פי שיוך ל-Release זה או אחר.

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

לא תמיד נזכור את ההקשר לכותרת התסריט.

העץ את לבנות וניתן בתסריטים הבדיקות עץ את למלא התחלנו כאמור, כהעתק של עץ הדרישות אבל בדרך כלל אמליץ לנצל את יכולות המערכות הקיימות בשוק ו”להרויח” מימד נוסף כמו חלוקה לרמות בדיקה, לסוגי בדיקה (Link( לקשור יכולת הבדיקות ניהול למערכת שיש בהנחה זאת כל וכו’, ולנהל את הקשר הזה בצורה חכמה )TCים( )TRים( לתסריטים בין דרישות

ולמעשה לנהל את הידע לטובת הבודקים.

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

תחילת פירוט התסריטים.

בהנחה שסיימנו למלא את עץ הבדיקות בתסריטים, קישרנו את התסריטים לדרישות, להערותיו, אפשר להתחיל במשימה והתייחסנו הגורם המפתח אישור קיבלנו את

הדרך הארוכה והקצרהאסף האוזר

אסף האוזר עוסק בתחום איכות ובדיקות תוכנה מעל ל-13 שנה.

יועץ עצמאי ומרצה לבדיקות תוכנה, HP Quality Center-מוכר כמומחה לולמתודולוגיות ALM, בשנים האחרונות

משמש כמנהל תשתיות לבדיקות באחד מהמוסדות הפיננסיים הגדולים במדינה.

ניתן ליצור קשר עם אסף באתר:www.qaconsultant.co.il

לבניית תוכנית בדיקות טובה

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

מנוהלת לבדיקות תוכנה.


Test_Planing.indd 20 27-Dec-10 10:53:19 AM

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

מקצועית ומבחינת קודים חברתיים וסביבת העבודה.

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

העובדים הקיימים ותומכת בהצלחת ההשתלבות.

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

/ בצוות / בצורת העבודה וכו’.

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

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

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

מעגל פינות.”

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

הוא מתחיל בהיערכות לקראתה.

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

ליכולותיו וכן להבטיח לחברה יציבות תעסוקתית.

גם “זה הקולטות: בחברות המנהלים אחד מדברי מסר ועוד עושה משהו בלב”.

לפרטים נוספים ויצירת קשר עם אסתר: נייד: [email protected] ,www.aqa.co.il :מייל

אסתר צברבוגרת הטכניון בהנדסה כימית

.)M.Sc.(12 שנות ניסיון בפיתוח תוכנה

בתעשייה האווירית. 11 שנות ניסיון בניהול בדיקות

.]ECI & BMC[ תוכנה Advisory Board -חברה ב

של הארגון הישראלי להסמכת בודקי תוכנה )ITCB( מיום

הקמתו.מזה שנתיים וחצי מובילה מיזם להכשרה ושילוב של

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

[email protected] :במה לסיפורים אחרים בתחום. להעברת סיפורים נוספים, אנא פנו למערכת

AQA.indd 19 27-Dec-10 10:43:48 AM

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

באמפתיה — הבנת נקודת מבט של הצד השני.

כתוצאה מכך, למרות היכולות שלהם, הם מתקשים לעבור ראיונות עבודה, ומי שמצליח בכל זאת להתקבל — חווה קושי בהשתלבות החברתית ובשמירה על

מקום עבודתו.

העבודה במעגל אלו אנשים לשלב הדרך את למצוא הוא החברתי האתגר ולתת ביטוי ליכולותיהם.

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

נתונים ומשימות שמחייבות דייקנות רבה, תשומת לב לפרטים וחזרתיות.

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

מיקרוסופט וכו’.

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

חברתית מובהקת.

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

גם עבורה, היא קיבלה ליווי שוטף וסיוע מקצועי מהארגון.

מטרה מתוך AQA (Asperger doing QA( את אסתר הקימה 2008 במאי להתאים אותו למאפייני תחום בדיקות התוכנה בישראל. הלוגו של AQA מציג

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

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

מקצועיים ורפואיים.

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

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

ענת בן מאיר, מומחית בעלת 30 שנות ניסיון באוטיזם ואספרגר.

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

מול גרסאות חדשות של המוצר.

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

כללי עבודה בכלי אופיס כגון: כתיבת מייל, הכנת מסמך וכו’.

בבחינות העומדים אלו שרק כך מסנן, הינו ההכשרה שתהליך לציין חשוב ובעבודה המעשית בהצלחה, ישולבו בעבודה.

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

אותו.

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

הבוגר המתאים ביותר לצרכי החברה ולסביבת העבודה.

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

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

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

תרומה לקהילה


AQA.indd 18 27-Dec-10 10:43:44 AM


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

ב‑ “Google” תתפלאו כמה תשובות תמצאו.

SQL INJECTIONמתקפה זו נפוצה מאד ואכזרית. היא מאפשרת לתוקף לשנות מבנה שאילתות הנשלחות אל בסיס המידע. תוקף עלול לנצל מתקפה זו על מנת לבצע פעולות בבסיס המידע, מחיקה של כל המידע הקיים — חשיפת כגון ומגוונות שונות

נתונים, הרצת פקודות על השרת ועוד.

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מספר ישנן זאת עם מורכבת, משימה הוא והרשאות הזדהות נושא בדיקת מממשת המערכת האם תחושה ולקבל לבצע ניתן אותן פשוטות בדיקות

מנגנונים אלו.

כל מה שצריך לבצע על מנת לדעת האם ניתן לבצע גישה לדפים הדורשים הזדהות ללא הזדהות זה את הצעדים הבאים:

1. גישה למערכת עם פרטי הזדהות תקינים. משורת הקישורים והעתקת במערכת גלישה .2

הכתובות בכל דף פנימי הנמצא במערכת.קיים )אם מהמערכת מסודרת יציאה ביצוע .3

לחצן יציאה, אם לא ע”י סגירת הדפדפן(.4. פתיחת דפדפן חדש וביצוע ניסיון גישה ישירה הזנת ללא קודם משלב אספנו אותן לכתובות

נתוני הזדהות במסך הכניסה.

בדיקה נוספת בנושא הרשאות:שונים משתמשים שני עם 3–1 צעדים ביצוע .1רגיל משתמש למשל שונות, הרשאות בעלי

ומשתמש מנהל. לבצע וניסיון רגיל משתמש עם 4 צעד ביצוע .2

גישה לדפים של מנהל המערכת.

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

לפני שמתבצעות בדיקות נרחבות יותר ע”י מומחי אבטחת מידע.

על ללמוד היא המידע אבטחת בתחום למומחה להפוך הנכונה הדרך שיטות ולימוד שיטות ולימוד שלהן מימוש לתרגל השונות, המתקפות כך evasion techniques — קלט בדיקות מנגנוני עקיפת כגון שונות

שיהיה ניתן לבצע בדיקות אבטחה ברמה גבוהה יותר.

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

SQLINJECTION


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

.XSS2 ו XSS1 להלן מספר דרכים פשוטות לבדיקת מתקפות מסוג

XSS1XSS בסיסית יחסית וניתן לבצעה בקלות יחסית. כל מה שנדרש, זה בדיקת לנסות להזין סקריפטים במקורות הקלט )טפסים, שדות וכו’( של דף המערכת

אותו אנו בודקים.

הסקריפט הבסיסי ביותר שיכול לתת לנו תשובה מהירה אם המערכת חשופה .>script>alert(‘I am XSS ‘)>/script> הינו סקריפט מהסוג: למתקפה, תגרום XSS למתקפת שחשופה במערכת קלט לשדות זה קוד הזרקת בהם מקרים )ישנם I am XSS ההודעה עם חלון להקפצת רבים במקרים יידרש לבצע שינויים שונים בסקריפט על מנת להצליח להזריק אותו ולגרום לו לפעול, על שינויים אלו לא אפרט מפאת מורכבותם, אך אתן טיפ קטן. אנא

.(http://ha.ckers.org/xss.html :הציצו בדף הבא

אתר על הבדיקה את נבצע זו, בדיקה למימוש פשוטה המחשה לצורך 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

נזין MESSGAE ובשדה ”Test Reflected XSS“ נזין Subject בשדה נבצע מכן לאחר .>script>alert(‘I am Reflected XSS ‘)</script> Posted Messages שליחה של הטופס. מרגע זה בכול פעם שניכנס לדף

נהיה חשופים להרצת הסקריפט בדפדפן שלנו:

אומנם הקפצת חלון נחמד עם הודעה לא מרגיש כמו מתקפה מתוחכמת, יודע שתוקף אחרי למתקפה. POC ב רק שמדובר להבין חשוב אך דברים הרבה לעשות יכול הוא XSS מסוג למתקפות חשופה שהמערכת

XSS1

XSS2


ירון חקון ירון הינו ארכיטקט אבטחת

מידע, ומנהל מחלקת הייעוץ בחברת Q.rity המתמחה

במתן שירותי אבטחת מידע מתקדמים. כמו כן, מנהל ירון

.Net Security את קבוצתUser Group בה מועברות

הרצאות רבות בנושאי אבטחת מידע בסביבת .Net, נושאי hacking ונושאים נוספים

מתחום אבטחת המידע.

ניתן לצור קשר עם ירון בכתובת: [email protected]

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

במאמרי המשך בנושא זה(.

חלק ב’להלן המתקפות אותן אסקור במאמר זה ותיאור קצר עבור כל מתקפה:

XSS 1 (Cross Site Scripting) — הזרקת קוד עוין למערכת דרך ממשקי קלט הקיימים כגון ממשק משתמש.

על שישפיע כך למערכת SQL בשפת קוד הזרקת — SQL Injection 2בדרך התערבות בעצם המידע, בסיסי אל מהמערכת המופעלות השאילתות

הגישה לבסיסי המידע.

Authentication bypassing 3 – ביצוע גישה ישירה לפונקציונאליות במערכת תוך עקיפת מנגנוני הזדהות והרשאות של המערכת.

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

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

XSSבחרתי להציג מתקפה זאת ראשונה, גם בגלל שהיא מקוטלגת בין המתקפות ביצוע מאפשרת שהיא בגלל וגם Web ה‑ עולם מבחינת ביותר הנוראיות

מתקפות נוספות באמצעותה.

למתקפה זו קיימים שלוש תצורות בהן ניתן לממש אותה. לכול צורה קיימת השפעה קצת שונה, להלן תיאור קצר של הסוגים:

HTTP הזרקת הסקריפט הזדוני מתבצע ע”י שליחת בקשות — Reflected 1מהתשובה כחלק העוין הסקריפט את להחזיר למערכת הגורמות למערכת,

המוחזרת מהשרת בצורה חד פעמית.

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

מהמתקפה הוא חשוף להרצה של סקריפט זדוני אצלו בדפדפן.

הרצים הסקריפטים התקפת על מבוססת זו מתקפה — DOM Base 3בצד עיבוד על שמבוססים הראשונים הסוגים שני )לעומת המשתמש בצד DOM ה של מניפולציה וביצוע אליהם ישירות סקריפטים הזרקת השרת(, http://www.webappsec.org/projects/ בנושא מצוין מאמר )ראה

.(articles/071105.shtml

חשיבות ביצוע בדיקות אבטחת מידע הינה גבוהה ואף קריטית, לא פחות מחשיבות ביצוע בדיקות

שפיות אותן מבצע בודק ה QA של מערכת, בדיקות שאותן מקובל לבצע כבר שנים רבות והינם במרבית

המקרים תנאי מקדים לפני הפצת מערכת.

Web User Browser

HTTP

get/post URL and params

get data from DB (SQL) or from local resource

return data from DBreturn HTTP page containing the data user requested

Web Application DB

SQL

1

3

2

2.1

Internet

בדיקות ת מידע אבט

לבודקי תוכנה


חלק א’בדיקות אבטחת מידע הינן נושא הנדרש בכול מחזור חיים של מערכת מידע

אותה מעוניינים לפרוש אצל לקוח על גבי רשת פנימית או חיצונית.

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

במערכת(.

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

לפני הפצת מערכת.

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

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

את הידע ולבצע בדיקות אבטחת מידע ברמה גבוהה יותר.

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

ההפעלה בה הותקנה )במידה ונדרש(.

במאמר זה אתמקד במספר דרכים בהן ניתן לבצע בדיקות אבטחת מידע פשוטות ושירותים המפותחים בטכנולוגיית ברמה האפליקטיבית, לממשקי משתמשים OWASP ארגון ע”י מקוטלגות שהן כפי בדיקות לקטגוריית בהתאם ,WEB(http://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project ) העולמי בפרויקט בשם TOP 10 )רק עבור חלק מהמתקפות אותן

סוקר הפרויקט(.

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

http://xss.progphp.com XSS לבדיקת online אתר התקנה של אתר ‑ HacmeBank המאפשר תרגול מתקפות WEB, ניתן http://www.foundstone. הבאה: מהכתובת האתר של התקנה להוריד com/us/resources/termsofuse.asp?file=hacmebank2_install.zip באמצעות מערכת זו תוכלו לבצע תרגול נוסף מעבר למופיע במאמר זה.

בנוסף, יכול בודק QA לבצע הרצה של כלי בדיקה אוטומאטיים חינמיים שיכולים לחשוף לא מעט בעיות אבטחה במערכות מבוססות טכנולוגיית זו למטרה כלים מספר למצוא ניתן בו לעמוד קישור להלן ,WEBhttp://www.webresourcesdepot.com/10-free-web-application-

security-testing-tool )במאמר זה לא אראה שימוש בכלי סריקה(. חשוב להבין שהרצת כלים אלו אינם מחליפים בדיקות ידניות של בודק אבטחה

מוסמך.

.WEB תחילה, רקע קצר על אפליקציות

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

לצורך הצגה בדפדפן של תוצאות הבקשה.

מידע למערכות פריצה לצורך תוקף מנצל אותן הנפוצות, החולשות אחת החשוב הכלל המערכת. צד אל המשתמש מצד המועבר לקלט קשורה ביותר מבחינת מפתח המערכת הוא לבצע בדיקות אימות קלט לפני שהוא מבצע שימוש כל שהוא בקלט אותו הוא מקבל מצד המשתמש, על מנת לא להיות חשוף למתקפות הקלט ‑ injection attack אותן הציג בחלק שני של

המאמר.

תוקפים רבים מבצעים שימוש בכלי PROXY כדי שיהווה חוצץ בין צד המשתמש בין צדדים אלו. נרצה להביט על המידע הזורם לצד השרת, בגלל שכתוקף, או ע”י ממשק המשתמש רק הנחשף למידע מוגבלים להיות רוצים לא אנו

בדיקות ת מידע אבט

לבודקי תוכנה


מאת ירון חקון

ראיון עם מנהל בדיקות

אני ממליץ לבודק תוכנה מתחיל ללכת לעבוד במקומות בהם יוכל ללמוד שיטות עבודה מסודרות. ללמוד קודם את

ה"מקצוע" מלמטה ובצורה הנכונה. מקומות בהם ניתן ללמוד את העבודה לפי הספר.

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

להמשך.

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

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

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

שאם לא הייתי מגיע לתחום הבדיקות, הייתי ממשיך לעסוק בתחום הפיתוח.

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

בדיקות ומשימות. כך ניתן לעלות על נקודות תורפה בקלות.

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

מוכשרים עם מוטיבציה ולא גאונים סוליסטים.

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

אני ממליץ לבודק תוכנה מתחיל ללכת לעבוד במקומות בהם יוכל ללמוד

מודעת הפרסום שלך יכולה להיות

כאן

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


[email protected] :לפרטים

Interview.indd 13 23-Dec-10 11:30:25 AM


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

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

ניכר את איכות העבודה.

תחת בארגון נוספים נושאים אילו .2אחריותך?

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

שהיא מועברת לסניפי הבנק.

בנוסף, אני עוסק בהקמת גוף לטיוב נתונים אשר מטרתו לשפר את איכות מאגרי המידע לסוגיהם .

במהלך נתקלת ואתגרים בעיות באילו .3עבודתך?

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

לאיכות גבוהה מאוד.

הכי מקצועית שמבחינה הדברים מהם .4מתסכלים אותך במהלך עבודתך?

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

הקשור לטרמינולוגיה, מונחים, מתודולוגיות ותהליכי עבודה.

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

קצת יותר כדי שאוכל לקבל אנשים טובים ומרוצים יותר.

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

לצרכים שלהם, ומציע מענה ספציפי, כל אחד לפי צרכיו.

7. איך לדעתך יראה תחום הבדיקות בעוד 5-10 שנים? במה הוא יהיה שונה מהיום?

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

מקרה לא יהיה תחליף לתכנון התסריטים על ידי הבודק.

מתודולוגיות, בדיקה, שיטות יש האם .8רעיונות מקוריים או טיפים בתחום הבדיקות

עליהם היית ממליץ?בתקופה האחרונה סיימנו מהלך של בניית תבנית בדיקות אחידה לכל הפרויקטים ב-Quality Center כולל פיתוח

פרופיל אישי

שם: אביעד בן יצחקמצב משפחתי: נשוי + 3

מגורים: מודיעין

תפקיד: מנהל תחום הבדיקות בבנק לאומי

קרירה: 24 שנים בצה"ל )סגן אלוף( במגוון תפקידים

באגף התקשוב /חייל הקשר. תפקיד אחרון בחיל: מפקד בית הספר למחשבים. 6.5 שנים בבנק לאומי. 3 שנים

אחרונות בתפקיד מנהל תחום הבדיקות.

השכלה: תואר ראשון בכלכלה ומדע המדינה. תואר

שני במנהל עסקים.

ראיון עם מנהל בדיקות

האני מאמין שלי – ארגוני בדיקות כארגוני איכות צריכים לתפקד ברמה הגבוהה

ביותר. עניין של דוגמא אישית

אביעדבן יצחק

Interview.indd 12 23-Dec-10 11:30:18 AM

IPM – Iteration Planning( כל איטרציה מתחילה בפגישת תכנית איטרציהבתוצאות דנים השאר )בין האחרונה האיטרציה נסקרת בפגישה .)Meetingבדיקות הקבלה ומסיקים מסקנות( ודנים בסיפורים )Stories( לאיטרציה הבאה.

מבוצע הפיתוח לדוגמא: במקביל. עובדים הצוותים כל האיטרציה, במהלך במקביל לבדיקות ולכתיבת האפיונים.

משימות הבדיקות הן: Acceptance( מעבר קריטריון הגדרת בסיוע הלקוח ע”י בדר”כ מבוצע :)Criteriaהבדיקות והפיתוח. נועד לייצר שקיפות ולתאם הלקוח של בשפה להשתמש חשוב ציפיות.

לצורך הגדרת הקריטריון.

Test Driven Development – גישה האומרת תכנית נכתבת שנכתב תוכנה חלק כל שעבור ברוב המקרים, תכנית הבדיקה קוד. אותו לבדיקת נכתבת לפני כתיבת הקוד עצמו. בדר”כ מבוצע ע”י נכתבות הבדיקות הבודקים. של בסיוע המפתחים כל עם ומורץ המערכת קוד נכתב שבה בשפה

.Build קומפילציה ועם כל

בדיקות קבלה אוטומטיות – מבוצע על מנת לוודא כי עמדנו בציפיות הלקוח וכן כי המערכת ממשיכה לתפקד עם התקדמות הפיתוח. מטרה נוספת יכולה להיות סיוע באפיון דרישות המערכת. מבוצע ע”י הלקוח בסיוע ה-QA. כלים .)http://fitnesse.org) Fitnesse -ו FIT מומלצים לבדיקות אוטומטיות הם

המסורתית בגישה בדיקות ביצוע ,Agile-ה בגישת – Exploratory Testing(Scripted Testing( כמעט ואינו אפשרי, שכן מסמכי האפיון מוכנים רק לאחר סיום הפיתוח. מומלץ לבצע Pair Testing )בודק מבצע הבדיקות והמפתח יושב

מאחוריו מוסיף רעיונות(.

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

יותר שכן הם “מייצגים” את נקודת ההשקפה של המשתמש.

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

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

מבודקים רגילים.

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

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

אפשרויות בצורה משמעותית.

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

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

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

אוטומטיה עקב בעיות בסקריפטים וכו’(.

Test-ה תפיסת את הצגתי מכן לאחר התפיסה של הבסיסי העיקרון .Languageהוא שהאחריות על תכנון בדיקות אוטומטיות והרצתן מבוצע ע”י הבודקים הידניים במקום

אנשי האוטומציה.

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

העברת והבנת ידע בין אנשי האוטומציה לבודקים הידניים.

כי מבטיחה הייתה שההרצאה )מתברר המשתתפים לכלל נתתי המצגת לסיום באולם היו מעל 100 משתתפים( תרגיל שבמהלכו הם היו אמורים לכתוב בדיקות – כלי ניהול בדיקות אוטומטיות של קווליטסט המהווה FUnTASy-באמצעות ה

פלטפורמה לבודקים ידניים לכתיבת בדיקות אוטומטיות ללא צורך בשימוש בקוד.

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

להציג אותו.


ויינברג. בעולם. במהלך הכנס ניתן אות תרומה לענף הבדיקות לג’רי הבדיקות בתחום הבולטים מהאישים אחד הינו ג’רי היסוד אבני יצקו את ספריו הוא פרסם מספר ספרים אשר חלקם בין היום. אותו מכירים שאנו כפי הבדיקות עולם Secrets of Consulting, Quality Software של שהוא יסיים את לימודי העברית שלו...של המגזין הוא ממש התרגש והבטיח לקרוא כל מילה ברגע about Testing ועוד. כשהצגתי בפני ג’רי את הגליון הראשון Management, Perfect Software: And Other Illusions הבולטים:

רשמים מכנס STP בלאס וגאס איל זילברמן

STP.indd 11 23-Dec-10 11:06:54 AM


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. באתר דוגמאות מספר למצוא ניתן לטעות... היה יכול המפתח איפה

.)General Testing תחת טאב Testometer חפשו( TestingGeek.com

G Forces in the Organization (Kent Beck)בעולם האחרונות ההתפתחויות את סקרה אשר הרצאה נתן בק קנט בקצב משמעותי גידול הוא ביותר המשמעותית ההתפתחות הבדיקות. הארגונים רוב לשנה, אחת גרסא משחרור ארגונים. של הגרסאות שחרור עובדים היום ברמה של מספר גרסאות בשנה. הצפי של קנט הוא כי תהליך חדשה גרסה של בתצורה יעבדו הארגונים רוב 2030 ובשנת ימשיך, זה

שתשוחרר כל שבוע!!!.

לתהליך זה השפעה משמעותית על עולם הבדיקות. מצד אחד קצב העבודה עולה, צורך ויהיה הארגון בהצלחת קריטי משקל יהיה האוטומטיות הבדיקות לתחום להגיע ל-100% כיסוי אוטומטי של בדיקות רגרסיה. מודל העבודה יעבור יותר ויותר

לכיוון של Agile. גם גישת הבדיקות הולכת להשתנות. הוצגו מספר דוגמאות:

במקום דרישה לתיעוד מלא ותהליך עבודה מובנה, ייעשה יותר שימוש בלוחות מחיקים.

Stand-up meetings( במקום פגישות ארוכות ודיונים - פגישות של 15 דקות– חדרי פגישות ייעודיים ללא כסאות( במקום פגישות ארוכות.

Pair מקום עבודה בצוותים גדולים, העבודה תיעשה בצוותים קטנים )לדוגמאהתוכנה לבודק בצמוד עובד המפתח בה גישה – Development-Testing

וכל פעולה נעשית ביחד(.

במקום הגדרת תפקידים ברורה ייעשה שילוב אחריות ותפקידים )מפתח לא גם מתקנים באגים אלא מוצאים רק לא בודקים בודק, גם רק מפתח אלא

אותם(.

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

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

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

ומה שמתוכנן ליום הבא.

בלאס-וגאסמכנס STPרשמים

STP.indd 10 23-Dec-10 11:06:53 AM

לסיכום

נובע תוכנית הבדיקות שלהם. החשש ET במסגרת חוששים להטמיע רבים בודקים מסיבות כגון: העדר תיעוד, יכולת בקרה מוגבלת, בעיית כיסוי של המערכת הנבדקת

ועוד סיבות שונות ומגוונות.

להראות מטרה מתוך ET ל- בנוגע ביותר השכיחות הטעויות 10 את סקרנו במאמר שטכניקה זו יכולה להיות יעילה לא פחות מכל טכניקה אחרת ואף טובה יותר.

Exploratory Testing .Exploratory לא מספיק להריץ בדיקות חופשיות ולקרוא להםET הינה גישה Testing, למרות הדיעה הרווחת בקרב הרבה אנשי בדיקות בישראל,

מאוד מוסדרת ומתועדת והניסיון ”לבלגן“ אותה יוביל לתוצאות לא אופטימליות.

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

ב“איכות“ גבוהה ובזמן קצר וזה משהו שכל בודק או מנהל בדיקות שואף להגיע אליו.

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

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

באיטרציה שניה, בהתאם לכמות הבאגים שנמצאו ולנקודות הסיכון שהבודק גילה.

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

ומדדים טובים יותר, ויכולה לשמש גם לשיפור התכנון וההערכה בעתיד.

טעות מספר 8: אתה חייב לבחור: או Exploratory Testing או

בדיקות ידניות

ידניות. אפילו כאשר תהליך הבדיקה 100% בדיקות אין דבר כזה (ורק בדיקה מקרי אותם וביצוע בדיקה מקרי יצירת משמעותו אותם), עדיין ייעשה שימוש ב ET. אמנם, לא בשלב ההרצה (אלא אם כן נמצאו באגים ואז בדרך כלל בחינת הבאג דורשת חקירה על

ידי הבודק), אלא לשם התכנון והעיצוב של מקרי הבדיקה.

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

כאשר הם מבצעים בדיקות נוספות שאינן מוגדרות מראש.

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

אשר יוביל לתוצאה הטובה ביותר עבור הפרויקט שלו.

טעות מספר 10: אי אפשר Exploratory Testing ליישם

במערכות מורכבות

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

שלא תוכננו.

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

.ET יותר ליישום

10

8

7

!

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

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

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

באגים שפשוט ”נמצאים מול העיניים“.

מקורות

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

9?


Cover_Story_2.indd 9 27-Dec-10 10:37:55 AM

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

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

ET הוא כמו שחמט, אפשר ללמוד את המשחק תוך זמן קצר, אך ללמוד לשחק היטב כבר איננו עניין של מה בכך. על בודק ET להיות מצויד היטב בטכניקות בדיקה על מנת

לבצע ET באופן מוצלח ויעיל.

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

אלא גם לספק מידע מפורט על מה שהיה לך בראש ומה רצית לבדוק בכל בדיקה.

בין מבט ממוקד למבט מיומנות המעבר היא ET-ב נוספת להכשרה הדרושה דוגמא להתמקד עשויים בודקים מערכת, בודקים כאשר .(de-focus-ו focus) מלמעלה במודול מסוים אותו הם בודקים עד כדי התעלמות מהתמונה הכוללת. חלק מההכשרה הדרושה לקראת ET היא היכולת להתמקד ולעבור למבט כללי. קל מאד להסביר את

העניין אך היכולת לפעול כך דורשת הכשרה ותרגול רב.

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

אחת הטענות המרכזיות כנגד ET היא שהגישה אינה מאפשרת להנהלה שליטה על זהות התוכן הנבדק. למעשה, אנו מאמינים שזהו הטיעון העיקרי כנגד בדיקות

.(scripted testing) ידניות

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

נסקר רק מדגם מייצג מתוך הבדיקות.

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

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

(Test Lead) “באחד הארגונים בהם עבדנו הגדרנו את התפקיד ”מוביל בדיקותמוביל מקטע, כל בסיום הבדיקה. דוחות את לסקור היה העיקרי שתפקידו הבדיקות ביצע תחקור מסודר של דוח הבדיקה. המטרה היתה לוודא ביצוע תקין של הבדיקה וכן שהבודקים כיסו את כל התרחישים הדרושים. רישומי הבודקים את הבין שהבודק לוודא בבואו הבדיקות מוביל את ששימש האמצעי הם המערכת הנבדקת והיה מסוגל להציע היכן היא עלולה להיכשל. בפועל, היתה זו

הפעם הראשונה שנעשתה סקירה אמיתית של התוכן הנבדק...

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

נפח הדיווח הדרוש ולמקד את מאמציו בהעלאת רעיונות בדיקה חדשים.

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

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

לבדוק, באיכות הקוד וכו‘.

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

המאותרים במשך שעת בדיקה, וקביעת חומרתם.

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

המערכת לגבי יותר רב מידע עומד הבודק לרשות ,ET ביצוע בעת ולכן הוא וגם מידע המתקבל מהמערכת עצמה) הנבדקת (גם האפיון

יכול להמציא יותר מקרי בדיקה ולגלות יותר פגמים.להתמקד לבודקים מסייע הבדיקות במהלך הנאסף המידע

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

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

את ההערות).

טעות מספר 3: המיומנויות Exploratory הדרושות לבודק

Testing שונות מאלה של בודק (Scripted Tester) ידני

הפעולות את משנה אינה ET — “ET ”בודק כזה דבר אין רק ET כך, זאת לנסח אפשר בבדיקות. הכרוכות העיקריות משנה את לוח הזמנים לביצוע הפעולות: במקום ללמוד את כל הפעילויות לבצען, כך ואחר לתכנן את הבדיקות המוצר,

מתבצעות במקביל.

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

משתמשים...

34

56



מגזין חושבים בדיקות ׀ אוקטובר 2010 ׀ 7

גדולה, תקשורת בחברת וותיק QA מנהל עם שניהלתי השיחות באחת הצגה לאחר .Exploratory Testing-ה גישת את בפניו להציג ניסיתי ראשונה התגובה הייתה מפתיעה: ”אנחנו כבר עושים את זה בארגון. כאשר נותן אני זמן, לי אין כאשר או הבדיקות מפרטי הרצת את מסיימים אנו

לבודקים שלי להתפרע וככה אני מוצא את רוב הבאגים במערכת“.

Exploratory Testing, אבל התיאור שלהלן הינו אמנם דרך אחת לעשות דרך מאוד לא טובה! הרי לא סביר שדווקא הגישה אשר מניבה הכי הרבה תוצאות (באגים) תבוצע באופן לא מבוקר ולא מסודר בעוד שהדגש על סדר

וארגון יתבצע דווקא בגישה הפחות יעילה...

השוק הישראלי מפוצל בגישתו לגבי Exploratory Testing (ET) כטכניקות לגיטימית גישה מהוות אינן ET כי הסוברים כאלו ישנם מתאימות. בדיקה חוסר הנבדקת, המערכת של מלא אי-כיסוי כגון שונות בטענות לבדיקות ET טוענים כי ,QA יכולת לבצע בקרה וכו‘. מצד שני, רבים, כגון אותו מנהלכבר מבוצעות בארגונם, אולם ET מוגדרות כבדיקות אד הוק — דהיינו בדיקות

.(monkey testing או free style מעין) לא מתועדות, לא מבוקרות

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

דיעות מוטעות אותן שמענו לגבי הנושא והסבר לגבי אותן נקודות.

ET ההגדרה המוכרת ביותר לנטבעה על ידי ג‘יימס באך James Bach) וקאם קנר

:(and Cem KanerET הינן פעילות במקביל של

למידה, תכנון בדיקות, וביצוען.

לאחרונה שונתה ההגדרה ל: ET מהווה גישה לבדיקות

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

למקסם את ערך עבודתו. זאת ניתן לעשות אם מתייחסים אל

למידה, עיצוב בדיקות וביצוע בדיקות כאל פעולות התומכות

זו בזו והמתקיימות במקביל לכל אורך הפרויקט“.

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

נכון עלול לגרום לכיסוי חלקי של המוצר, בדיוק ET באופן לא אכן ביצוע של כשם שתכנון בדיקות מראש (Scripted Testing) לא נכון יכול להביא לאותה

תוצאה.

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

ישובץ במוצר מבלי לתת לבודקים הזדמנות למצוא אותו.

שימוש במתודולוגית SBTM (Session-Based Test Management) הוא דוגמא לשיטה להבטחת כיסוי של המערכת הנבדקת. SBTM מחלק את כל (Test Mission) (Sessions). לכל מקטע יש משימה הבדיקות למקטעים (מה הבדיקה גבולות את מגדירים ביחד אשר (Charter) רישום וטופס נדרש לבדוק). שימוש ב SBTM יכול לסייע לצוותי הבדיקה בהבטחת הכיסוי ובאותה עת משאיר לבודקים חופש להפעיל שיקול דעת שמבטיח כיסוי מלא SBTM ניתן למצוא באתר של ג‘יימס באך של המערכת. מידע נוסף אודות

www.satisfice.com

ב“טבלאות שימוש באמצעות הינה הדרישות כיסוי להבטחת נוספת שיטה מצב“ (State Tables). נוהל זה מבוסס על קישור Session Logs (לוג הנכתב איפיון / לדרישות שבוצעו) הבדיקות את ומפרט Session כל הרצת בסיום המערכת, כך שנוצרות טבלאות עקיבה המצביעות על ה-Session שבמהלכו

.(Test Case) נבדק כל מקרה בדיקה

חשוב לציין שבדיקת כל מקרי הבדיקה שבדרישות אינה מוכיחה שהמערכת אכן נבדקה. אלא, שאם בודקים את כל הדרישות בגישת ET, מגבירים את רמת

הביטחון בכך שרוב הבאגים במערכת אכן נמצאו.

2

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


.Intel בחברת

איל זילברמןאיל זילברמן הוא ממיסדי חברת קווליטסט

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

רוני וולפינזוןרוני וולפינזון פועל בתחום בדיקות התוכנה מאז 2006, ועסק בעיקר בתחום המערכות

הצבאיות. רוני שימש כיועץ ומנהל פרויקטים עבור חברות כמו: חיל האויר, אלביט מערכות

והתעשיה האוירית לישראל. כיום משמש רוני כמנהל בדיקות

10 הטעויות הנפוצות ביותר בנושא Exploratory

Testing

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

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

רבים הבודקים הם האנשים המתמצאים ביותר ברזי המוצר).

היא: הנשאלת השאלה מטבעה! (Structured) מובנית היא בדיקה כל טועים מיומנים בלתי ET בודקים קרובות, לעיתים מובנית? הבדיקה כיצד לחשוב שגישת ET אינה מובנית משום שהם בודקים באופן לא עקבי, כלומר:

מבצעים בדיקות שונות בכל מחזור בדיקות.

1

רוני וולפינזון ואיל זילברמן



פרויקט מרגליות של קווליטסט מעסיק מעל 100

בודקות ומציע את המקצועיות הגבוהה של קווליטסט במודל

LOW COST מקומי

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

למידע נוסף ותיאום פגישת היכרות:[email protected]

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


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

היה נכון ומוצדק.

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

בודק מחברה אחרת?

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

וקשה מעניינים המאמרים כל משוחד!) אני (אבל לדעתי להצביע על כמה מהם באופן מסוים, אבל בין כל המאמרים במהדורה אני רוצה להתמקד בשלושה שאני אוהב במיוחד.

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

בקיא ב-ET ורוצה לנסות אותה במהלך הבדיקות שלו.

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

מסובכת ותאורטית מדי.

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

מקום אצטרך לתת לכם לגלות אותם בעצמכם.

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

הכתיבה שלכם... אנחנו כאן לעזור לכם!

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

קריאה מהנה,יואל.

[email protected] :לתגובות, הערות, והצעות

ברוכים הבאים לגליון השני של חושבים

בדיקות, מגזין הבדיקות העברי הראשון מסוגו

בישראל.

זה מרגש לכתוב את ההקדמה לגליון השני בעיקר בזכות

הכנסו עכשיו לאתר המגזין והרשמו למנוי

בחינם! www.ThinkTesting.co.il

Editor_02.indd 4 27-Dec-10 10:21:43 AM

עורך ראשי: יואל מונטבליסקיוועדה מקצועית: איל זילברמן,

רם יוניש ויואל מונטבליסקירכז מערכת: עמיחי סטרלינג

Red Designer עיצוב: סטודיואתר והרשמה למנוי חינם:www.ThinkTesting.co.il

[email protected] :יצירת קשרהדפסה: דפוס מאי

הצטרף לקבוצת המגזין ”חושבים בדיקות“ LinkedIn-ב

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

10 דברים שחשבת שאתה יודע על Exploratory Testing

רוני וולפינזון ואיל זילברמן

רשמים מכנס STP בלאס וגאס איל זילברמן

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

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

בודקים קצת אחרת. בעלי תסמונת אספרגר — בודקי תוכנה מיוחדים

אסתר צבר

הדרך הארוכה והקצרה לבניית תוכנית בדיקות טובה ומנוהלת אסף האוזר

4

6

10

12

14

18

20

ICTB תחרות בודק השנה של

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

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

Exploratory Testing — בחן את עצמך

Pairwise Testing מקסימום כיסוי במינימום בדיקות טלמון בן-כנען

מגמות בעולם הבדיקות — קיצור איטרציות הפיתוח רם יוניש

המלצה על ספר ובלוג איל זילברמן ויואל מונטבליסקי

מיומנו של בודק מתחיל

Editor: Joel MontveliskyProfessional Committee: Ayal Zylberman, Ram Yonish and Joel MontveliskyProduction coordinator: Ami SterlingDesign: Red Designer StudioWebsite and free subscription: www.ThinkTesting.co.ilContact: [email protected]: May PrintJoin “חושבים בדיקות” group on LinkedIn

22

24

28

31

32

36

38

39

תוכן הענייניםגליון מס‘ 02 ׀ ינואר 2011


ינואר 2011 גליון מס‘ 02 www.thinktesting.co.il


ToC.indd 3 27-Dec-10 10:20:12 AM

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

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

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

מגזין הבדיקות הראשון

בעברית ב די קותמגזין חושב ים


(NOT) איךלפשל

באוטימיזציה


בדיקות ואופטימיזציה

של ביצועי יישום רשת



בחן את עצמך Exploratory

Testing

מקסימום כיסוי במינימום

בדיקות

10 הטעויות הנפוצות ביותר בנושאExploratory

Testing

Documents

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