לא פעם נשמע שאפליקציה מועברת לשרת אחר, הטכנולוגיה משתנה, תוכנה מתעדכנת לגרסה הבאה או מועברת לשרת של מסד נתונים אחר.
יישום ישן מכונה בדרך כלל בשם יישום ה'-מורשת' (Legacy). לכן, בדיקות הגירה כוללות בדיקות עם נתונים ישנים, נתונים חדשים או שילוב של שניהם, תכונות ישנות (תכונות ללא שינוי) והתכונות החדשות כל זאת כדי לוודא שהנתונים עוברים בהצלחה לאחסון בשרת החדש.
מה זה אומר בעצם ומה צפוי מצוות הבדיקות במצבים אלו?
מנקודת המבט של צוות הבדיקות, יש לבדוק את האפליקציה ביסודיות מקצה לקצה יחד עם העברה מהמערכת הקיימת למערכת החדשה בהצלחה.
יש לבצע בדיקת מערכת עם כל הנתונים הקיימים באפליקציה, גם עם נתונים ישנים וגם עם נתונים חדשים. יש לאמת את הפונקציונליות הקיימת יחד עם הפונקציונליות החדשה/השונה.
יחד עם אפליקציה חדשה/משודרגת, חובה להמשיך ולבדוק אפליקציות מדור קודם עד שהחדשות/משודרגות יהפכו יציבות ועקביות. בדיקת העברה מקיפה באפליקציה חדשה תחשוף את הבעיות החדשות שלא נמצאו באפליקציה מדור קודם.
אז מה זה בעצם בדיקות הגירה?
בדיקת הגירה שנקראת גם "בדיקת מיגרציה" היא תהליך אימות של הגירה של המערכת הישנה למערכת החדשה עם מינימום הפרעות/ זמן השבתה, עם שלמות נתונים, ללא אובדן נתונים, תוך הבטחה שכל היבט, פונקציונלי ולא פונקציונלי של האפליקציה מתקיים לאחר ההגירה.
כידוע, הגירת האפליקציות למערכת חדשה יכולה להיות מסיבות שונות, כמו איחוד מערכות, טכנולוגיה מיושנת, אופטימיזציה או כל סיבה אחרת ולכן די אופייני שנגיע בשלב זה או אחר להתמודד עם בדיקות אלו לאורך מחזור חיי המוצר.
אלו נקודות חיוניות יש לקחת בחשבון כשאנו עושים בדיקות הגירה?
- יש למזער כל סוג של הפרעה/אי נוחות שנגרמה למשתמש עקב הגירה. למשל: השבתה, אובדן נתונים וכד.'
- צריך לוודא אם המשתמש יכול להמשיך להשתמש בכל התכונות של התוכנה על ידי גרימת נזק מינימלי או ללא נזק כלל במהלך ההגירה. למשל: שינוי פונקציונליות, הסרה של פונקציונליות מסוימת וכד.'
- חשוב גם לצפות ולשלול את כל התקלות/המכשולים האפשריים אשר עלולים להתרחש במהלך ההגירה בפועל של המערכת החיה.
מכאן, שכדי להבטיח הגירה חלקה של המערכת החיה על ידי ביטול פגמים אלה, חיוני לבצע בדיקות הגירה במעבדה עם הדמייה מדויקת של סביבת ה"מורשת" והסביבה החדשה. לבדיקה זו יש חשיבות משלה והיא ממלאת תפקיד חיוני כאשר הנתונים נכנסים לתמונה.
מבחינה טכנית בדיקות אלו יבוצעו בסביבת הבדיקות, כדי להבטיח תאימות של האפליקציה החדשה/משודרגת עם כל החומרה והתוכנה האפשרית שהאפליקציה מדור קודם תומכת בהן. שם למשל אנו בודקים את התאימות החדשה גם עבור חומרה חדשה, פלטפורמת תוכנה, סביבות שהשתנו וכד.' בדיקת מעבדה מסייעת לנו להבטיח שכל הפונקציות הקיימות פועלות כמו באפליקציה מדור קודם. שכן לא אמור להיות שינוי באופן שבו האפליקציה פועלת בהשוואה לגרסה מדור קודם.
האפשרות למספר רב של ליקויים עקב הגירה גבוהה מאוד. רבים מהליקויים בדרך כלל יהיו קשורים לנתונים ולכן יש לזהות ולתקן את הליקויים הללו במהלך הבדיקה במעבדה טרם שחרור המוצר לסביבה המבצעית (Production). כאשר נבצע בדיקות טרום שחרור נוכל להבטיח שאם זמן התגובה של המערכת או של האפליקציה החדשה/ משודרגת זהה או קטן ממה שנדרש לאפליקציה/המערכת מהדור הקודם.
כאשר נבצע בדיקות הגירה מקדימות נוכל לוודא שהחיבור בין שרתים, חומרה, תוכנה וכו,' כולם שלמים ואינם נשברים בזמן הבדיקה. שכן זרימת נתונים בין רכיבים שונים לא אמורה להישבר בשום תנאי.
קיימים שלבים בבדיקות הגירה
- בדיקות טרום הגירה
- בדיקות הגירה
- בדיקות לאחר הגירה
בדיקת הגירת נתונים
בנוסף לאמור לעיל, הבדיקות הבאות מתבצעות גם כחלק מפעילות הגירה כולה:
- אימות תאימות לאחור (Backward Compatibility Verification)
- בדיקות שחזור לאחור ( Rollback Testing )
כדי להתחיל עם תוכנית מגובשת, יש לערוך מחקר מעמיק של המערכת הישנה והחדשה ולאחר מכן לתכנן את מקרי הבדיקה ואת תרחישי הבדיקה שיכוסו כחלק משלבי הבדיקה ולהכין את אסטרטגיית הבדיקה בהתאם.
אסטרטגיית בדיקת העברת נתונים
עיצוב אסטרטגיית הבדיקה להגירה כוללת קבוצה של פעילויות שיש לבצע וכמה היבטים שיש לקחת בחשבון. זאת כדי למזער טעויות וסיכונים אשר עלולים להתרחש כתוצאה מהגירה ולבצע את בדיקות ההגירה בצורה יעילה.
פעילויות בבדיקה זו שיש לקחת בחשבון:
גיבוש צוות מיוחד:
להקים את צוות הבדיקות עם החברים בעלי הידע והניסיון הנדרשים ולספק הדרכה הקשורה למערכת המועברת.
ניתוח סיכונים עסקיים, ניתוח שגיאות אפשרי:
אין להפריע ללקוח הנוכחי לאחר ההגירה ולפיכך לבצע פגישות 'ניתוח סיכונים עסקיים' בהשתתפות מחזיקי העניין הנכונים (מנהל בדיקות, אנליסט עסקי, אדריכלי התוכנה, בעלי מוצר, וכ'ו) ולזהות את הסיכונים ואת ההפחתות אשר ניתנות ליישום. הבדיקה צריכה לכלול תרחישים שונים כדי לחשוף את הסיכונים הללו ולוודא שאכן הוטמעו אמצעים מתאימים.
ניתוח וזיהוי היקף ההגירה:
עלינו לנתח את ההיקף הברור של מבחן ההגירה כמו מתי ומה צריך להיבדק.
זהה את הכלי המתאים להגירה:
תוך כדי שמגדירים את האסטרטגיה של בדיקה זו, אוטומטית או ידנית, זהה את הכלים שעומדים לשמש. לדוגמה: כלי אוטומטי להשוואת נתוני מקור ויעד.
זהה את סביבת הבדיקה המתאימה להגירה:
זהה סביבות נפרדות עבור סביבות Pre וMigration- Post לביצוע כל אימות שנדרש כחלק מבדיקות. להבין ולתעד את ההיבטים הטכניים של מערכת הגירה מדור קודם והחדשה, כדי להבטיח שסביבת הבדיקה מוגדרת בהתאם.
מסמך וסקירה של מפרט בדיקת הגירה:
הכן מסמך מפרט בדיקת הגירה אשר מתאר את גישת הבדיקה, תחומי בדיקה, שיטות בדיקה (אוטומטיות, ידניות,) מתודולוגיית בדיקה (קופסה שחורה, טכניקת בדיקת קופסה לבנה,) מספר מחזורי בדיקות, לוח זמנים של בדיקות, גישת יצירת נתונים ושימוש בנתונים חיים (רגישים.)
השקת ייצור של המערכת שהועברה:
נתח ותעד את רשימת המטלות להעברת המערכת לסביבת הייצור ופרסם אותה זמן רב מראש. הלן מוצגים השלבים השונים של הגירה:
שלב מס :1 בדיקת טרום הגירה
לפני העברת הנתונים, מערך פעילויות הבדיקה מבוצעות כחלק משלב הבדיקה שלפני ההגירה. זה מתעלם או לא נחשב ביישומים פשוטים יותר. אך כאשר יש להעביר יישומים מורכבים, פעילויות טרום-הגירה הן חובה. בשלב זה יוגדרו היקפי הנתונים שהולכים לעבור, ואלו שלא יעברו.
כאשר נבצע בדיקות הגירה מקדימות נוכל לוודא שהחיבור בין שרתים, חומרה, תוכנה וכו,' כולם שלמים ואינם נשברים בזמן הבדיקה.
יבוצע מיפוי נתונים בין המורשת לאפליקציה החדשה – עבור כל סוג של נתונים באפליקציה הישנה נבצע השוואה לסוג הרלוונטי שלו באפליקציה החדשה.
נלמד את סכימת הנתונים של האפליקציה החדשה – שמות שדות, סוגים, ערכי מינימום ומקסימום, אורך, שדות חובה, אימותים ברמת השדה וכ'ו, נכין מקרי בדיקה, תרחישי בדיקה ומקרי שימוש לתנאים חדשים ביישומים החדשים.
נבצע קבוצה של מקרי בדיקה ותרחישים עם קבוצה של משתמשים ושמור את התוצאות, יומנים מאוחסנים. יש לאמת את אותו הדבר לאחר הגירה כדי להבטיח שהנתונים והפונקציונליות מדור קודם נשארים ללא פגע.
שלב מס :2 בדיקת הגירה
יש לעקוב בקפדנות אחר 'מדריך ההגירה' שהוכן על ידי צוות ההגירה כדי לבצע את פעילות ההגירה. באופן אידיאלי, פעילות ההגירה מתחילה עם גיבוי הנתונים בקלטת, כך שבכל עת ניתן לשחזר את המערכת הישנה.
אימות חלק התיעוד של 'מדריך הגירה' הוא גם חלק מבדיקת העברת נתונים. יש לוודא שהמסמך ברור וקל לעקוב אחריו. כל התסריטים והשלבים חייבים להיות מתועדים בצורה נכונה ללא כל אי בהירות. כל סוג של שגיאות תיעוד, פספוס התאמות בסדר ביצוע השלבים צריך גם להיחשב כדי שניתן יהיה לדווח ולתקן אותן. יש לאסוף סקריפטים, מדריך ומידע אחר הקשור להגירה בפועל ממאגר בקרת הגרסאות לצורך ביצוע.
כדי לרשום את הזמן בפועל שלוקח להגירה מנקודת תחילת ההגירה ועד שחזור מוצלח של המערכת, הוא אחד ממקרי הבדיקה שיש לבצע ומכאן שצריך לרשום את "הזמן הנדרש להעברת המערכת" זמן זה יצויין בדוח הבדיקה הסופי (STR) אשר יימסר כחלק מתוצאות בדיקות הגירה ומידע זה יהיה שימושי במהלך השקת הייצור. זמן ההשבתה שנרשם בסביבת הבדיקה מוחלף כדי לחשב את זמן ההשבתה המשוער במערכת החיה. במהלך בדיקה זו, בדרך כלל כל מרכיבי הסביבה יופלו ויוסרו מהרשת לצורך ביצוע פעולות ההגירה.
שלב מס :3 בדיקות לאחר הגירה
ברגע שהאפליקציה עוברת בהצלחה, בדיקות פוסט-הגירה נכנסות לתמונה.
כאן מתבצעות בדיקות מערכת מקצה לקצה בסביבת הבדיקה. בודקים ומבצעים מקרי בדיקה מזוהים, תרחישי בדיקה, מקרי שימוש עם נתונים מדור קודם, כמו גם קבוצה חדשה של נתונים.
לאחר סיום פעילות ההגירה המפורטת במדריך, על כל השרתים מופעלים, ובדיקות בסיסיות הקשורות לאימות הגירה מוצלחת יבוצעו, מה שמבטיח שכל המערכות מקצה לקצה מחוברות כראוי וכל הרכיבים מדברים עם כל אחד מהם. אחר, DB פועל, הקצה הקדמי מתקשר עם הקצה האחורי בהצלחה.
תאימות לאחור
מקובל לבדוק בחלק זה האם המערכת החדשה תומכת בפונקציונליות שנתמכה ב2- גרסאות קודמות יחד עם החדשה.
לפיכך, חיוני להבטיח את התאימות לאחור של המערכת על ידי ביצוע ספציפי של הבדיקות הקשורות לתמיכה בתאימות לאחור. הבדיקות הקשורות לתאימות לאחור צריכות להיות מתוכננות ולהיכלל במסמך מפרט הבדיקה לצורך ביצוע.
בדיקת שחזור מערכת לאחור
במקרה של בעיות כלשהן במהלך ביצוע ההגירה או אם יש כשל הגירה בכל נקודת זמן במהלך ההגירה, אזי אמורה להיות אפשרות למערכת לחזור למערכת הישנה ולחדש את פעולתה במהירות מבלי להשפיע על המשתמשים והפונקציונליות שנתמכה קודם לכן.
לכן, על מנת לאמת זאת, יש לתכנן תרחישי בדיקות כשל הגירה כחלק מבדיקות שליליות ויש לבדוק את מנגנון החזרה לאחור. הזמן הכולל הנדרש כדי לחזור למערכת הישנה גם צריך להירשם בתוצאות הבדיקה.
לאחר החזרה לאחור, יש להפעיל את הפונקציונליות העיקרית ואת בדיקות הרגרסיה (אוטומטיות) כדי להבטיח שההגירה לא השפיעה על דבר והחזרה לאחור מצליחה להחזיר את המערכת הישנה למקומה.
כמו בכל פעילות בדיקה נוכל להעביר דוח סיכום מבחן הגירה לבעלי העניין, בדוח זה נציין את סיכום הבדיקות/תרחישים השונים שבוצעו במסגרת שלבי הגירה שונים עם מצב התוצאה (עובר/נכשל) ויומני הבדיקה. דוח שכזה אמור לכלול נתונים על הזמן שנרשם עבור הפעולות הבאות:
- זמן כולל עבור הגירה
- זמן השבתה של האפליקציות
- הזמן שהושקע להעברת 10,000 רשומות.
- זמן שהוקדש לחזרה.
- בנוסף למידע הנ"ל, ניתן גם לדווח על כל תצפיות/המלצות.
אתגרים בבדיקות העברת נתונים
האתגרים העומדים בפני בדיקה זו הם בעיקר עם נתונים. להלן כמה ברשימה:
איכות נתונים:
אנו עשויים לגלות שהנתונים המשמשים באפליקציה מדור קודם הם באיכות ירודה באפליקציה החדשה/משודרגת. במקרים כאלה, יש לשפר את איכות הנתונים כדי לעמוד בסטנדרטים העסקיים.
אי התאמה של נתונים:
ייתכן שהנתונים שהועברו מהגרסה הישנה לאפליקציה החדשה/ משודרגת לא תואמות באפליקציה החדשה. ייתכן שהסיבה לכך היא השינוי בסוג הנתונים, בפורמט של אחסון הנתונים, המטרה שלשמה נעשה שימוש בנתונים עשויה להיות מוגדרת מחדש.
אובדן נתונים:
נתונים עלולים ללכת לאיבוד בעת המעבר מהגרסה הישנה לאפליקציה החדשה/משודרגת. זה יכול להיות עם שדות חובה או שדות לא חובה. אם הנתונים שאבדו הם עבור שדות לא חובה, הרי הרשומה עבורם עדיין תקפה ולכן ניתן לעדכן אותה שוב.
אבל אם נתוני שדה החובה אובדים, הרשומה עצמה הופכת לבטלה ולא ניתן לבטל אותה. זה יגרום לאובדן נתונים עצום ויש לאחזר אותו ממסד נתוני הגיבוי.
נפח נתונים:
נתונים עצומים אשר דורשים הרבה זמן להגירה בתוך חלון זמן ההשבתה של פעילות ההגירה. למשל: כרטיסי גירוד בתעשיית הטלקום, משתמשים בפלטפורמת רשת חכמה וכו,' כאן האתגר הוא עד שהנתונים הישנים ינוקו, ייווצרו נתונים רבים חדשים, אותם צריך להעביר שוב. במקרה זה אוטומציה היא הפתרון להעברת Data .Big
סימולציה של סביבה בזמן אמת (עם הנתונים בפועל):
סימולציה של סביבה בזמן אמת (Real Time) במעבדת הבדיקות היא אתגר בפני עצמו, מאחר והנתונים ממשיכים לזרום בזמן הבדיקה עצמה העלולים להשפיע על תוצאותיה. לכן, דגימת נתונים, שכפול של סביבה אמיתית, זיהוי נפח הנתונים המעורבים בהגירה חשובים למדי בזמן ביצוע בדיקות העברת נתונים.
סימולציה של נפח הנתונים:
צוותים צריכים ללמוד את הנתונים במערכת החיה בזהירות רבה. יש צורך להגיע לניתוח ודגימה טיפוסית של הנתונים.
לדוגמא: משתמשים עם קבוצת גיל מתחת לגיל ,10 10-30 שנים וכו,' עד כמה שניתן, יש לקבל נתונים מהחיים, אם לא, יש צורך ביצירת נתונים בסביבת הבדיקה. יש להשתמש בכלים אוטומטיים כדי ליצור נפח גדול של נתונים (מחוללי דאטה.)
טיפים להתמודדות עם האתגרים
בבדיקות הגירה
1. תקנו מראש את הנתונים המשמשים במערכת מדור קודם, כך שבעת ההעברה, נתונים סטנדרטיים יהיו זמינים במערכת חדשה.
2. נקו את הנתונים לפני ההעברה, כך שבעת ההעברה לא יהיו נתונים כפולים במערכת החדשה וגם זה שומר על ניקיון המערכת כולה.
3. בדקו מחדש את האילוצים, הנהלים המאוחסנים, שאילתות מורכבות המניבות תוצאות מדויקות, כך שבעת ההעברה, נתונים נכונים יוחזרו גם במערכת החדשה
4. זהו כלי אוטומציה נכון לביצוע בדיקות נתונים / בדיקות רישום במערכת החדשה בהשוואה למורשת.
לסיכום
קיימת מורכבות גבוהה הכרוכה בביצוע בדיקות של העברת נתונים, מתוך ההבנה שפספוס קטן בכל היבט של אימות במהלך הבדיקה יוביל לסיכון של כשל בתהליך ההגירה. לפיכך, חשוב מאוד לבצע מחקר מדוקדק ויסודי וניתוח המערכת לפני ואחרי ההגירה. תכנון אסטרטגיית הגירה אפקטיבית עם כלים חזקים ויחד עם בודקים מיומנים ומאומנים יגדילו את הסיכוי למעבר יעיל ומהיר.