יום ראשון, 25 ביולי 2010

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


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

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

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

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

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

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

יום ראשון, 18 ביולי 2010

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

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

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

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


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

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

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


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

יום ראשון, 11 ביולי 2010

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

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

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

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

יום ראשון, 4 ביולי 2010

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

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

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

רשומות פופולריות