הצהרות הQA

[erandd]

הצהרות הQA

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

 

[neko]

תאורטית זה לא נכון,

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

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

 

[erandd]

טוב אם זה לא נכון

בואי תשלחי לי קטע קוד מדובג לחלוטין

 

[erandd]

סליחה הכוונה לתשלח

 

[JohnDoe5]

בבקשה

using System; using System.Windows.Forms; namespace ConsoleApplication1 { class Class1 { [STAThread] static void Main(string[] args) { MessageBox.Show("Hello"); } } }

 

[JohnDoe5]

דעתי האישית

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

 

[Admini]

ואם ה-Framework לא מותקן ?

 

[JohnDoe5]

ואם אתה מריץ את זה על לינוקס ?!

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

 

[Admini]

דווקא על לינוקס זה אמור לעבוד(mono)

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

 

[JohnDoe5]

ואם אתה מריץ את זה על לינוקס ?!

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

 

[erandd]

דוגמאות

מה עם שפות זרות: האפליקציה נדרשת להודיע גם בגרמנית ובעברית סינטקס: יכול להיות שהסוגריים סביב HELLO לא תואמים? תאימות מערכת הפעלה: לא יעבוד בלינוקס תאימות דפדפן: יעבוד על OPERA? תאימות גרסת דפדפן: יעבוד על EXPLORER 4?

 

[JohnDoe5]

כפי שציינתי, לא תפקיד ה-QA

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

 

[vinney]

מתי יש?

מתי יש הגדרה מדויקת לכל הסוגיות האלה? נראה לי מאוד דמיוני פרוייקט בו כל זה יוגדר על ידי מנהלת הפרוייקט עם תחילת הפיתוח. רוב הדברים נסגרים בסוף הפרוייקט, לאחר שעלו כבאגים. למשל - אני אישית כתבתי פרוייקט לא קטן שאמור היה לרוץ על מס' מערכות הפעלה. אבל מה, מסתבר, בסוף, במהלך הבדיקות, שהוא לא עובד על מערכת הפעלה של IBM, זאת למרות שהיא POSIXית לחלוטין. למה? כובע. כי פיתחתי על HP. תוכנן מראש? לא. באג? ועוד איך. דוגמא נוספת - מאותו פרוייקט : פיתחנו עם מס"ד נתונים של ORACLE. מתי גילינו שגרסת הORACLE חייבת להיות 8i ולא 9i? בשלב הבדיקות. תוכנן מראש? בטח שלא, ORACLE מבטיח backward compatibility. באג? ועוד איך. למה? כי פיתחנו עם OCI שלא נתמכת על ידי ORACLE רשמית, אבל קיצר לנו תהליכים. אף אחד מהבאגים האלה לא היה באשמתי, כמתכנת, אני חייב לציין. שניהם פרי החלטה ניהולית של כלים בהם נשתמש, אבל המחקר (שאני מודה, אני עשיתי) לא היה מספק ולא העלה את סוגיות התאימות שבנינו עליהן... בסופו של דבר הוצאנו גרסה עם שני הבאגים, הבטחנו ללקוחות לקתן אותם בגרסה הבאה, זאת משום שתיקון הבאגים האלה היה כואב וארוך מאוד, למרות שתכל'ס זה נשמע משהו פשוט לגמרי. אז לא כל דבר אפשר לתכנן, וגם אם מתכננים, לא כל דבר מתקיים לפי התכנון.

 

[JohnDoe5]

אתה לא טועה

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

 

[vinney]

אתה כן טועה

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

 

[erandd]

דווקא כן

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