גישת Poka-Yoke לאבטחת איכות.

[0rib]

גישת Poka-Yoke לאבטחת איכות.

גישת QA מעניינת, לדעתי. מצורפים לינקים. השם הוא ביפנית, למי שתוהה, צריך לבטא אותו Poh-kah Yo-kay.

 

[erandd]

תודה יוסף ללינקים

 

[ScrollLock]

לא הבנתי את הפרנציפ...

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

 

[0rib]

בערך

הרעיון הוא לבנות את התהליך ככה שלא תהיה אפשרות לטעות, עד כמה שאפשר. לדוגמא, ניהול הזכרון של Java אמור למנוע אפשרות של טעות בנושא ניהול זכרון אצל המפתח, ובמידה מסוימת מצליח. לגבי בדיקה, מערכת Coverage Testing יכולה לוודא שאכן תוכנית הבדיקה מכסה את התוכנה באופן סביר - וזה עוזר במיוחד לבדיקות ידניות, מפני שזה בודק בו זמנית שהתוכנית מקיפה מספיק, וגם שהצעדים בתוכנית הבדיקה אכן מולאו ולא "נשכחו". לגבי פיתוח באופן כללי, מערכת ניהול התצורה Aegis (ומן הסתם גם אחרות), לא מוכנה לקבל Check-In אם לא מקשרים אותו לבאג או בקשת תוספת - או אם זה מכשיל אחת מהבדיקות האוטומטיות (היא מריצה כדי לוודא). יתרה על כן, היא דורשת שתיקון באג ילווה בתוכנית בדיקה _נוספת_ על הקיימות, שתוכיח את קיומו של הבאג ותגיד "יש באג" על הגרסה שלפני ה- Check-In, ו-"אין באג" על הגרסה שאחרי ה- Check-In. זה עוזר מאוד למנוע רגרסיות. [כמובן שעם ההרשאות המתאימות ניתן לוותר על חלק מהשלבים, ולעיתים זה חיוני - למשל, הרבה פעמים בלתי אפשרי לכתוב תוכנית בדיקה שתחשוף Race Condition. אבל בתור ברירת מחדל, כל התנאים צריכים להתקיים]. לגבי ההמצאה של אינטל - ידוע ש- Great Minds Think Alike, אפילו בהפרש של 40 שנה (שים לב שרעיון היפני הוא משנות החמישים). לדוגמא, שמת לב שמשינה ו- Madness הלחינו אותם לחנים בהפרש של 10 שנים?

 

[erandd]

אנלוגיה מעניינת למשינה

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

 

[0rib]

זה הבסיס לתהליך מסודר

אם הכלי עושה את זה קל, אז זה בעיקר עוזר. Aegis, בדומה ל- ClearCase ובשונה מ- CVS, SourceSafe עובד על אוספי שינויים, מה שנהוג לכנות Changeset. שינוי שעושים לו Check-In לא צריך להיות מוגבל לקובץ אחד או מודול אחד - הוא יכול להיות גורף (לדוגמא, יכול להיות שינוי של אות אחת בכל אחד מהקבצים של הפרויקט). אם לא היה תהליך רשמי של בקשת תוספת, אז Aegis יעצור אותך מלבצע Check-In באותו רגע, ומה שתאלץ לעשות הוא לפתוח Issue חדש, שמתאר את השינויים, ולקשר אליו (אם זכרוני אינו מטעני, ניתן לעשות זאת במשולב, במסגרת פקודת ה- Check-In. היתרון של זה הוא שגם מי ש*לא* קורא את הקוד, יודע מה השינויים. לכל איש QA יצא, מן הסתם, להתקל במצב שבו התנהגות של התוכנה שונתה בלי שום אזהרה מוקדמת או תיעוד מחוץ לקוד. החובה לקשור check-in ל- Issue עוזרת קצת להמנע מהמצב הזה. כמובן שכל אחד יכול לפתוח לא ענף פרטי לצורך בדיקות, העברה למפתחים אחרים בשלבי ביניים, וכו'. אבל כל check-in שמהווה אינטגרציה מול גרסה "רשמית", חייב לעמוד בקריטריונים. בסופו של דבר, זה (כמעט) לא דורש יותר מאמץ מאשר הערה בזמן Check-In, ומצד שני, רמת השקיפות של הפרויקט משתפרת ללא הכר.