tag:blogger.com,1999:blog-60293148907948024862012-02-09T20:44:09.280+02:00כאדם בעל ניסיון והכשרה בתחום בדיקות התוכנה החלטתי שהגיע הזמן לרשום לפחות חלק מהמידע שצברתי במשך השנים. הסיבות לכך הן: לרכז את החומר, להנגיש את המידע לאנשים בצוותים שלי וגם בכדי שכל מי שמתעניין בתחום יוכל לקרוא ולקבל רעיונות. המידע כאן רלוונטי הן לאנשים חדשים בתחום והן לבעלי ניסיון. האתר והטמפלייטים הם בחינם ומתוך רצון טוב. אהבתם? לחצו על ה"Like / Share".דורון ברhttp://www.blogger.com/profile/14499386811348993353noreply@blogger.comBlogger931100tag:blogger.com,1999:blog-6029314890794802486.post-36979573646731209512012-01-10T20:59:00.000+02:002012-01-10T21:00:22.561+02:00

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

דורון ברhttp://www.blogger.com/profile/14499386811348993353noreply@blogger.com0tag:blogger.com,1999:blog-6029314890794802486.post-13485016395319598212011-12-29T23:28:00.002+02:002011-12-30T08:28:34.535+02:00

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

דורון ברhttp://www.blogger.com/profile/14499386811348993353noreply@blogger.com0tag:blogger.com,1999:blog-6029314890794802486.post-67766471319150903762011-12-13T22:58:00.000+02:002011-12-29T22:43:25.856+02:00

ברור שלכל אחד שיקול משלו, למשל באפליקציות שרת יש לשים לב למערכות הפעלה מותאמות שרת כגון windows server 2008. אבל ברגיל בשרת לא משתמשים בקליינטים נפוצים כמו של תחנות עבודה, למשל ב-Office. אני מכוון כאן למי שתחנות העבודה הם קהל היעד שלו. גםכאן עדיף לבדוק הכל ברמת הסביר: XP, Vista,Win7 וכל אחד גם 32 ביט וגם 64 ביט. אם אין זמן יש לבדוק: - XP x86 כי אין הרבה XP עם 64 ביט. - Vista x86 גם כאן אין כמות

דורון ברhttp://www.blogger.com/profile/14499386811348993353noreply@blogger.com0tag:blogger.com,1999:blog-6029314890794802486.post-1910749620614907282011-11-11T21:55:00.001+02:002011-11-12T14:30:58.653+02:00

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

דורון ברhttp://www.blogger.com/profile/14499386811348993353noreply@blogger.com0tag:blogger.com,1999:blog-6029314890794802486.post-32678823273739619902011-08-21T17:04:00.002+03:002011-08-26T13:36:18.174+03:00

המוצר - או נכון יותר השירות - הזה, הkeynote (http://www.keynote.com/), מיועד בעצם למי שאחראי על אתר וחשוב לו שהאתר יהיה זמין 24X7, יעלה במהירות סבירה ומכל העולם. יש שני שלבים עיקריים בתפעולו:1.      מורידים תכנה בשם KITE (http://kite.keynote.com/).2.      מקליטים סנריו וובי בסיסי על דפדפן מבוסס אקספלורר או דפדפן פרופרייטי שלהם. למשל: פתיחת האתר, ביצוע חיפוש, מעבר לכמה עמודים. שומרים את הסקריפט

דורון ברhttp://www.blogger.com/profile/14499386811348993353noreply@blogger.com0tag:blogger.com,1999:blog-6029314890794802486.post-67978058792979252002011-08-11T15:45:00.002+03:002011-08-11T21:24:31.126+03:00

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

דורון ברhttp://www.blogger.com/profile/14499386811348993353noreply@blogger.com0tag:blogger.com,1999:blog-6029314890794802486.post-70105589839775827642011-07-15T17:11:00.004+03:002011-07-15T17:17:37.928+03:00

לראשונה נתקלתי אישית בתופעת ה-offshore כשעבדתי בקומברס. כינסו את המחלקה שלנו והודיעו לנו חגיגית על הקמת מטה בהודו ותחילת העבודה איתם. הרושם היה ש-El Dorado , עיר מיתולוגת העמוסה לעייפה בזהב, נמצאה. מדובר באנשים מבריקים, הסבירו לנו מנהלינו  בחיוך עם מבט מזוגג בעיניים, והמשיכו: נתנו להם לבדוק  flows של תאים קוליים שאנחנו בעצמנו, היצרנים של המוצר, לא מכירים מרוב שזה מסובך. אחרי יומיים, תוך כדי

דורון ברhttp://www.blogger.com/profile/14499386811348993353noreply@blogger.com1tag:blogger.com,1999:blog-6029314890794802486.post-52364542394248004802011-07-02T17:38:00.000+03:002011-07-02T17:38:27.697+03:00

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

דורון ברhttp://www.blogger.com/profile/14499386811348993353noreply@blogger.com0גני תקווה, ישראל32.060496 34.87312299999996432.054409 34.86413199999996 32.066583 34.882113999999966tag:blogger.com,1999:blog-6029314890794802486.post-31981237304622364602011-06-12T07:21:00.000+03:002011-06-12T07:21:31.199+03:00

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

דורון ברhttp://www.blogger.com/profile/14499386811348993353noreply@blogger.com0tag:blogger.com,1999:blog-6029314890794802486.post-68387081097920410792011-06-04T13:29:00.003+03:002011-06-10T16:03:45.342+03:00

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

דורון ברhttp://www.blogger.com/profile/14499386811348993353noreply@blogger.com0tag:blogger.com,1999:blog-6029314890794802486.post-15108416112039304182011-05-31T20:28:00.002+03:002011-06-10T16:04:08.730+03:00

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

דורון ברhttp://www.blogger.com/profile/14499386811348993353noreply@blogger.com0tag:blogger.com,1999:blog-6029314890794802486.post-65503432996226030502011-05-25T23:37:00.003+03:002011-06-10T16:04:24.062+03:00

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

דורון ברhttp://www.blogger.com/profile/14499386811348993353noreply@blogger.com0tag:blogger.com,1999:blog-6029314890794802486.post-33212849160211655082011-05-22T16:05:00.003+03:002011-06-10T16:04:36.470+03:00

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

דורון ברhttp://www.blogger.com/profile/14499386811348993353noreply@blogger.com0tag:blogger.com,1999:blog-6029314890794802486.post-64396193172894879272011-05-05T10:22:00.002+03:002011-06-10T16:11:02.914+03:00

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

דורון ברhttp://www.blogger.com/profile/14499386811348993353noreply@blogger.com0דרך בן גוריון 30, רמת גן, ישראל32.0922718 34.8223235000000432.0922698 34.82231200000004 32.0922738 34.82233500000004tag:blogger.com,1999:blog-6029314890794802486.post-17173545293907978682011-04-15T17:26:00.004+03:002011-06-10T16:11:37.021+03:00

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

דורון ברhttp://www.blogger.com/profile/14499386811348993353noreply@blogger.com0tag:blogger.com,1999:blog-6029314890794802486.post-24944439049620711972011-04-08T17:44:00.004+03:002011-06-10T16:11:56.887+03:00

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

דורון ברhttp://www.blogger.com/profile/14499386811348993353noreply@blogger.com0tag:blogger.com,1999:blog-6029314890794802486.post-69975219599859110702011-03-17T14:50:00.000+02:002011-03-17T14:50:03.999+02:00

ה-backlog זו רשימה מתועדפת של עבודה שיש לבצע בכדי להחיות את המוצר. זה יכול להכיל דרישות לקוח או אפשרויות טכניות, תיאור של דרישות פונקציונליות ושאינן פונקציונליות, העבודה הנחוצה להשקת האתר, איך לסדר את הסביבה ורשימת באגים. זהו בעצם התחליף למסמך הדרישות של פעם והוא באחריות בעל המוצר אך מתוחזק בעזרת צוות ה-Scrum. יש לבקלוג ארבע תכונות עיקריות: It is detailed appropriately, estimated, emergent, and

דורון ברhttp://www.blogger.com/profile/14499386811348993353noreply@blogger.com0tag:blogger.com,1999:blog-6029314890794802486.post-73264017095360073872011-03-07T15:15:00.001+02:002011-03-08T08:42:11.085+02:00

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

דורון ברhttp://www.blogger.com/profile/14499386811348993353noreply@blogger.com0tag:blogger.com,1999:blog-6029314890794802486.post-81807863688157221212011-02-20T09:42:00.002+02:002011-03-07T15:15:52.072+02:00

הימים בהם מנהל המוצר היה יושב מבודד בחדר וכותב דרישות פסו מן העולם (אם כי לא בטוח שכולם יודעים את זה). במאמר זה אתאר את הדרך היותר נכונה מבחינתי לנהל מוצר כחלק מתפקיד חדש: בעל המוצר. עוד על Scrum ו-Agile מדוע צריך  product owner (להלן PO)? בשיטת ה-waterfall המוצר החל בשיווק, המשיך בניהול המוצר, מכאן למנהל הפרוייקטים וכן הלאה - פיתוח, בדיקות ועוד. בעצם אין אחראי אחד מבחינת מוצר לכלל תהליך הפיתוח

דורון ברhttp://www.blogger.com/profile/14499386811348993353noreply@blogger.com1tag:blogger.com,1999:blog-6029314890794802486.post-63175047709371971952011-02-09T13:21:00.002+02:002011-06-10T16:07:20.225+03:00

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

דורון ברhttp://www.blogger.com/profile/14499386811348993353noreply@blogger.com0tag:blogger.com,1999:blog-6029314890794802486.post-69724739434624194212011-01-26T16:46:00.002+02:002011-06-10T16:08:23.972+03:00

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

דורון ברhttp://www.blogger.com/profile/14499386811348993353noreply@blogger.com0tag:blogger.com,1999:blog-6029314890794802486.post-17008102624312039902010-12-23T12:24:00.003+02:002011-06-10T16:09:13.788+03:00

היסטורית, התחלנו בתוכנות (או אפליקציות), המשכנו בדפדפניזציה, וחזרנו לאפליקציות. הנה כמה דברים שיש לשים דגש בבדיקת אפליקציות בטלפונים חכמים. זהו רק קצה הקרחון כמובן - רק כמה טיפים קטנים. כאן אני מדבר על אפליקציות client – server אמנם, אבל חלק מהנאמר מטה נכון לכול האפליקציות:  1. יוזביליות. אני חושב שמי שמכיר את הנושא, בעזרת קצת common sense יוכל ליישם אותו בקלות בטלפון. הנה כמה טיפים: האם הגרפיקה

דורון ברhttp://www.blogger.com/profile/14499386811348993353noreply@blogger.com0tag:blogger.com,1999:blog-6029314890794802486.post-50003208410681253842010-11-10T11:48:00.003+02:002011-06-10T16:09:52.013+03:00

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

דורון ברhttp://www.blogger.com/profile/14499386811348993353noreply@blogger.com0tag:blogger.com,1999:blog-6029314890794802486.post-82713810076058190282010-11-03T09:26:00.003+02:002011-06-10T16:10:36.655+03:00

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

דורון ברhttp://www.blogger.com/profile/14499386811348993353noreply@blogger.com0tag:blogger.com,1999:blog-6029314890794802486.post-85265928003422043882010-10-18T21:00:00.002+02:002011-06-10T16:13:01.890+03:00

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

דורון ברhttp://www.blogger.com/profile/14499386811348993353noreply@blogger.com0tag:blogger.com,1999:blog-6029314890794802486.post-62331567499457449742010-10-11T13:19:00.001+02:002010-10-11T13:22:58.208+02:00

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

דורון ברhttp://www.blogger.com/profile/14499386811348993353noreply@blogger.com2tag:blogger.com,1999:blog-6029314890794802486.post-35409149310703785932010-10-06T17:14:00.000+02:002010-10-06T17:14:47.516+02:00

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

דורון ברhttp://www.blogger.com/profile/14499386811348993353noreply@blogger.com0tag:blogger.com,1999:blog-6029314890794802486.post-32505151469849027252010-09-15T14:26:00.002+02:002011-06-10T16:12:33.667+03:00

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

דורון ברhttp://www.blogger.com/profile/14499386811348993353noreply@blogger.com0tag:blogger.com,1999:blog-6029314890794802486.post-48004776156100749522010-09-06T16:58:00.000+03:002010-09-06T16:58:12.846+03:00

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

דורון ברhttp://www.blogger.com/profile/14499386811348993353noreply@blogger.com0tag:blogger.com,1999:blog-6029314890794802486.post-48759084940368614102010-08-29T15:28:00.002+03:002010-08-30T14:54:44.163+03:00

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

דורון ברhttp://www.blogger.com/profile/14499386811348993353noreply@blogger.com0tag:blogger.com,1999:blog-6029314890794802486.post-14806417208129583922010-08-19T07:32:00.008+03:002010-08-21T03:10:35.346+03:00

Http watch הוא לדעתי כלי חובה לכל בודק ומפתח ווב. זוהי ההגדרה שלו - מתוך האתר: HttpWatch is an integrated HTTP sniffer for IE and Firefox that provides new insights into how your website loads and performsהוא בעצם תוסף שמתלבש על הדפדפן וניתן להפעיל אותו לפי שיקול דעת.מה שהוא עושה בעצם הוא להציג כל קריאה או כל תעבורה מהדפדפן לכל מקום אחר. זהו אינו סניפר כמו הויירשארק שבודק את כל התעבורה, אלא

דורון ברhttp://www.blogger.com/profile/14499386811348993353noreply@blogger.com0tag:blogger.com,1999:blog-6029314890794802486.post-86722235295060660892010-08-08T12:54:00.006+03:002010-08-17T13:40:52.080+03:00

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

דורון ברhttp://www.blogger.com/profile/14499386811348993353noreply@blogger.com0tag:blogger.com,1999:blog-6029314890794802486.post-35124187970550225762010-08-01T09:32:00.003+03:002011-02-17T20:44:28.824+02:00

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

דורון ברhttp://www.blogger.com/profile/14499386811348993353noreply@blogger.com2tag:blogger.com,1999:blog-6029314890794802486.post-66836674629309155952010-07-25T09:41:00.000+03:002010-07-25T09:41:05.395+03:00

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

דורון ברhttp://www.blogger.com/profile/14499386811348993353noreply@blogger.com0tag:blogger.com,1999:blog-6029314890794802486.post-35888868733679264362010-07-18T08:39:00.001+03:002010-07-28T13:50:53.259+03:00

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

דורון ברhttp://www.blogger.com/profile/14499386811348993353noreply@blogger.com0tag:blogger.com,1999:blog-6029314890794802486.post-3241162591956084652010-07-11T10:10:00.000+03:002010-07-11T10:10:14.121+03:00

בתפקידי הראשון בתחום, ולמעשה בשבוע הראשון, בדקתי אפליקציה אשר מתממשקת ל-Outlook, כלומר אתה פותח את האאוטלוק ומוצא מודולים נוספים שאנחנו הכנסנו בתחום של CTI, שזה Computer Telephony Integration. בבדיקות הבחנתי בתופעה הבאה: אחרי שימוש ארוך של כמה שעות המודול שלנו באאוטלוק היה נתקע. ללא ניסיון, ידע תיאורתי או מנהל שיכל לעזור לי, ניסיתי בתחילה פשוט "לשחק" במודולים שלנו. הבעיה השתחזרה, אבל לא היה

דורון ברhttp://www.blogger.com/profile/14499386811348993353noreply@blogger.com2tag:blogger.com,1999:blog-6029314890794802486.post-24492445423564963142010-07-04T10:49:00.000+03:002010-07-04T10:49:05.882+03:00

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

דורון ברhttp://www.blogger.com/profile/14499386811348993353noreply@blogger.com0tag:blogger.com,1999:blog-6029314890794802486.post-67417363572999988752010-06-27T11:36:00.000+03:002010-06-27T11:36:54.899+03:00

STR = Software/System Testing Resultd. יוצא פר גרסה ויש לשמרו חמש שנים אם רוצים לעבוד בהתאמה עם ה-ISO. מדוע צריך STR? STR נותן תמונת מצב של המוצר בעת השחרור. מבטיח שטסט קייסים לא יישכחו. מהווה תיעוד אחורנית, אם ירצו יום אחד לדעת מה היו הבאגים של גרסה כזו או כזו וכד'. אחריות:מנהל הבדיקות. מתי ממלאים את הSTR?בעצם כל הזמן. הוא אמור להיות מוכן לגמרי כשמסמכי הבדיקות גמורים לגמרי, ולהתמלא מיום

דורון ברhttp://www.blogger.com/profile/14499386811348993353noreply@blogger.com0tag:blogger.com,1999:blog-6029314890794802486.post-27067877002410932502010-06-21T11:54:00.001+03:002010-06-21T11:55:39.006+03:00

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

דורון ברhttp://www.blogger.com/profile/14499386811348993353noreply@blogger.com0tag:blogger.com,1999:blog-6029314890794802486.post-32133169395831674922010-06-14T11:41:00.003+03:002010-06-15T11:22:22.125+03:00

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

דורון ברhttp://www.blogger.com/profile/14499386811348993353noreply@blogger.com0tag:blogger.com,1999:blog-6029314890794802486.post-53238102734722676972010-06-07T17:39:00.012+03:002010-06-07T18:06:28.982+03:00

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

דורון ברhttp://www.blogger.com/profile/14499386811348993353noreply@blogger.com0tag:blogger.com,1999:blog-6029314890794802486.post-74262560791598908342010-05-26T19:41:00.009+03:002010-05-26T20:27:57.288+03:00

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

דורון ברhttp://www.blogger.com/profile/14499386811348993353noreply@blogger.com0tag:blogger.com,1999:blog-6029314890794802486.post-65877359672822758422009-06-23T15:38:00.000+03:002009-06-23T15:39:00.568+03:00

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

גאיוס דרוסוסnoreply@blogger.com0tag:blogger.com,1999:blog-6029314890794802486.post-36832380255994157352009-03-10T12:02:00.012+02:002010-05-25T17:54:26.446+03:00

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

דורון ברhttp://www.blogger.com/profile/14499386811348993353noreply@blogger.com0tag:blogger.com,1999:blog-6029314890794802486.post-13567552596888555752008-10-05T11:45:00.002+02:002008-10-05T11:47:01.697+02:00

חזור לרשימת הרשומות

דורון ברhttp://www.blogger.com/profile/14499386811348993353noreply@blogger.com0tag:blogger.com,1999:blog-6029314890794802486.post-82756105694084658792008-09-28T11:59:00.014+03:002011-12-05T22:52:08.700+02:00

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

דורון ברhttp://www.blogger.com/profile/14499386811348993353noreply@blogger.com0tag:blogger.com,1999:blog-6029314890794802486.post-4271781739473039282008-09-21T16:04:00.004+03:002011-06-06T22:29:40.488+03:00

שוב חריגה מגבולות בדיקות התוכנה "נטו" (כמו במאמר על ה-UT) לראייה כללית יותר של איכות המוצר (וממילא אינטרס שלנו הבודקים). הגדרה: * בדיקה מתודית והבנת הפעילות של הקוד. מטרות: * לוודא שהקוד כתוב לפי הסטנדרטים. * שאין שגיאות בקוד, לוגיות ואחרות. * שה-flow תקני ולפי ההגדרות. * מקרי גבול. * מעבר על בדיקות ה-UT המתוכננות. מתי? ה- Code Review הוא חלק מבדיקות ה-Unit Test, ויכול לבוא לפני הבדיקות

דורון ברhttp://www.blogger.com/profile/14499386811348993353noreply@blogger.com0tag:blogger.com,1999:blog-6029314890794802486.post-66070265799879418862008-07-22T11:28:00.000+03:002008-07-22T11:32:09.846+03:00

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

דורון ברhttp://www.blogger.com/profile/14499386811348993353noreply@blogger.com0tag:blogger.com,1999:blog-6029314890794802486.post-33596048910416806082008-07-16T11:27:00.000+03:002008-07-22T11:34:21.233+03:00

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

דורון ברhttp://www.blogger.com/profile/14499386811348993353noreply@blogger.com0tag:blogger.com,1999:blog-6029314890794802486.post-26398363205461233252008-07-11T14:28:00.002+03:002008-09-28T11:56:04.318+03:00

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

דורון ברhttp://www.blogger.com/profile/14499386811348993353noreply@blogger.com0tag:blogger.com,1999:blog-6029314890794802486.post-75898939085492470612008-07-07T15:16:00.000+03:002008-07-10T07:43:47.180+03:00

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

דורון ברhttp://www.blogger.com/profile/14499386811348993353noreply@blogger.com0tag:blogger.com,1999:blog-6029314890794802486.post-36734903302740770672008-07-03T11:56:00.000+03:002008-07-03T12:18:10.663+03:00

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

דורון ברhttp://www.blogger.com/profile/14499386811348993353noreply@blogger.com0tag:blogger.com,1999:blog-6029314890794802486.post-48657625722264675142008-06-29T16:28:00.001+03:002008-07-02T11:05:48.269+03:00

כידוע ככל שהבאג מתגלה מוקדם יותר, עלותו נמוכה יותר (קל לתקן אותו, מבזבז פחות שעות עבודה וכד' - וראו כאן). בדרך כלל כשמתייחסים לבאג ש"חרג" מאותה נקודה בתהליך שבה הוא היה אמור להמצא (נקרא גם escape) אז מתייחסים באג שלא אובחן בשלבי בדיקות הגרסה.אבל לא פחות חשוב לדעת אילו באגים "ברחו" גם בנקודות אחרות של התהליך:מסמכי שיווק;מסמכי מהנדס מערכת;מסמכי פיתוח;Unit tests;Private Integration;Integration Tests

דורון ברhttp://www.blogger.com/profile/14499386811348993353noreply@blogger.com0tag:blogger.com,1999:blog-6029314890794802486.post-69364295637291421212008-06-29T10:02:00.000+03:002008-06-29T13:35:34.912+03:00

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

דורון ברhttp://www.blogger.com/profile/14499386811348993353noreply@blogger.com0tag:blogger.com,1999:blog-6029314890794802486.post-87270651051706870552008-06-15T21:44:00.000+03:002008-06-15T21:50:48.232+03:00

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

דורון ברhttp://www.blogger.com/profile/14499386811348993353noreply@blogger.com2tag:blogger.com,1999:blog-6029314890794802486.post-2936000082830955302008-06-05T09:42:00.000+03:002008-06-05T10:41:35.453+03:00

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

דורון ברhttp://www.blogger.com/profile/14499386811348993353noreply@blogger.com0tag:blogger.com,1999:blog-6029314890794802486.post-55874778865486329742008-06-03T15:49:00.000+03:002008-06-03T16:52:11.105+03:00

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

דורון ברhttp://www.blogger.com/profile/14499386811348993353noreply@blogger.com0tag:blogger.com,1999:blog-6029314890794802486.post-38580931069201308092008-05-23T06:29:00.009+03:002011-06-07T19:29:41.986+03:00

סיכום מאמר:Ad hoc testing, Chris Argus & Bob Johnsonזהו מאמר ראשון שלי מתוך כמה שיבואו בעתיד בנושא ה-exploratory testing. המאמר שאני מסכם יכול לשמש כמבוא טוב שייתן מושג מהן בדיקות אלה. זה אינו מאמר חדש, וחסרונותיו עמו:שימו לב שהמילה "פרוגרסיה" אינה נזכרת בשום מקום. האם באמת "אד הוק" שווה תמיד ל"חד פעמי"? האם באמת זה עניין לבודקים מיומנים? איך אפשר ללמד את צוות הבדיקה לעשות את זה? האם בכ"ז ניתן

דורון ברhttp://www.blogger.com/profile/14499386811348993353noreply@blogger.com0tag:blogger.com,1999:blog-6029314890794802486.post-17647806241963391282008-05-13T13:00:00.000+03:002008-05-13T13:06:46.957+03:00

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

דורון ברhttp://www.blogger.com/profile/14499386811348993353noreply@blogger.com0tag:blogger.com,1999:blog-6029314890794802486.post-8689794168540524192008-05-09T12:37:00.002+03:002011-04-10T15:34:57.133+03:00

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

דורון ברhttp://www.blogger.com/profile/14499386811348993353noreply@blogger.com0tag:blogger.com,1999:blog-6029314890794802486.post-49002035182203504482008-05-07T10:30:00.000+03:002008-05-10T08:01:00.781+03:00

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

דורון ברhttp://www.blogger.com/profile/14499386811348993353noreply@blogger.com0tag:blogger.com,1999:blog-6029314890794802486.post-75070815396967612642008-05-04T15:37:00.001+03:002011-07-22T18:39:48.756+03:00

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

דורון ברhttp://www.blogger.com/profile/14499386811348993353noreply@blogger.com0tag:blogger.com,1999:blog-6029314890794802486.post-60572036885267219212008-04-28T10:01:00.001+03:002008-05-10T08:01:40.064+03:00

סיכום המאמר שיפור תהליך הבדיקות אינו מחייב.אני לא חושב שזהו מאמר מבריק, והוא חוזר על אותן הדוגמאות שוב ושוב, מה שמראה שהוא לא יושם כנראה באופן מלא ע"י מי שכתב אותו.יחד עם זאת, שווה לקרוא בכדי לקבל רעיונות.מה שבכחול - הערות שלי.Escape - הגדרה:escape מוגדר כבאג שעבר / לא התגלה בחדר הבדיקות אלא אצל הלקוח. כידוע באג שמתגלה בשלב זה מחירו הוא היקר ביותר. לשם כך יש לנתח את ה-escape בכדי להבין איך זה קרה

דורון ברhttp://www.blogger.com/profile/14499386811348993353noreply@blogger.com0tag:blogger.com,1999:blog-6029314890794802486.post-76382428977687202022008-04-23T08:33:00.000+03:002008-04-24T09:20:36.953+03:00

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

דורון ברhttp://www.blogger.com/profile/14499386811348993353noreply@blogger.com0tag:blogger.com,1999:blog-6029314890794802486.post-17208026091312049612008-04-21T12:45:00.000+03:002008-05-08T09:16:35.283+03:00

ה-STP הוא מסמך תכנון הבדיקות. הוא צריך להיות סגור ברגע שיש תכולה ברורה ולוחות זמנים, ואמור להיות מתוחזק במשך כל זמן חיי הגרסה.דבר אחד שלמדתי הוא: שאם אתה לא יודע איך למלא אותו, או שאתה לא סגור על המסמך, זה אומר רק דבר אחד: אתה לא סגור לגבי הבדיקות של הגרסה!ממה מורכב ה-STP?הערה: אני לא מתכוון להכנס לתהליכי כתיבת מסמך בכלל (רשימת שינויים, Reference וכו').דבר אחר: כיוון שה-STP אמור להיות מתוחזק, אני

דורון ברhttp://www.blogger.com/profile/14499386811348993353noreply@blogger.com0tag:blogger.com,1999:blog-6029314890794802486.post-9698455053131100932008-04-15T12:41:00.000+03:002008-05-07T16:42:58.322+03:00

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

דורון ברhttp://www.blogger.com/profile/14499386811348993353noreply@blogger.com0tag:blogger.com,1999:blog-6029314890794802486.post-66404408053991826382008-04-09T15:11:00.000+03:002008-05-09T12:06:42.768+03:00

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

דורון ברhttp://www.blogger.com/profile/14499386811348993353noreply@blogger.com0tag:blogger.com,1999:blog-6029314890794802486.post-57479202928795313632008-04-09T10:36:00.000+03:002008-06-30T20:24:48.162+03:00

הרשימה הסופית כוללת תוספות רבות של קובי הלפרין כפי שהופיעו כאן.Preparations and format:01. Were all the requirements identified and listed while preparing the TD?02. Does the traceability matrix exist as a part of the document or referenced from the TD?03. Is every requirement covered by at least one test group in the TD?04. Was the TD written in accordance with the template?05. Was the TD

דורון ברhttp://www.blogger.com/profile/14499386811348993353noreply@blogger.com1tag:blogger.com,1999:blog-6029314890794802486.post-17952448140116920792008-04-08T14:58:00.000+03:002008-07-10T12:37:09.773+03:00

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

דורון ברhttp://www.blogger.com/profile/14499386811348993353noreply@blogger.com0tag:blogger.com,1999:blog-6029314890794802486.post-87078409286219287282008-04-05T10:39:00.000+03:002008-05-07T16:39:48.672+03:00

כיום יש כלים טובים (למשל ב-Quality Center) למעקב אחרי דרישות. אני אתייחס לצדדים החשובים, תהא ההטמעה אשר תהא.אביא כאן את העיקר:כל הדרישות חייבות לבוא משלב ה-MRD עם סעיפים, סעיף פר דרישה, ת-סעיף לתת-דרישה, וכל סעיף צריך להיות עם סמן ייחודי (נניח MRD-403-24-001, MRD זה המסמך, 403 זו הגרסה, 24 הסעיף ו-01 הוא תת-הסעיף). מומלץ לקפוץ בין מספרים בהפרש מסויים, למשל מ-01 ל-05, למקרה שמשהו ישכח.יש למפות כל

דורון ברhttp://www.blogger.com/profile/14499386811348993353noreply@blogger.com0tag:blogger.com,1999:blog-6029314890794802486.post-44504643809904578702008-04-03T09:33:00.000+03:002008-04-22T16:39:57.591+03:00

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

דורון ברhttp://www.blogger.com/profile/14499386811348993353noreply@blogger.com0tag:blogger.com,1999:blog-6029314890794802486.post-16280462659475894942008-04-01T14:15:00.000+03:002008-05-07T16:30:21.782+03:00

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

דורון ברhttp://www.blogger.com/profile/14499386811348993353noreply@blogger.com0tag:blogger.com,1999:blog-6029314890794802486.post-9865765991586185382008-03-25T12:14:00.000+02:002008-05-07T16:41:51.623+03:00

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

דורון ברhttp://www.blogger.com/profile/14499386811348993353noreply@blogger.com0tag:blogger.com,1999:blog-6029314890794802486.post-78456132696824729172008-03-23T13:55:00.000+02:002008-05-08T09:10:12.794+03:00

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

דורון ברhttp://www.blogger.com/profile/14499386811348993353noreply@blogger.com2tag:blogger.com,1999:blog-6029314890794802486.post-73253381365219086052008-03-18T13:29:00.002+02:002011-06-07T19:34:27.450+03:00

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

דורון ברhttp://www.blogger.com/profile/14499386811348993353noreply@blogger.com3tag:blogger.com,1999:blog-6029314890794802486.post-71229680424739790302008-02-28T10:44:00.001+02:002011-06-06T08:14:22.076+03:00

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

דורון ברhttp://www.blogger.com/profile/14499386811348993353noreply@blogger.com0tag:blogger.com,1999:blog-6029314890794802486.post-42306267155459465042008-02-26T12:32:00.002+02:002011-06-06T08:12:44.319+03:00

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

דורון ברhttp://www.blogger.com/profile/14499386811348993353noreply@blogger.com0tag:blogger.com,1999:blog-6029314890794802486.post-46821031635871188412008-02-24T12:14:00.000+02:002008-05-07T16:39:13.070+03:00

לא, אין כאן כוונה לשערים כמו בכדורגל, אלא לתהליך מסודר של העברת אחריות, או מעבר בין פאזות, בתוך תהליך הפיתוח.טרמינולוגיה:שער = gate, והישיבה = Readiness before X, כאשר X יכול להיות בדיקות.מהו השער?השער הוא בעצם ישיבה (אפשרי טלפונית, תלוי בבגרות התוכנה, פשטותה וכו') בין א' כשא' הוא זה שסיים שלב בתהליך הפיתוח, ל-ב', שאמור להמשיך את התהליך. מטרת הישיבה היא לוודא מהו המצב של הגרסה כפי שבאה לידי ביטוי

דורון ברhttp://www.blogger.com/profile/14499386811348993353noreply@blogger.com0tag:blogger.com,1999:blog-6029314890794802486.post-53313426312112999062008-02-20T09:14:00.000+02:002008-04-20T08:42:33.525+03:00

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

דורון ברhttp://www.blogger.com/profile/14499386811348993353noreply@blogger.com0tag:blogger.com,1999:blog-6029314890794802486.post-35182675573209416232008-02-17T12:20:00.000+02:002008-02-17T14:30:08.987+02:00

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

דורון ברhttp://www.blogger.com/profile/14499386811348993353noreply@blogger.com0tag:blogger.com,1999:blog-6029314890794802486.post-7751637304141401602008-02-13T12:29:00.003+02:002010-07-08T17:18:47.478+03:00

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

דורון ברhttp://www.blogger.com/profile/14499386811348993353noreply@blogger.com0tag:blogger.com,1999:blog-6029314890794802486.post-56968120579663717952008-02-12T07:38:00.001+02:002011-06-06T08:10:56.110+03:00

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

דורון ברhttp://www.blogger.com/profile/14499386811348993353noreply@blogger.com1tag:blogger.com,1999:blog-6029314890794802486.post-66106649697483010302008-02-07T13:29:00.013+02:002011-04-07T18:07:10.046+03:00

Ad Hoc Testing - Testing carried out using no recognized test case design technique. ATP - Acceptance Test: Tests that are sometimes performed by a customers to determine whether or not a system has satisfied predetermined acceptance criteria. These tests are often used to enable the customer (either internal or external) to determine whether or not to accept a system. Escape - a defect that was

דורון ברhttp://www.blogger.com/profile/14499386811348993353noreply@blogger.com2tag:blogger.com,1999:blog-6029314890794802486.post-69901469108657685692008-02-06T16:23:00.002+02:002010-07-08T11:41:21.871+03:00

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

דורון ברhttp://www.blogger.com/profile/14499386811348993353noreply@blogger.com5tag:blogger.com,1999:blog-6029314890794802486.post-46955206140717619702008-02-06T16:06:00.000+02:002008-11-13T23:04:48.278+02:00

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

דורון ברhttp://www.blogger.com/profile/14499386811348993353noreply@blogger.com2tag:blogger.com,1999:blog-6029314890794802486.post-51139809473996910662008-02-05T16:18:00.001+02:002010-07-08T11:38:11.098+03:00

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

דורון ברhttp://www.blogger.com/profile/14499386811348993353noreply@blogger.com0tag:blogger.com,1999:blog-6029314890794802486.post-21847967400197534872008-02-05T16:08:00.003+02:002010-07-08T11:27:57.766+03:00

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

דורון ברhttp://www.blogger.com/profile/14499386811348993353noreply@blogger.com3tag:blogger.com,1999:blog-6029314890794802486.post-55820855102045271552008-01-29T17:52:00.001+02:002010-07-08T11:16:14.057+03:00

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

דורון ברhttp://www.blogger.com/profile/14499386811348993353noreply@blogger.com0tag:blogger.com,1999:blog-6029314890794802486.post-56937133078667938122008-01-29T17:21:00.001+02:002010-07-08T11:15:35.616+03:00

1.The process of executing a program with the intention of finding errors.2.The purpose of testing is to discover errors. Testing is the process of trying to discover every conceivable fault or weakness in a work product.3.Process of evaluating a system or a component to determine whether the product of a given development phase satisfies the conditions imposed at the start of that phase. *SUT -

דורון ברhttp://www.blogger.com/profile/14499386811348993353noreply@blogger.com1tag:blogger.com,1999:blog-6029314890794802486.post-22894288925047735052008-01-29T17:12:00.001+02:002011-04-06T10:45:54.083+03:00

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

דורון ברhttp://www.blogger.com/profile/14499386811348993353noreply@blogger.com4tag:blogger.com,1999:blog-6029314890794802486.post-29694960174521101562008-01-29T16:55:00.001+02:002010-07-08T11:15:01.375+03:00

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

דורון ברhttp://www.blogger.com/profile/14499386811348993353noreply@blogger.com1tag:blogger.com,1999:blog-6029314890794802486.post-32370496863528386772008-01-29T16:38:00.000+02:002008-05-20T08:16:55.243+03:00

אני לא בא כאן כמומחה לענייני גוגל, או כמנהל אתרים מדופלם, אלא רק כאחד שמסכם לעצמו את הידע שלו. כלומר הרשומה מיועדת לא למקצוענים.כדאי להתחיל כאן:ויקי, קידום אתרים במנועי חיפושגוגל, מידע על Google למנהלי אתריםYnet, קידום אתרים, אמיתות ומיתוסיםYnet, כלים מומלצים ל-SEOנענע, לך תתקדםNetwise, אופטימיזציה למנועי חיפוש (SEO)פורום: קידום אתרים אורגני, מנועי חיפושהמונח : SEO: Search Engine Optimizationלפי

דורון ברhttp://www.blogger.com/profile/14499386811348993353noreply@blogger.com1tag:blogger.com,1999:blog-6029314890794802486.post-60029607139058467022008-01-29T16:31:00.007+02:002011-05-27T17:07:46.027+03:00

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

דורון ברhttp://www.blogger.com/profile/14499386811348993353noreply@blogger.com9