אתה משתמש בדפדפן מיושן. יתכן והאתר הנוכחי יוצג באופן שגוי, כמו כן אתרים אחרים ברשת.
אנא שדרג את הדפדפן או השתמש בדפדפן חילופי.
אנא שדרג את הדפדפן או השתמש בדפדפן חילופי.
בקרוב מאמר למתכנת איך לבדוק בעצמך
- פותח הנושא erandd
- פורסם בתאריך
בעיה עקרונית
כל יוצר עוור למגבלות של היצירה שלו. כותב הקוד עוור ברמה מסוימת לבעיות של הקוד שלו, עם כל הרצון הטוב שיכול להיות (ולמרבה הצער, מי מאיתנו שעבד בסביבה מסחרית לחוצה יודע שרצון טוב עלול להיות מצרך נדיר). יש הבדל שראוי לשים לב אליו בין QA ל- QC בהקשר הזה: QC = Quality Control = בקרת איכות: תהליך וידוא התאמה בין המפרט לבין המוצר בפועל. רוב מה שקוראים לו בארץ QA הוא למעשה QC QA = Quality Assurance = אבטחת איכות: וידוא התאמה של המוצר לשוק היעד. מי שעובד על הפרויקט כמאפיין או כמתכנת יכול לעשות, במקרה הטוב, QC - וגם זה בעייתי. כאשר מדובר בנושאי QA, כמו - חסר פיצ'ר כזה או אחר שלא מופיע ב- spec, או שה- layout של המסכים לא ברור (למרות שהוא תואם ל- spec), זה פשוט לא עובד. מי שיש לו את החוש כיצד לעשות את זה טוב, עושה את זה טוב מלכתחילה. ומי שחסר את החוש, לא יכול לשפוט את עבודתו שלו עצמו. יש מי שההכללה שאני עושה כאן לא מתאימה לו מן הסתם, והוא מסוגל באמת לבדוק את עצמו בצורה נאותה. יצא לי לעבור דרך עשרות פרויקטים, לעבוד עם מאות אנשים, מכל רמות היכולת - וההכללה הזאת מניסיוני דווקא די תואמת למציאות. והגדיל לעשות מישהו שעבדתי איתו, שהאשים את צוות ה- QA בבאגים, שכן "כשבדקנו את הדברים בעצמנו, לפני שהייתה מחלקת QA, לא היו כמעט באגים". נו, שוין. עם טיעון כזה אי אפשר להתווכח. מה שכן, יש עקרון שרצוי מאוד להנחיל למתכנתים שנקרא design for testability - בנה את כל המוצר מראש כך שקל יהיה לבדוק אותו. יש קצת תיאוריה מעבר לכותרת (אבל לא הרבה - מעבר לרעיון הכללי). למרבה הצער, זה לא מסתדר טוב עם רוב מתודולגיות הפיתוח האופנתיות, ולכן הסיכוי שנראה את זה נפוץ הוא אפסי.
כל יוצר עוור למגבלות של היצירה שלו. כותב הקוד עוור ברמה מסוימת לבעיות של הקוד שלו, עם כל הרצון הטוב שיכול להיות (ולמרבה הצער, מי מאיתנו שעבד בסביבה מסחרית לחוצה יודע שרצון טוב עלול להיות מצרך נדיר). יש הבדל שראוי לשים לב אליו בין QA ל- QC בהקשר הזה: QC = Quality Control = בקרת איכות: תהליך וידוא התאמה בין המפרט לבין המוצר בפועל. רוב מה שקוראים לו בארץ QA הוא למעשה QC QA = Quality Assurance = אבטחת איכות: וידוא התאמה של המוצר לשוק היעד. מי שעובד על הפרויקט כמאפיין או כמתכנת יכול לעשות, במקרה הטוב, QC - וגם זה בעייתי. כאשר מדובר בנושאי QA, כמו - חסר פיצ'ר כזה או אחר שלא מופיע ב- spec, או שה- layout של המסכים לא ברור (למרות שהוא תואם ל- spec), זה פשוט לא עובד. מי שיש לו את החוש כיצד לעשות את זה טוב, עושה את זה טוב מלכתחילה. ומי שחסר את החוש, לא יכול לשפוט את עבודתו שלו עצמו. יש מי שההכללה שאני עושה כאן לא מתאימה לו מן הסתם, והוא מסוגל באמת לבדוק את עצמו בצורה נאותה. יצא לי לעבור דרך עשרות פרויקטים, לעבוד עם מאות אנשים, מכל רמות היכולת - וההכללה הזאת מניסיוני דווקא די תואמת למציאות. והגדיל לעשות מישהו שעבדתי איתו, שהאשים את צוות ה- QA בבאגים, שכן "כשבדקנו את הדברים בעצמנו, לפני שהייתה מחלקת QA, לא היו כמעט באגים". נו, שוין. עם טיעון כזה אי אפשר להתווכח. מה שכן, יש עקרון שרצוי מאוד להנחיל למתכנתים שנקרא design for testability - בנה את כל המוצר מראש כך שקל יהיה לבדוק אותו. יש קצת תיאוריה מעבר לכותרת (אבל לא הרבה - מעבר לרעיון הכללי). למרבה הצער, זה לא מסתדר טוב עם רוב מתודולגיות הפיתוח האופנתיות, ולכן הסיכוי שנראה את זה נפוץ הוא אפסי.
מסכים איתך לגבי האוביקטיביות
נושא שנכנס חזק לשוק הוא UNIT TEST כלומר כתיבת קלאס בדיקה על כל קלאס קוד.כלומר יש התיחסות למתכנת הבודד שבודק בעצמו לפני שליחת קוד לQA יכול להיות שההפרדה הזו שבה המתכנת, כמו שתארת, סבור שהQA רק הרע את המצב, נובעת מכך שנוצרה ההפרדה, הלעיתים מלאכותית, בין כתיבת הקוד ובדיקת איכותו. אנשי QA רבים מתלוננים שאין להם מספיק זמן לבדוק את המוצר, אולי ע"י הכשרת המתכנת לבדיקת המודול הבדיד ניפטר מבאגים טיפשיים ונוכל להתרכז בבאגים היותר מהותיים שכמעט לא נבדקים: בעיות עומס, התאמה למערכות הפעלה שונות, בדיקות קצה וכו.
נושא שנכנס חזק לשוק הוא UNIT TEST כלומר כתיבת קלאס בדיקה על כל קלאס קוד.כלומר יש התיחסות למתכנת הבודד שבודק בעצמו לפני שליחת קוד לQA יכול להיות שההפרדה הזו שבה המתכנת, כמו שתארת, סבור שהQA רק הרע את המצב, נובעת מכך שנוצרה ההפרדה, הלעיתים מלאכותית, בין כתיבת הקוד ובדיקת איכותו. אנשי QA רבים מתלוננים שאין להם מספיק זמן לבדוק את המוצר, אולי ע"י הכשרת המתכנת לבדיקת המודול הבדיד ניפטר מבאגים טיפשיים ונוכל להתרכז בבאגים היותר מהותיים שכמעט לא נבדקים: בעיות עומס, התאמה למערכות הפעלה שונות, בדיקות קצה וכו.
זה נושא מעניין לסקר
כמה אנשים פה עושים Unit Test בכלל? כמה עושים זאת בצורה "דתית" (בדיקה לכל Class בלי יוצא מהכלל?) כמה עושים את זה לפני שכותבים את ה- Class עצמו (ע"פ Extreme Programming)? אישית אני מהלא-דתיים. בדיקות אחרי הקוד, ורק לדברים בסיסיים או שבירים. וחוץ מזה, אני מאמין שמסיבות חסרות הצדקה לחלוטין, Unit Test קיבל משקל בלתי פרופורציוני לתרומה שלו לאיכות מוצר, על חשבון בדיקות כוללות יותר. בין השאר, לדוגמא, אי אפשר לחשוף Race Conditions ע"י Unit Test, ולמעשה ע"י אף בדיקה אחרת אלא אם כן תוכננה ספציפית עבור אותו Race Conditions.
כמה אנשים פה עושים Unit Test בכלל? כמה עושים זאת בצורה "דתית" (בדיקה לכל Class בלי יוצא מהכלל?) כמה עושים את זה לפני שכותבים את ה- Class עצמו (ע"פ Extreme Programming)? אישית אני מהלא-דתיים. בדיקות אחרי הקוד, ורק לדברים בסיסיים או שבירים. וחוץ מזה, אני מאמין שמסיבות חסרות הצדקה לחלוטין, Unit Test קיבל משקל בלתי פרופורציוני לתרומה שלו לאיכות מוצר, על חשבון בדיקות כוללות יותר. בין השאר, לדוגמא, אי אפשר לחשוף Race Conditions ע"י Unit Test, ולמעשה ע"י אף בדיקה אחרת אלא אם כן תוכננה ספציפית עבור אותו Race Conditions.
Copyright©1996-2021,Tapuz Media Ltd. Forum software by XenForo® © 2010-2020 XenForo Ltd.