מתי אין בעייה?
במקרה של בדיקות של תוכנה קטנה, אין בעייה - או שמריצים את כל הבדיקות עליה שוב או שיושבים עם המפתח ומתייעצים.
גם במקרה שיש לכם בדיקות אוטומטיות שמכנות את כל היקף ה-SUT אין בעייה - פשוט מריצים אותם שוב.
מתי יש בעייה?
בעצם כשאין מספיק זמן לבצע את כל הבדיקות.
יש בעייה במערכות גדולות, שזמני הבדיקה של כל המערכת עקב פיתוחים חדשים הם גבוהים מידי.
ישנן מערכות שזמני הבדיקות המלאים שלה גם כשיש צוותי בדיקה גדולים נמדד בחודשים.
מה עושים?
מתכננים היטב את סוגי הרגרסיות שיש להריץ.
ההנחה שלי היא שמדובר במערכת גדולה, והבודקים משתמשים במסמכי בדיקות רבים, כל מסמך קשור לפיצ'ר זה או אחר.
שוב - אם הינו בודקים את Office אזי היו לנו מסמכים לכל אפליקציה. ולכל אפליקציה מסמכים משלה: נניח ל-Outlook יהיה מסמך שבודק שליחה של מיילים בפורמטים שונים וכו'.
1. קביעת היקף הרגרסיות:
על האחראי של הבדיקות ליצור מסמך אקסל שנראה כך פחות או יותר:
איור מס' 1
2. התייעצות עם הגורמים הרלוונטים:
לאחר שמי שצריך השלים את המשימה הזו יש לנו מיפוי של כל הרגרסיות שלדעתנו עלינו לבצע.
כעת יש לשבת עם הפיתוח, מנהל הגרסה ועם מהנדסי המערכת, לעבור פיצ'ר פיצ'ר ולציין אילו רגרסיות אנו מתכננים. יש לציין שיש לנו כבודקים הבנה די טובה של המערכת, אבל לא תמיד אנו יודעים שיש פונקציות משותפות לפיצ'רים שונים.
הפידבק שאני מצפה לו הוא:
4. קביעת הרגרסיות פר סבב (cycle):
לאחר שלב שלש יש לנו רשימה מעודכנת של איור מס' 1. כעת יש להריץ את הרגרסיות כך:
אם יש רגרסיה בשל פיצ'ר אחד בלבד - יש להריץ אותה ב-build שבו הפיצ'ר נכנס.
לגבי רגרסיות שיש להריץ בשל מס' פיצ'רים - יש לנסות להריץ כאשר כל הפיצ'רים הוכנסו, כלומר לא להריץ אותה ב-build 1, 3 ו-4 אלא ב-4 בלבד. אבל, לעתים עדיף להריץ פעמיים - אם הרגרסיה X ב-build ראשון היא בשל פיצ'ר מרכזי, אבל לפי הטבלא יש להריץ אותה ב-build האחרון עדיין כשאי להריץ אותה לפני בכדי לא לגלות בסוף שאולי כל הפיתוחים החדשים עובדים, אבל האפליקציה מתרסקת בכל פעם שפותחים פיצ'ר קיים מרכזי.
יש להכין טבלא בדומה לזו למעלה כאשר העמודה הראשונה היא ה-build ואח"כ הרגרסיות הרלוונטיות.
5. רעיון
לדעתי בגרסה גדולה למערכות מורכבות, כדאי לשקול הרצה של ATP ברגע שכל / רוב התכולה נכנסת (ולא רק בסוף). כך נוכל להיות רגועים באשר לפעילות המרכזית של המערכת. בכדי לא לבזבז זמן את החלקים שנבדקו ב-ATP ועברו כשורה אין צורך לחזור ברגרסיות.
במקרה של בדיקות של תוכנה קטנה, אין בעייה - או שמריצים את כל הבדיקות עליה שוב או שיושבים עם המפתח ומתייעצים.
גם במקרה שיש לכם בדיקות אוטומטיות שמכנות את כל היקף ה-SUT אין בעייה - פשוט מריצים אותם שוב.
מתי יש בעייה?
בעצם כשאין מספיק זמן לבצע את כל הבדיקות.
יש בעייה במערכות גדולות, שזמני הבדיקה של כל המערכת עקב פיתוחים חדשים הם גבוהים מידי.
ישנן מערכות שזמני הבדיקות המלאים שלה גם כשיש צוותי בדיקה גדולים נמדד בחודשים.
מה עושים?
מתכננים היטב את סוגי הרגרסיות שיש להריץ.
ההנחה שלי היא שמדובר במערכת גדולה, והבודקים משתמשים במסמכי בדיקות רבים, כל מסמך קשור לפיצ'ר זה או אחר.
שוב - אם הינו בודקים את Office אזי היו לנו מסמכים לכל אפליקציה. ולכל אפליקציה מסמכים משלה: נניח ל-Outlook יהיה מסמך שבודק שליחה של מיילים בפורמטים שונים וכו'.
1. קביעת היקף הרגרסיות:
על האחראי של הבדיקות ליצור מסמך אקסל שנראה כך פחות או יותר:
#
|
Feature
|
Build
|
Regression name
|
Time (d)
|
1
|
הוספה של פורמט SMIL
|
1
|
פורמטים,
|
2
|
שליחת מיילים,
|
4
| |||
שילוב מדיות
|
1
| |||
ועוד....
| ||||
2
|
שיפור טיפול בדואר זבל
|
2
|
דואר זבל,
|
5
|
שליחת מיילים
|
4
| |||
עיבוד דואר נכנס
|
2
| |||
ועוד...
|
2. התייעצות עם הגורמים הרלוונטים:
לאחר שמי שצריך השלים את המשימה הזו יש לנו מיפוי של כל הרגרסיות שלדעתנו עלינו לבצע.
כעת יש לשבת עם הפיתוח, מנהל הגרסה ועם מהנדסי המערכת, לעבור פיצ'ר פיצ'ר ולציין אילו רגרסיות אנו מתכננים. יש לציין שיש לנו כבודקים הבנה די טובה של המערכת, אבל לא תמיד אנו יודעים שיש פונקציות משותפות לפיצ'רים שונים.
הפידבק שאני מצפה לו הוא:
- האם הפיצ'רים החדשים אכן נוגעים ברגרסיות שציינו כרלוונטיות? אם לא - על אילו רגרסיות אפשר לוותר?
- האם הפיצ'רים החדשים נוגעים ברגרסיות שלא ציינו כרלוונטיות? אם כן - אילו רגרסיות יש להוסיף?
- את הרגרסיות שכן יש להריץ - האם צריך להריץ את כולה או רק בחלקה?
- אפשר לנצל את את הפגישה הזו לסיכום של זמני פיתוח לפי הרגרסיות. כלומר מה שדורש הרבה רגרסיות יפותח קודם (גם כן סוג של ניהול סיכונים).
- לראות אולי יש פיתוחים פחות חשובים שדורשים זמן רגרסיות גדול. במקרה הזה יש לשקול הכנסתם שוב.
4. קביעת הרגרסיות פר סבב (cycle):
לאחר שלב שלש יש לנו רשימה מעודכנת של איור מס' 1. כעת יש להריץ את הרגרסיות כך:
אם יש רגרסיה בשל פיצ'ר אחד בלבד - יש להריץ אותה ב-build שבו הפיצ'ר נכנס.
לגבי רגרסיות שיש להריץ בשל מס' פיצ'רים - יש לנסות להריץ כאשר כל הפיצ'רים הוכנסו, כלומר לא להריץ אותה ב-build 1, 3 ו-4 אלא ב-4 בלבד. אבל, לעתים עדיף להריץ פעמיים - אם הרגרסיה X ב-build ראשון היא בשל פיצ'ר מרכזי, אבל לפי הטבלא יש להריץ אותה ב-build האחרון עדיין כשאי להריץ אותה לפני בכדי לא לגלות בסוף שאולי כל הפיתוחים החדשים עובדים, אבל האפליקציה מתרסקת בכל פעם שפותחים פיצ'ר קיים מרכזי.
יש להכין טבלא בדומה לזו למעלה כאשר העמודה הראשונה היא ה-build ואח"כ הרגרסיות הרלוונטיות.
5. רעיון
לדעתי בגרסה גדולה למערכות מורכבות, כדאי לשקול הרצה של ATP ברגע שכל / רוב התכולה נכנסת (ולא רק בסוף). כך נוכל להיות רגועים באשר לפעילות המרכזית של המערכת. בכדי לא לבזבז זמן את החלקים שנבדקו ב-ATP ועברו כשורה אין צורך לחזור ברגרסיות.
אין תגובות:
הוסף רשומת תגובה