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

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

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

2. בדיקה על מספר מערכות הפעלה.

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

4. הודעות שגיאה: פונקציונאליות וקישורים לשרת.

5. בדיקות שליליות: ערכי קצה, מעברים מהירים, פתיחה מחודשת זריזה של האפליקציה וכד'.

6. מה קורה בקבלת/דחיית/ שיחה או בייזום שיחה בזמן שאנו משתמשים באפליקציה. כנ"ל לגבי SMS.

7. התקנה והסרה.

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

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

כמה כללים למצגת אפקטיבית

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

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

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

• מטרתנו היא לשכנע את היושבים מולנו במשהו. כל עמוד שאתם מסיימים לכתוב, תקראו שוב ותסבירו לעצמכם למה כל משפט תורם למטרה הכללית. אם הוא לא עושה את זה - נסחפתם. תמחקו אותו.
• אף פעם אל תניחו מראש שתצליחו במטרה.
• אם המטרה חשובה, או אם ברור מראש שתוכן המצגת לא יתקבל על הכל, או אפילו עלול לפגוע בחלק מהאנשים שיהיו בפגישה - דברו איתם לפני. הראו להם, אם צריך, את המצגת. עשו קואליציות והגיעו להסכמות עם אלו שיוצאים פחות טוב. אם אתם רוצים לשכנע, עדיף שתדברו עם לפחות חלק מהמוזמנים לפני, תציגו את מה שרציתם, קבלו פידבקים, תקנו את מה שצריך. אין לכם מושג (או שכן) כמה נעימה יכולה להיות ישיבה כזו. תחשבו על זה.
  לא, אנשים טכנים יקרים, אני לא מתכוון לוותר על מה שיש לכם לומר. ממש לא. אבל אם אתם מציגים lesson learned ואומרים שבעייה עיקרית היא בזמני הפיתוח, ואלה יתחממו ויענו לכם שאתם לא פחות בעייתיים ויתחיל ויכוח, וזאת מול כל הקודקודים - כולם מפסידים. מצטער, לפעמים פוליטיקה, או יש כאלה שיאמרו התחשבות, זה דבר הכרחי.
• אם אתם מנסים לשכנע במשהו: אנשים יקבלו את מה שאתם "מוכרים" לא בגלל שהם דברים צודקים, לא כיוון שהם מועילים לחברה, לא כי אתם חכמים, לא כי אתם יפים. אנשים יקבלו את מה שאתם אומרים בגלל ידידה טובה שלי, אמילי שמה. ומה אמילי אומרת? - אני, מה יצא לי (מזה)? ככל שפנימו את זה יותר מהר כך זה יעזור לכם יותר.
  הכוונה אינה בהכרח טובות הנאה אישיות, אני מקווה שלא, אלא דברים כמו מידע אמין וזמין, חסכון בשעות עבודה וכד'.
• הטקסט על המצגת לא נועד להעביר את כל הוראות השימוש של המוצר / יומן יומיומי של גרסה וכד'. הטקסט בכל דף נועד להכיל את הדברים החשובים שאת רוצה להעביר בנושא זה, הדברים שעל הנוכחים לזכור. הסיכום כביכול. נ-ק-ו-ד-ה. אף אחד לא יקרא את כל מה שאתם אומרים - כי אתם אומרים את זה ממילא. איש לא יזכור את כל מה שאתם אומרים גם אם זה רשום (במלואו). אולי זה יפריע להם להתרכז בהרצאה אם הם יקראו את הטקסט.
  לדוגמא: אם הכוונה בדף זה היא לומר שכלקח הקטנו את ה-down time במעבדה: הסבירו איך, תגידו מה יש היום מול מה שהיה, אבל הטקסט צריך להיות:
  - הכנסנו נהלים חדשים:
    - אודיט לפני הבדיקות.
    - הכנסת רמת העדיפות על כל קריאה לצוות הטכני.
    - הרצה אוטומאטית קבועה של בדיקת המערכת.וכו'.
  בע"פ תסבירו מה זה האודיט הזה (לא זו לא מישהי מהודו), מה טוב בעדיפויות וכד'.
• לבוא לבוש מסודר. לא להחזיק משהו בידיים לאורך זמן, לא להחזיק ידיים בכיסים. האמינו לי שידים בחוץ מרגיש פחות טוב, אבל נראה טוב יותר. לא לזוז כאחוזי תזזית. מומלץ: להסריט את עצמכם כמה דקות מציגים בפרטיות ולראות את התוצאה.
• הצג את עצמך ואת תפקידך. אם צריך - כמה מילים על ניסיונך.
• עליך לערוך חזרות חוזרות ונישנות. אתה לא אמור להסתכל על המצגת בזמן ההצגה (חוץ מכאשר אתה מעביר עמודים).
• אם הזמן הוא שעה, וודא שלבד בחזרה אתה מסיים תוך 45 דקות.
• עמוד בזמנים בזמן אמת.
• לדאוג שכל, אבל כל אחד בחדר מקבל קשר עין.
• אל תדבר רק לכיוון אחד של הקהל.
• לא להסחף למקומות לא רצויים. אפשר לשאול, אפשר לענות, אבל הישיבה מנוהלת על ידכם.
• לחייך מידי פעם, להכניס גוונים לקול. כדאי לערב את הקהל בשאלות.
• להגיע לפחות 15 ד' לפני ולוודא שהכל עובד (מקרן, רשת, USB, שיש מפתחות לחדר ישיבות).
• לבוא עם העתק של הפרזנטציה. אם תהיה הפסקת חשמל או תשרף הנורה של המקרן - עדיין יהיה שלד ההרצאה בידיך.
• לוודא שכל המצגת היא באותם פונטים, ובכמה גדלים קבועים (כלומר אם הכותרת היא פונט בגודל 16, שיהיה אותו הגודל בכל עמוד).
• בעמוד הראשון, שער, ובו הנושא בשורה וגם שמו של המציג.
• לא יורדים שורות! כאמור למעלה, רק משפטים קצרים של מהות העניין צריכים להיות מוגשים. אנשים פשוט לא יזכרו יותר (ואולי גם לא את זה!).
• כל מונח שעשוי לא להיות ברור: תנו הגדרה (אפילו בתחתית העמוד). לא תמיד אנשים יטרחו לשאול.
• נסו להבין אילו שאלות עשויות להישאל ונסו לתת עליהן מענה.
• אם אתם מכניסים נתונים הבאים ממקור מסויים, או בכלל יש הרחבות חשובות לנושאים שעליהם אתם מדברים, אבל שלא חייבים להיות במצגת (ששוב - אמורה להיות קצרה ולעניין) - שימו אותם בדפים בסוף, אחרי עמוד הסיכום והתודה. ואם איזה נודניק ישאל: רגע, איך אתם יודעים? -בבקשה הנה מלא המידע. חשוב בכ"ז לא להיגרר מצד שני למקומות שאתם לא רוצים להגיע אליהם.
• כל דף אמור להכיל את ידידתנו אמילי. זה הכי חשוב.
• בסוף - סיכום קצר של עד שלשה נושאים מרכזיים מרכזיים. ואמילי.

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

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

• קודם כל אם באמת הכוונה להציג למישהו, אז צריך להחליט מראש מה היו בדיוק הסנריו שיוצגו, ולעשות את מרב הבדיקות עליהם ועל סביבתם הקרובה. אבל זו הייתה רק דוגמא.
• 30 דקות: כן חשוב לדבר עם מנהל המוצר ולהבין את מטרת המוצר, שימוש "רגיל" של משתמש קצה וכד', לרשום שימושים חשובים / נפוצים.
• 30 דקות: לדבר עם הפיתוח (שמן הסתם יודע יותר מאיתנו כי בלי להסביר לו הוא לא יוכל לפתח) שבוודאי יודע היכן המקומות הפגיעים ומה חשוב שיתבצע. לצרף לרשימה הקודמת.
• לנסות לקבל כמה שיותר expected results שאפשר מהגורמים לעיל.
• 15 דקות: לסגור את הרשימה של הדברים חשובים ביותר לבדיקה ולסדר לפי סיכונים.
• לוודא שכולם בסביבה וזמינים לעזרה מיידית.
• 45 דקות: מעבר ראשוני על התוכנה. פשוט לעבור עמוד עמוד, תפריט תפריט, ובזריזות. נכון שזה נשמע כמו בזבוז, אבל זה ייתן לך קצת פרספקטיבה על המוצר ויאתר בעיות בסיסיות ביותר. אפילו פונקציה חשובה פחות כמו מה חדש תתגלה כחשובה מאוד אם היא מקריסה את המערכת או מראה טקסט של מפתח משועמם שהיה צריך לכתוב כמה מילים כתופסי מקום והא כתב משהו על המקצוע של אחותו של העמית שלו.
• עברו שעתיים יקרות מאוד, כי בעיות צריך לתקן ואח"כ לבדוק, אז מתחילים לחפור. מתחילים בפעולות קלות ועוברים לקשות. רבע שעה ראשונה עדיף שר"צ הפיתוח או מנהל המוצר יישבו איתך ופשוט יעקבו אחריך. את התוצאות צריך לשמור, אפילו ב"קצרנות" על נייר. כל דבר שלא ברור תוך 5 דקות - בניגוד לבד"כ כשמומלץ לנסות ולהבין יותר לעומק - ללכת לפיתוח/מנהל המוצר ולשאול. כל באג - לכתוב ולתת עדיפויות. באג שחייבים לתקן, ללכת במיידי לפיתוח, להציג, לוודא הבנה ושהתיקון מיושם במקום, לחזור ולהמשיך בבדיקות.

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

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

מקרים מהחיים: חשיבותן של מדידות

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

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

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

קומברס

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

1. ניפטר מהטריוויאלי: כיוון שאת לא רוצה עוד אלפי מחפשי עבודה.
2. כיוון שמרבית האנשים בחברה היו מקצועיים לעילא ועילא, בעלי ראש גדול ואיכפתיות. ואני אומר את זה לא בקלות, כי אני לא אוהב משפטים כלליים מהסוג הזה. מה שאומר שהבעייה בקומברס היא בראש. לא פלא שאנשים טובים כמו זאבי ברגמן וירון צואלה לא שם. לא עבדה שם שיטת ה"יהיה בסדר" - דברים תוכננו מראש, סיכונים נלקחו בחשבון. כל כך נדיר במקומותינו. חבל על האנשים הטובים האלו. אבל אני מאמין שהם ימצאו עבודה בקלות, וראי סעיף 1.
3. כיוון שזה היה בי"ס לכל מי שעבד שם. גם המקצוענות של העמיתים שלך, גם התהליכים המסודרים, שיטות העבודה החדישות, המונחים שלמדת. אם יש משהו שאני יודע על ניהול, למדתי אותו בקומברס, בעיקר מאנשים כמו רונית ליניק, קרן עידן.
4. כיוון שבקומברס אם היית בא עם רעיון לשיפור, אפילו לא פשוט, היו מתייחסים לזה בראש פתוח, ולא מייללים שאין זמן ליישם את זה. למעשה, דברים הבאת דברים כאלו היו קרש קפיצה בקריירה.
5. כי האתגר המקצועי היה אדיר.
6. כיוון שבזמנים הטובים זו הייתה גאווה להיות חלק ממכונה משומנת וענקית זו.
7. כי היה הרבה action והרבה אחריות.

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

ביקורת תוכנה: פיירוול של קומודו

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

ביקורת תוכנה: net limiter 2 PRO

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

האם הווב מת והאינטרנט הוא מחליפו?

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

ביקורת כלי: Cookie Editor - עורך קבצי "עוגיות"

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

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

מי שצריך לערוך עוגיות של אדובה, הרי הקישור הבא:
http://www.macromedia.com/support/documentation/en/flashplayer/help/settings_manager07.html
או תוכנה בשם Sol editor.

המלצה לכלי: HTTP WATCH

Http watch הוא לדעתי כלי חובה לכל בודק ומפתח ווב.
זוהי ההגדרה שלו - מתוך האתר:

HttpWatch is an integrated HTTP sniffer for IE and Firefox that provides new insights into how your website loads and performs

הוא בעצם תוסף שמתלבש על הדפדפן וניתן להפעיל אותו לפי שיקול דעת.

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

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

מה אפשר לעשות איתו?

הנה רק כמה דוגמאות:

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

לטייל בעולם בלי לקום מהכיסא: המלצה על פרוקסי (Proxy)

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

יש ברשת כמה אפשרויות. למשל אפשר למצוא רשימות של פרוקסים חינמיים, אבל בד"כ הן לא שוות את המאמץ ואולי אף מסוכן להשתמש בהן..
פרוקסי אחד בתשלום שאפשר לסמוך על האמינות שלו הוא http://www.xroxy.com/. אפשר לבחור מכמה מיקומים ואז לשלם בתשלום קבוע אחד, וללא הורדת תוכנה.
אבל הפרוקסי הטוב ביותר שגיליתי עד כה הוא זה: http://www.hidemyass.com.
באתר יש אפשרות להתנסות איתו מתוך האתר, ולדעתי זו טעות כי אם קונים את השירותים שלו מקבלים משהו אחר לגמרי והרבה יותר טוב: זהו חיבור VPN למגוון רחב של שרתים הממוקמים בכמה מדינות בארה"ב, קנדה ואירופה. ניתן להתחבר למיקום ולהחליף כתובת IP ידנית או בכל פרק זמן מסוים שאתה קובע.
אגב יש להוריד תוכנה בכדי שזה יעבוד.
החסרון שלו הוא שיש כמה פעולות שלפעמים אי-אפשר לבצע. במקרה שלי: הרשמה לאתר. אבל שוב - בסה"כ הוא עושה את העבודה.
חסרון אחר: כל העבודה שלך היא מול הפרוקסי, ולא רק שימוש בדפדפן מסוים.

כמה טיפים כלליים בשימוש בפרוקסי בכלל:
כשמשנים את ההגדרות ב-Internet Explorer בכדי להתחבר לפרוקסי, בעצם כל המחשב עובד מול הפרוקסי. לעומת זאת ב-Firefox ניתן לשנות כך שיעבוד רק בשימוש בו.
אם אתם עושים שינויים באתר שלכם ולא רואים את השינוי ייתכן שאובייקטים מסויימים נשמרים ב-קש של הפרוקסי בכדי לחסוך לו זמן טעינה.
העבודה עם פרוקסי בד"כ איטית יותר בגלל התיווך.
בשביל לבדוק שאתם מחוברים ממקום אחר: http://www.ip2location.com/.
כדאי אחרי ההתחברות לסגור ולפתוח את הדפדפן מחדש - ליתר ביטחון.

Hide my ass!

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

חידה: מי יודע מאיזו מדינה ה-IP הזה: 127.0.0.1?

Agile: SCRUM אגייל: סקראם

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

חלק מהעקרונות:

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

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

SCRUM – דרך ליישם AGILE
Framework for none predictable complex projects

בתחילת התהליך ניצב באקלוג (backlog) של המוצר: סך הפיצ'רים שרוצים להכניס למוצר.

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

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

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

ככל המחזור הפיתוח קצר יותר כך הספרינטים אמורים להיות קצרים יותר. אמורים להיות מ-4 עד 12 ספרינטים למחזור פיתוח אחד.

כיוון שכל עיכוב בספרינט אחד יעכב את הספרינט הבא יש לעקוב אחרי ההתקדמות בעזרת ה-burn-down chart. מדידה יומית של שארית העבודה, אמור להגיע לאפס. ציר ה-X הוא תאריכים, ה-Y – שעות שנותרו. בעזרת CHART זה קל למדוד קצב התקדמות או velocity. אם למשל הצוות עושה ביום 50 שעות ויודעים שנותרו 150 שעות לסיום הפרוייקט קל למדוד את הזמן הנותר לספרינט או RELEASE.
איך מחשבים: בכל ספרינט יש הערכת זמנים פר פיצ'ר. בסוף כל יום המשתתפים מעדכנים את הזמן הנותר.

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

המלצה שבסה"כ ישתתפו בספרינט 5-9 אנשים.

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

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




מקורות:

http://www.youtube.com/watch?v=Q5k7a9YEoUI
http://he.wikipedia.org/wiki/פיתוח_תוכנה_זריז
http://en.wikipedia.org/wiki/Agile_software_development

הבעיה של בדיקה רק לפי תסריט

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

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

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

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

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

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

בסופו של דבר, אלו הנתונים:

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

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

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

ניהול מעבדות בדיקות חומרה / תוכנה

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

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

• לאיזו מעבדה המחשב שייך.
• השימוש שלו.
• מע' ההפעלה שלו.
• השם שלו ברשת.
• ה-ip שלו.

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

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

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

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


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

באג ה-32, או: איך לבודד באג

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

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

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

לקח: האם בפועל זה יעבוד?

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

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

מנהלי קומפוננטה

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

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

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

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

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

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

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

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

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

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

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

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

וכך היה גם כאן.

מקרים מהחיים: אחריות במערכת מורכבת

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

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

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

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

מהן הבדיקות ואיך עושים את זה?

לא מזמן כתבתי על בניית קבוצת בדיקות.

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

מצ"ב פרזנטציה שכתבתי בדיוק בשביל זה. מטרתה:

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

- להסדיר נהלי עבודה חדשים.

- תיאום ציפיות.

- לקבל התחייבות לתהליכים החדשים.

מצ"ב לינק למצגת.

מה קורה כשלא ברור לאף אחד מאין לעזאזל נובע הבאג?

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

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

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

2. הכנת דאמפ. בעת קריסת האפליקציה, המחשב מכניס לקובץ את המידע שיש לו בזיכרון השייך לאפליקציה http://en.wikipedia.org/wiki/Core_dump.
יתרונות: במקרה הטוב מיד ניתן לעלות על הבעיה.
חסרונות: לפעמים המחשב קורס ללא הדאמפ, לפעמים הוא ענק ולא ניתן למצוא בו ידיים ורגליים, ולפעמים הבעיה אינה עקבית וצריך לחכות כמה ימים.

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

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

5. ישיבת "סיעור מוחות" עם המומחים הטובים ביותר של החברה, TIER 4 של התמיכה והמפתחים עם רשימה מלאה של שינויים שנעשו הגרסה, כולל שידרוגי מערכות הפעלה, שינויים ברשת וכד'.

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

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

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

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

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