בחלק מהצוותים איתם אני עובד ב-AVG יש לנו רגרסיות שאנו רוצים להמיר לאוטומציה. כיוון שכמות הרגרסיות גדולה, אנו זקוקים לקריטריון ברור שיעזור לנו להחליט על סדר ההמרה לאוטומציה. למשל המרה של רגרסיה קצרה להרצה ידנית, קשה להמרה לאוטומציה ומורצת לעיתים רחוקות תהיה בדחיפות נמוכה.
אנו חושבים שתהליך ההמרה אמור להיות כזה:
1. כתיבת רשימת רגרסיות.
2. נתינת ציון לכל רגרסיה לפי מידת הדחיפות שלה.
3. אם צריך בתוך הרגרסיה עצמה נתינת ציון ל-test cases.
4. להתחיל בהמרה בהתאם.
המידות לפיהן נחשב את מידת הדחיפות של כל רגרסיה הן:
1. ההשקעה באוטומציה:
כמה זמן יקח לנו להעביר לאוטומציה, כתיבת הקוד (אפשר להתייעץ עם צוות האוטומציה אם יש).
נקודות לחשיבה:
- זמן כתיבת הקוד.
- האם יש צורך ללמוד טכנולוגיות / כלים חדשים?
- האם יש צורך בשינוי תשתיות האוטומציה?
ככל שזמן ההמרה קצר יותר, כך הרגרסיה מועמדת טובה יותר להמרה (כמובן בהתייחס גם למידות האחרות).
דוגמא: אוטומציה שהיא בעיקרה שליחה וקבלה של JSON עשוייה להיות קלה לכתיבה.
2. המאמץ בהרצה ידנית:
- כמה זמן לוקח לנו להריץ את הרגרסיה ידנית (הרמה של רגרסיה אחת X מספר החזרות - למשל מערכות הפעלה)?
ככל שזמן ההרצה ארוך יותר, כך הרגרסיה מועמדת טובה יותר להמרה (כמובן בהתייחס גם למידות האחרות).
3. חזרות:
- האם אנו מריצים את הרגרסיה בכל גרסה? בכל בניה בתוך גרסה (למשל בדיקות שפיות)?
ככל שמספר החזרות גדול יותר, כך הרגרסיה מועמדת טובה יותר להמרה (כמובן בהתייחס גם למידות האחרות).
4. תחזוקת הקוד האוטומטי:
אם מדובר באובייקט / פיצ'ר / UI שמשתנים לעיתים קרובות עלינו להחליט אם שווה להמיר אותם לאוטומציה.
למשל ל-UI יש נטייה להשתנות לעיתים קרובות יותר וקשה יותר לעדכן אותם מאשר תהליכים (בד"כ).
ככל שהצפי לתחזוקת הקוד גדול יותר, כך הרגרסיה מועמדת טובה פחות להמרה (כמובן בהתייחס גם למידות האחרות).
5. ניהול סיכונים:
איזה פיצ'ר חשוב יותר לבדוק?
מבחינת המוצר:
- פיצ'ר חשוב למשתמשים.
- פיצ'ר חשוב לחברה.
- מתחבר לפיצ'ר חשוב.
מבחינה הנדסית:
- פיתוח מורכב.
- קוד בסיסי.
- האם היה בעייתי בעבר?
ככל שהפיצ'ר ריסקי יותר, כך הרגרסיה מועמדת טובה יותר להמרה (כמובן בהתייחס גם למידות האחרות).
איך הבדיקות שלכם לא אמורות להיראות:
קביעת סדר עדיפויות בהמרת בדיקות ידניות לאוטומטיותקביעת סדר עדיפויות בהמרת בדיקות ידניות לאוטומטיות
איך הבדיקות שלכם אמורות להיראות:
מה לא כדאי להמיר?
· בדיקות קבלה, בדיקות יוזביליות, או בדיקה סופית של המוצר - דברים שזקוקים להערכת אדם.
· בדיקות חד-פעמיות.
· התנהגות או פלט שאינם צפויים.
אין תגובות:
הוסף רשומת תגובה