איך לבדוק הסבות ומגרציה-QA

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

בואו רגע נבין מה המשמעות של פרויקט הסבה או מגרציה. אירגון מחליט שהוא מעוניין לשדרג את המערכת שלו למוצר אחר חדשני יותר, עם אפשרויות טכנולוגיות רחבות יותר, בעל אפשרות קסטומזציה רחבה ללא שורות קוד. מה עושים עם ההיסטוריה?

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

כמובן שלכל חלופה כזו יש ייתרונות וחסרונות, שיקולי תקציב מול שיקולי סיכון, במקרה והאירגון החליט שלפי שיקולי עלות מול תועלת נכון לו לצאת לפרויקט הסבת הנתונים או מגרציה של המערכת הישנה, על בודקי התוכנה תקפיד קריטי.

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

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

שימוש בכלים: אחת מהדרכים להגיע להצלחת הפרויקט בהסבת הנתונים הוא בדיקות באמצעות כלים, הכוונה כאן למס"ד הנתונים. עלינו לקחת בודקים המכירים את שפת ה SQL, לאפשר להם גישה לבסיס הנתונים בסביבה נמוכה, ולתת להם לייצר שאילתות מובנות על המידע לפני ההסבה ואחרי ההסבה. בדיקה כמותית של ההסבה, סיכומית אם מדובר על תשלומים והזמנות, ובדיקה פרטנית המייצרת השוואה בין רשומה קיימת לבין רשומה מוסבת.

כשאנחנו מקבלים את שני בסיסי הנתונים להשוואה, אנחנו יכולים להסתכל ברמת טיפוס השדות כדי להבין האם יש בעיה וצריכים לתת עליה מענה ברמת האיפיון, בואו ניקח דוג'. מספר הזמנה במערכת הישנה הייתה עם 10 ספרות, מספר ההזמנה במערכת החדשה היא רק 7 ספרות. במקרה שנבצע הסבה AS IS ללא טיפול ברמת הלוגיקה והאיפיון מה שיקרה זה שיחתכו 3 ספרות בתהליך ההסבה, מה שעשוי להוביל לכאוס במערכת, וליצור לנו מפתחות דומים, מידע שהולך לאיבוד. ניקח דוגמאות נוספות קיטום של סכומים, אי שימוש בנקודה עשרונית מול מספר שלם. שימוש בתאריך DD/MM מול תאריך מלא שהמערכת החדשה מצפה לה כגון DD/MM/YYYY איך משלימים את השנה כשהמידע לא קיים?

בדיקות באמצעות ה GUI: שימוש בכלים היא דרך מעולה למצוא חוסרים בתהליך ההסבה. אך חשוב לא פחות להבין איך האפליקציה תתמודד עם הנתונים לאחר ההסבה, לדוג' שאין חוק עסקי במערכת הצפה לקבל נתון בשדה חובה, כשבמערכת הישנה שדה זה כלל לא היה חובה, ולכן המערכת החדשה לא תדע לטפל ברשומה מסוג זה, הרי והיא מצפה לנתון קריטי מבחינתה, זה אף יכול להיות רשומת מפתח.

יש כלים ושיטות נוספות שאנחנו מלמדים בקורס הדיגיטלי המלא שלנו

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