הקפצת שרשור הנחות סמויות

[0rib]

על הנחות סמויות בבדיקה ופיתוח

ישנן תמיד הנחות, הן בזמן בדיקה והן בזמן פיתוח, שלא מופיעות "על השולחן" באף מסמך, ובדרך כלל גם לא קוראים עליהן תיגר. צוין פה שאפשר להמנע מ- reordering של תעבורת UDP, שזו הנחה סמויה מקובלת (ולא נכונה). הנחה סמויה אחרת שיצא לי להפיל עליה הרבה מאוד תוכנות היא שזמן UTC=GMT של המחשב (זמן גריניץ' שאינו משתנה עם שעון קיץ/חורף) תמיד נע קדימה בקצב קבוע. הדגמה: העתיקו קובץ ב- Windows Explorer על Win2K בצורה שיקח הרבה זמן - קובץ ענק או לחילופין לדיסקט/רשת איטית). חכו עד שתהיה הערכת זמן (נאמר "עוד 3 דקות לסיום"). הזיזו את השעון אחורה, שעה (או יום), ותגלו שהערכת הזמן קופצת לאלפי שעות לסיום. אם אני מבין נכון את המנגנון בפנים, קיימת קפיצת זמן שתגרום לחילוק באפס - לא היה לי אף פעם זמן לרדת לשורש העניין. נאמר שאני צודק, והמתכנת לא התחשב במקרה כזה - באותו רגע האקספלורר יקרוס. ןאם אתם שואלים למה שזמן יחזור אחורה -- שעונים של מחשב הם מאוד לא מדויקים. מי שמפעיל סנכרון NTP רואה קפיצות זמן קדימה ואחורה מדי פעם (בימים עד חודשים הראשונים - תלוי במשטר הכיבוי/הדלקה של המחשב). עוד הנחה סמויה נפוצה בכמה שנים האחרונות: יש מספיק מקום פנוי בדיסק. הרבה תוכנות היום לא טורחות לבדוק אם כתיבה לדיסק הצליחה, וברוב ה- Testplans, אין בדיקה כזאת. ושאלתי לשרשור היא: אילו הנחות סמויות אתם מכירים, ש"נשכו" אתכם או אחרים בעבר? כאלה שלא נשכו (עדיין?)

 

[Rשף]

אצלינו יש לא מעט כאלה

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

 

[ScrollLock]

הנחות תמיד נושכות!

הנחות מתקבלות לרוב רק אחרי מחיר גבוה... ההנחה שנושכת אותנו שוב ושוב היא ש-"רק המודולים ששונו הושפעו מהשינוי". כמובן שלרוב ההשפעות מתגלות בכל מקום אחר שלא ציפינו לו ולכן, המסקנה המתבקשת היא: "Nothing is Impossible". ואם בתאריכים/זמנים עסקינן - בסביבת Client-Server (בפרוייקט מבוסס Oracle) תמיד נטינו לחשוב שה-Client מקבל את הזמן שלו מה-Server. טעות בסיסית! עד שלא חטפנו את זה לפנים לא הבנו למה המערכת עפה בתנאים מסויימים... המסקנה היתה, כמובן, לסנכרן את הפורמט בין השניים.

 

[Rשף]

רק המודולים ששונו הושפעו ../images/Emo6.gif

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

 

[אבי ע]

נכון... יש הנחות ויש הנחות ../images/Emo39.gif

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

 

[עפר פרת]

אחריות לאיכות

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

 

[erandd]

אז איך לדעתך ניתן להנחיל זאת

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

 

[Rשף]

אין תרופות קסם, זו תכונת אופי

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

 

[אבי ע]

נושא חשוב שבלב העיסוק שלנו ../images/Emo39.gif

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

 

[ScrollLock]

למה הנחות???

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

 

[אבי ע]

בוא נחדד את זה... ../images/Emo39.gif

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

 

[erandd]

מה רע בפינג פונג?

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

 

[אבי ע]

מעבר לגבול מסויים אין רע...

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

 

[אלון וינשטיין]

../images/Emo45.gif

אצלנו המפתחים (אנחנו) עושים Smoke Test לפני העברת הגרסה הלאה. יש כמה דברים שבודקים כל פעם (פעולות בסיסיות + פונקציונאליות חדשה/מתוקנת) -- אם הם לא עוברים עוצרים את ההעברה ל QA. זה חסר טעם.

 

[עפר פרת]

בלי הנחות

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

 

[erandd]

הקפצת שרשור הנחות סמויות

לפי בקשת אבי: הוקפץ שרשור הנחות סמויות

 

[אבי ע]

מחשב הלקוח זהה לשלנו... ../images/Emo39.gif

ואני מדבר כרגע על תחנת העבודה, ה-PC השולחני (Client). במחשב שלנו הותקנו כבר בעבר כל תוכנות הצד השלישי, כל מיני משתנים הוגדרו בהתקנות לקראת בדיקות קודמות, וכולי וכולי. המחשב שלנו הוא בהגדרות אזוריות מסוימות מבחינת פורמט תאריך, פורמט מספרים (הפסיק מול הנקודה העשרוניים, לבד, יכולים לשגע את כל המערכת), וכולי. במחשב שלנו יש תצורה מסויימת של כרטיס מסך ושל המסך עצמו, וכולי. שלא לדבר על מערכת ההפעלה שזה כמובן טריוויאלי אבל לעתים נשכח. הדרך להתגבר על כך: לייעד מחשב לצורך זה (לא המחשב האישי שלנו, עם כל אי הנוחות), ולבצע עליו לפחות שני סבבי בדיקות אחרי איתחול מלא של מערכת ההפעלה מאפס (מ-scratch, בעברית), והתקנת התוכנה במדויק לפי הוראות ועזרי ההתקנה שאנו נספק ללקוח: סבב אחד בשלב מוקדם, וסבב אחד בבדיקות האחרונות. לפחות לעשות בדיקות "שפיות" (Sanity) על המחשב הזה. להקפיד שהוא יותקן עם מערכת הפעלה כמו של הלקוח (גרסא, הגדרות אזוריות, תמיכה כן/לא בעברית וכולי). ככל הניתן, רצוי שחומרת המחשב הזה תהיה דומה למקובל אצל הלקוח המיועד. עוד לפני כן ובמקביל, שווה לבדוק את התוכנה על כמה מערכות הפעלה נפוצות אצל הלקוחות. לצורך זה אני מחזיק אצלי מחשבים קצת יותר ישנים שעליהם חלונות NT4, אלפיים, ואפילו 98 (לתמיכה בלקוחות מאד ותיקים ולא מעודכנים), לצד XP במחשב הממש אישי שלי.

 

[Rשף]

אם כבר הזכרת מערכות הפעלה

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

 

[אבי ע]

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

 

[erandd]

זה אחד המיזמים שאני מכניס כרגע

להגדיר סביבות עבודה פר לקוח זה כולל 5 מחשבים עם GHOST לכל השפות והגדרות לוקליזציה שרת WEB זהה להגדרות לקוח (גם ווב ספיר וגם JBOSS) שרת DB לפי המפרט שלו ועוד