בדיקת תיקון היא תהליך של אימות תכונה מסוימת שפעלה לא נכון במהלך הבדיקה הקודמת. היא נעשית כדי לאמת האם התיקונים שהודיעו על כמה באגים במהלך זמן הביצוע נקבעו.
במחזור החיים של פיתוח תוכנה, האלמנטים העיקריים הקריטיים הם בדיקת הפונקציונליות, הביצועים, האבטחה והיבטים אחרים של התוכנה, שכוללת בדיקת התוכנה לכל שגיאות. עם זאת, האתגר העיקרי הוא אימות פעולת התוכנה בהתאם לקהל היעד. חשוב להבטיח את האפקטיביות והאמינות של התוכנה המיוצרת, וכאן בדיקת תיקון נכנסת כמושיבה.
המטרה העיקרית של בדיקת תוכנה היא לזהות שגיאה או באגים ביישום התוכנה. מהנדסי בדיקות אחראים לקבלת ההחלטה בנוגע לאלו ולדווח לצוות הפיתוח להערכה נוספת. לאחר מכן, ניסוחים כאלה ונשלח למהנדס בדיקה לאימות מחדש.
בדיקות מחדש מוודאות שלא יתרחשו בעיות נוספות במהלך שחרור התוכנה. תהליך כזה יכול להתבצע באופן ידני באמצעות סט מסוים של מקרי בדיקה. ללא קשר למורכבות המעורבת בבדיקות מחדש, עלינו להבין זאת כחלק השורש של בדיקת תוכנה להבאת מוצרים באיכות גבוהה.
מהי בדיקת תיקון?
אתה בטח רגיל לעובדה שלמצוא באגים במהלך בדיקת התוכנה זו תפקידה של מהנדסי בדיקות. בין כך, הם אחראים לתיקון ולשליחת השגיאה או הבעיה חזרה למפתחים, ולהבטיח שהם יתקנו שגיאה או בעיה כזו. הנה באה בדיקת תיקון. בוא נבין זאת יותר ברור.
בפיתוח תוכנה, בדיקת החזרה היא תהליך של אימות בנייה שמסופקת על ידי המפתחים כדי לוודא שהשגיאה נתקנה. במונחים פשוטים, נניח שאתה בודק תוכנה כלשהי שהיא "מספר הבנייה 1", ואם נתקלת בשגיאה כלשהי, הסימון שלה הוא, למשל, A1. לאחר מכן, הבודק בודק את השגיאה ונקראת "מספר הבנייה 2".
במילים אחרות, השגיאה שזוהתה במספר הבנייה 1 נבדקת שוב במספר הבנייה 2 כדי לבדוק האם המפתח תיקנ את השגיאה. הבודק כאן בודק שוב את המקרים שנכשלו כדי לאמת את התיקון שנעשה על ידי המפתחים.
זה חלק ממחזור החיים של הפגם שבו בוצעת בדיקת מקרים הבדיקה הנכשלים, שהיו לא פונקציונליים בזמן הבדיקה הקודמת שתוקנה על ידי המפתחים.
עקוב אחר נקודות אלו כדי לקבל מידע נוסף על תהליך הבדיקה מחדש:
- מקרים הבדיקה הנכשלים המתאימים לבאגים המדווחים נבדקים מחדש.
- שם אחר לבדיקת החזרה היא בדיקת אימות עידון.
- עבור השגיאה המדווחת בבנייה החדשה, ניתן צריך להשתמש בנתוני בדיקה ותהליכים דומים כדי לאמת את הגילוי מחדש.
A comprehensive example of the retest process will help you get a clearer picture.
למה בדיקת החזרה חשובה?
בדיקת החזרה היא חלק ממחזור חיי הבדיקה בתוכנה שמקיף מספר ערכים הקשורים למשימות המשולמות של המוצר. בהחלט, זהו חלק עיקרי מתהליך הבדיקה התקני של תוכנה. אך מלבד זאת, זה מעניק למוצר שכבה נוספת של בטחון, סינון ביצועי הטכניים והפונקציונליים שלו לפני השחרור למשתמשים הסופיים.
עסקים צריכים להבטיח יישומים דיגיטליים באיכות גבוהה בשוק הפיתוח התוכנה המתחרה זהה. זה דורש שום פשרה באיכות המוצר הסופי.
פלטפורמות בדיקות אוטומציה יכולות לעזור לך להשיג תשואה על ההשקעה טובה יותר עבור המוצר שהושקע בו. עם זאת, בדיקה חוזרת מעניקה יותר בטחון על ידי וירידה כל באג. לעומת תהליך הבדיקה הראשוני, היא לא מוסיפה עלות נוספת למשאבי הבדיקה ולא גורמת לזמן רב. ידוע להתבצע באותו סביבה עם מידע דומה הקשור למקרים בדיקה שנכשלו.
בנוסף, תהליך הבדיקה החוזרת מתייחס לבעיות ספציפיות או באגים שנמצאו במודולים ספציפיים של היישום. לכן, אין צורך להקים סביבת בדיקה חדשה ולהשקיע יותר מאמץ כדי לאמת את האיכות של המוצר עם בדיקה מקצה לקצה.
דוגמה לבדיקה חוזרת
למרות שהדוגמה המוסברת לעיל יכולה לעזור לך להשיג מידע שטחי, להלן, נתמקד בדוגמה דומה, עם תובנה עמוקה יותר בתהליכים שלה.
תרחיש
כחלק מתהליך הפיתוח התוכנה, נפתחה גרסה 2.0. במהלך בדיקתה, הצוות זיהה ושיחרר פגם (נניח, פגם 2.0.1). צריך לבדוק פגם דומה 2.0.1 בגרסה 2.1 (בתנאי שהפגם הזה מופיע בהערות שיחרור של גרסה 2.1) כדי לוודא את תיקון הפגם.
תהליך ביצוע
על פי מעגל החיים של הבאג, כשהבאג מתווה, הוא מייד משודר או מודע לצוות הפיתוח. לאחר מכן, מסומן כ"חדש". עכשיו, זה תלוי בצוות הפיתוח אם לקבל או לדחות את הבאג.
לאחר אישור הבאג, המפתח יתקן אותו ולאחר מכן ישוחרר בשלב הבא. מסומן כ"מוכן ל-QA". כעת, הבודקים מאשרים את הבאג כדי לגלות את פתרונו. לכן, אפשר להגיד שבדיקה חוזרת היא בדיקה מתוכננת.
הבודק משתמש באותם מקרי בדיקה ונתוני בדיקה בבנאדם הקודם. אם לא נמצא באג, מסומן כ"נתקן". לעומת זאת, המצב נשאר "לא נתקן". לאחר מכן, מועבר מסמך בדיקת פגמים חוזרת לצוות הפיתוח.
כדי לקבל תובנה טובה בבדיקות חוזרות, עליך להכיר את המאפיינים העיקריים שלהן. זה לא רק יעזור להרחיב את הבדיקה שלך אלא גם להגדיל את הממדים לבניית איכות התוכנה.
מאפיינים של בדיקות חוזרות
חווית המשתמש הגבוהה ביותר בבדיקת תוכנה עוקבת אחרת תהליך איטרטיבי. לשם כך, שמירה על מידע על היבטים קרדינליים של תהליך בדיקה חוזרת מאפשרת משלוח תוכנה טוב יותר.
להלן המאפיינים העיקריים שלה:
- הוא מופעל באותו מסמך כמו הקודם ומתבצע בבנאדם החדש.
- ביצוע נעשה כאשר מקרי בדיקה מסוימים נחשבים כנכשלים.
- זה קורה כאשר תוכנת מלאה דורשת בדיקות חוזרות כדי לאמת את איכותה.
- לא ניתן להפעיל באופן אוטומטי את מקרי הבדיקה שמיובאים לבדיקה מחדש.
- התהליך של בדיקה מחדש מסתמך על הצוות הפיתוח, שאחראי לקבל או לדחות את הבאג.
- פרטים מפורטים נחשבים עבור ההיבט השינוי של הפונקציונליות על ידי הבודק.
מתי כדאי לבצע בדיקה מחדש?
כבודק, קריטי לקבוע מתי כדאי לעשות בדיקה מחדש. התשובה לכך היא פשוטה. תחילה, יש לקחת בחשבון את גודל הפרויקט והמאפיינים שלו, שדורשים בדיקה.
לדוגמה, בדיקה מחדש הופכת לרגילה אם ארגון מחזיק קו מוצרים מרובים ומפוזרים בין מוצרים שונים. הסיבה היא הצורך בשחרור היישום התוכנה בזמן, שזה עשוי גם להשפיע על חלקים אחרים של המערכות בדרכים שונות.
ישנם תרחישים שונים שבהם ניתן להשתמש בבדיקה מחדש כתהליך. חלקם מוסברים להלן:
בגילוי הבאג המדורג כ"לא ניתן לשחזור"
זה עשוי לקרות פעמים רבות כאשר הבאג שהבודק מציין נדחה על ידי המפתח ומסומן כ"לא ניתן לשחזור". במקרים כאלה, מבוצעת בדיקה מחדש עבור אותו באג כדי ליידע את המפתח שהבעיה ניתן לשחזור ותקפה.
צורך בתיקון הבאג שמודגש בפתק השחרור
בתהליך פיתוח התוכנה, כאשר צוות הפיתוח משחרר בניין חדש, מתקיימת בדיקה מחדש. כאן, הבודק בודק את הבאגים שדווחו קודם לכן כדי לוודא שהם תוקנו.
בקשת לקוח
רמת האיכות של תוכנת היא דאגה עיקרית עבור כל ארגון. כדי להבטיח זאת, לקוח עשוי לבקש לבצע בדיקה חוזרת עבור מקרים שימוש ספציפיים כדי להבטיח את איכות המוצר.
תרחישים אחרים
חשוב לציין שבכל פעם שבאג מוכפל, מפתחים יוצרים מקרים בדיקה נוספים. זה מעיד על כך שכדאי לבלות יותר זמן בכתיבת מקרים בדיקה מאשר בתיקון באגים. עם זאת, גם אם אתה בטוח בבסיס הקוד שלך, עדיין חיוני לבצע בדיקה חוזרת על חלקים קרדינליים של היישום בכל פעם של שחרור.
לדוגמה, פונקציונליות חדשה גורמת להתנהגות לא צפויה ולאתגרים בגילוי באגים בפעם הראשונה. זה יתכן רק כאשר נתקלות בבעיות כאלה במהלך הבדיקה או על סמך משוב המשתמש. מצב זה דורש ממך לבצע "בדיקה חוזרת" כדי להתגבר על ספק בנוגע לבאגים הנכונים לראשונה.
יתרונות של בדיקה חוזרת
האיכות של יישום תוכנה תלויה בהצלחת תהליך הבדיקה החוזרת. זה מבטיח את היציבות של היישום במחזור חיי היישום.
חלק מהיתרונות העיקריים שלה מודגשים להלן:
- מאפשר לוודא האם הבאג מוכפל או לא.
- משפר את איכות המוצר והיישום שנוצר.
- מבטיח את פעולת היישום או המוצר על פי ציפיות המשתמש.
- כולל פחות זמן בתיקון הבאגים כפי שהבעיה המסוימת ממוקדת.
- עובד עם אותם נתונים ותהליכים עם בניין חדש לצורך פעולתו.
- אינו דורש הקמת סביבת בדיקה חדשה.
למרות שיש לתהליך הבדיקה החוזרת מספר יתרונות, הוא גם מכיל כמה חסרונות. בואו נבין זאת מהקטע הבא.
חסרונות של בדיקה חוזרת
A retest process also has some drawbacks, which can hamper or create challenges in the testing process. Knowing such limitations will help you address those while retesting to avoid any issues.
בואו נבין מה הם:
- זקוקים לבנית חדשה לאימות פגמים.
- תיקיות הבדיקות של הבדיקה החוזרת יכולים להישאר רק כאשר היא מתחילה.
- אין אפשרות לאוטומט תיקיות הבדיקות לבדיקה חוזרת.
- בדיקת פגמים בבדיקות שנכשלו דורשת זמן ומאמץ נוספים.
- בדיקות חוזרות אינן מובטחות כחלק מתהליך הבדיקות פרט למקרים בהם מצאנו באג או תוקן.
כשמתייחסים לחסרונות של בדיקות חוזרות, אפשר לומר שבדיקה חוזרת עשויה להיות מאתגרת עבור כמה בודקים. במיוחד הבודקים החדשים לעתים מנסים למצוא איזה דרך חלופית לתקן את הבעיה. כאן, מה שמבלבל אותם הוא המושג בדיקת רגרסיה. עם זאת, בדיקת רגרסיה ובדיקה חוזרת מכילות הבדלים משמעותיים.
מה ההבדל בין בדיקת רגרסיה לבין בדיקה חוזרת?
אם אתה חדש בבדיקת תוכנה, אולי תחשוב שהמושגים "בדיקה חוזרת" ו"בדיקת רגרסיה" דומים. עם זאת, זו עובדה ששניהם שונים, אם כי קשורים. נחקור בקטע זה איך תהליך הבדיקה החוזרת שונה מבדיקת הרגרסיה.
קודם כל, השיבוט ובדיקות החזרה הם חלק מהאימות התוכנה בתהליך הפיתוח התוכנה. בדיקת החזרה מתבצעת בעיקר בסוף שלב ספציפי בפיתוח. במילים אחרות, כשאתה רוצה לוודא שמוצר פועל אינו מלא בבאגים מבדיקות קודמות, אתה מבצע בדיקת חזרה. לעומת זאת, בדיקת השיבוט יכולה להתבצע בכל שלב בפיתוח כדי להבטיח את הפעולה הנכונה של היבט מסוים של הקוד.
בחלק מהמצבים, מבקרים יכולים לבצע בדיקות חזרה על ידי קריאת תוצאות בדיקות קודמות או דיווחים כדי לבדוק כל בעיה ותיקון שלה. בדיקה מקיפה יכולה גם להתבצע על ידי בדיקה בנפרד של המקרים הקודמים כדי לוודא שהם מנוהלים. עם זאת, בדיקת השיבוט מתבצעת בעיקר על ידי תכנון בדיקה וביצוע זאת על כל גרסת היישום, החל מהאחרונה. בגישה זו, עליך לוודא שכל שינוי ביישום בדוק באופן נכון.
להלן כמה נקודות מפתח על ההבדלים בין תהליך השיבוט לבין תהליך בדיקת החזרה:
| Component | Regression Testing | Retesting |
|---|---|---|
| Purpose | It is executed to check the impact of the code level changes, which often require retests. | It is done to ensure changes executed in the software that doesn't lead to regressions. |
| Method | It is executed with the use of automation testing tools. | It is done manually as it checks for particular defects |
| Target | It is done to check existing bugs in the software. | Retest verifies the functionality of the software. |
| Time involved | It is more time-consuming because extensive research is needed in previous software versions. | It is less time-consuming because a specific defect is only retested. |
| Focus | It aims to check if the functionality of prior versions is maintained corresponding to the update or change to the application. | It does not focus on the functionality of previous versions. Instead, it aims to ensure the restoration of functionality following a bug fix. |
הבנת בדיקת השיבוט ובדיקת החזרה עם דוגמה
ההבדל בין בדיקת השיבוט לבין בדיקת החזרה יכול להיות הודגם על ידי הדוגמה הבאה.
נניח, שיש בעיה בדף ההתחברות של יישום אינטרנט בנקאי שבו לקוחות אינם יכולים לגשת לפרטים של חשבונם. למרות שהתבקשו לנסות להתחבר שוב, הם נכשלו בהתחברות לחשבון שלהם. הצוות התמיכה בדק את הבעיה והבטיח שדבר כזה לא יקרה שוב.
קבוצת המפתחים ביצעה שינויים ברמת הקוד כדי להבטיח התחברות מוצלחת לדף החשבון בכל דפדפן. עם זאת, הבדיקות כאן לא רק כוללות דף ההתחברות אלא גם מוודאות ששינויי הקוד אינם משפיעים על תפקודיה האחרים של אפליקציות האינטרנט לבנקאות. כאן, הבדיקות שנערכות תבדקנה את היישום לשינויים. זה נקרא בדיקת רגרסיה.
בבדיקת הבעיה שוב בהתאם לשינוי שנעשה, קבוצת הבדיקות ניסתה להתחבר לדף, אך זה לא הצליח. קבוצת התמיכה יצרה קשר עם המפתח המתאים והסבירה את הבעיה. עם זאת, המפתח יידע אותנו שהוא רכש את הבעיה. קבוצת QA בודקת את הפעילות של האפליקציה האינטרנטית כדי לבדוק האם הבעיה נפתרה, זה נקרא בדיקה חוזרת.
לכן, בדיקה חוזרת היא הכרחית בתהליך בדיקת התוכנה והיא קדמון כדי להבטיח את פעילותה.
פנינו אל החשיבות של תהליך הבדיקה החוזרת, מה שנותן מושג על מערכת היחסים שלה עם בדיקת התוכנה. קודם כל, בואו נבין מספר יישומיה המקובלים בבדיקת התוכנה. הנה כמה מהיישומים של בדיקות חוזרות בבדיקת התוכנה:
- מיושמת לתיקון שגיאה ספציפית או באגים מסוימים, שדורשים אימות.
- בודקת את פעילות המערכת השלמה כדי לאמת את התפקוד הסופי.
- בודקת את איכות חלק מסוים של המערכת.
שלבים של בדיקה חוזרת
תהליך הבדיקה החוזרת כולל גישה מלאכותית. היא גם מתחשבת בשלבים העיקריים לבדיקת היישום התוכנה.
להלן השלבים המעורבים בתהליך בדיקה חוזרת:
1. בחירת מקרי הבדיקה
בחירת מקרי הבדיקה היא גישה בה מבוצעת בדיקה מסוימת של מקרים בדיקה ממבחר הבדיקות כדי לבדוק האם תיקון הפגמים בתוכנה נעשה או לא. בדרך כלל, מקרי הבדיקה מופרדים לנצלים ולמיושנים, כאשר מקרי הבדיקה הניתנים לשימוש חוזר משמשים להפעלת בדיקה חוזרת.
2. החלת מקרי הבדיקה
המיקוד העיקרי של תהליך הבדיקה חוזרת הוא להשוות את התוצאה הצפויה של מקרי הבדיקה. לפיכך, עליו להחיל את מקרי הבדיקה עם גיליונות תוצאות מוקדמים סטנדרטיים.
3. הערכת זמן
בזיהוי מקרי הבדיקה, מבקרים צריכים לקחת בחשבון את הזמן הכולל לביצוע בדיקות חוזרות. גורמים כמו ביקורת מקרי הבדיקה עשויים להוסיף זמן נוסף.
4. מעקב אחר מודולים
במצבים של כשלון במקרי הבדיקה, זו אתגר גדול לזהות את המודולים המתאימים לשגיאה. לכן, החלק התוכנתי מחולק למודולים בודדים שונים.
כדי לעשות זאת, מיושנים מקרי בדיקה קטנים למודולים בודדים ספציפיים. המודולים שאינם מציגים תוצאות צפויות מסומנים כמודולים פגומים. בדרך זו, משוחק מעקב אחר מודולים פגומים.
5. בדיקה חוזרת על המודול
בדוק את המודול הפגום עד שהוא מותקן.
6. שיבוט המודול
לאחר תיקון המודול הפגום, מחולק השיבוט המלא של מקרי הבדיקה לתוך התוכנה. עוד, בדק את הפעולה של התוכנה.
איך לבצע בדיקות חזרה?
בדיקות חזרה של יישום התוכנה יכולות להתבצע רק באמצעות גישה ידנית. כפי שהדגשנו בקטע שלמעלה, הסיבה העיקרית היא שהיא מתמקדת רק בפגם ספציפי. לכן, זו גישה מתאימה לבדיקות ידניות מאחר שהיא יכולה להתבצע במדויק יותר מאשר בשיטה אוטומטית.
כדי לבצע בדיקת חזרה, הצוות הבדק צריך להכיר היטב את המצב הנוכחי של יישום התוכנה. הידע זה על הפעולה של התוכנה ואיך להפוך אותה ליעילה על ידי תיקון באגים מקל על הגישה הידנית.
הבודק מבצע ידנית את מקרי הבדיקה כדי לאמת את השינויים שבוצעו ביישום. זה נעשה כדי לוודא ששינויים אלה לא גורמים לפגמים נוספים ושמקרים נכשלים שזוהו נמחקים בשדה החדש. אפשר לבצע בדיקות חזרה ידניות לאחר שינוי השינויים בתוכנה, תיקון הפגמים וסיום מחזור הבדיקות של התוכנה.
אפשר לעקוב אחר השלבים הבאים כדי לבצע בדיקת חזרה ידנית:
- קבע את השינויים ביישום התוכנה ובאיזה אזור יש צורך בבדיקות חזרה.
- בדוק ועדכן את מקרי הבדיקה הדרושים לבדיקות חזרה בהתאם לשינויים.
- מקרי הבדיקה שנפתחו צריכים להיות מבוצעים ידנית.
- נתח את התוצאה האמיתית עם התוצאה הצפויה כדי להעריך שהשינויים לא גורמים לפגמים חדשים.
- אם זוהה פגם, הקפד לתעד אותו ולדווח עליו לצוות הפיתוח.
- חזור על תהליך הבדיקת חזרה הידנית עד שכל הפגמים תוקנו.
אולם, אולי אתה תוהה למה לא ניתן לבצע בדיקות חזרה באמצעות גישה אוטומטית. יש לכך מספר סיבות. בואו נבין רעיון מהקטע הבא:
האם לא ניתן לאטומט בדיקות חזרה?
אי אפשר לבדוק מחדש יישום באמצעות גישה אוטומטית. כמה סיבות נפוצות מודגשות להלן:
- מורכבות: חלק מהמקרים הנכשלים עשויים להתאים עקב המורכבות של התוכנה. לכן, מקרים כאלה קשים לאוטומציה.
- תוצאה לא צפויה: השינויים שנעשו בתוכנה עשויים להביא לתוצאות לא צפויות. מקרי הנכשל במצבים כאלה דורשים בדיקה ידנית לאימות התוצאה.
- עלות ומשאבים: אוטומציה של תהליך הבדיקה החוזרת עשויה להיות יקרה כיוון שזה כרוך בשימוש בחומרה ותוכנה נוספים. קשה להצדיק את העלות של שינויים קטנים בתוכנה.
- מגבלת זמן: אוטומציה של תהליך הבדיקה החוזרת כרוכה בהקצאת כמות זמן ניכרת, וככלל ישנה לחץ לשחרור בזמן, ולכן גישה ידנית היא האופציה הטובה ביותר.
דברים לשקול בעת ביצוע בדיקות חזרה
עד כה הבנו את החשיבות של תהליך הבדיקה החוזרת ואיך לבצע אותו. עם זאת, קיומם של השקפות תקפות בבדיקות חוזרות דורשת תשומת לב. להלן כמה נקודות שצריך לקחת בחשבון.
- תהליך הבדיקה החוזרת דורש יצירת בניין תוכנה חדש כאשר הבעיה מתוקנת על פי הדיווח הראשון.
- קיימת האפשרות שתוכנה שנשלחה לבדיקות חזרה עשויה לעבור שינויים ברמת הקוד. לכן, חשוב מאוד לבצע בדיקות רגרסיה לפני שחבילת היישום משוחררת.
- הכיסוי והיקף הבדיקה החזרה יכולים להתברר רק לאחר שהבעיה תיקונה. כתוצאה מכך, אין אפשרות לבצע אוטומציה לבדיקות החזרה כמו ברגרסיה.
- זמן הפיתוח של היישום עשוי להתרחב אם הבעיות שנמצאות בבדיקות החזרה נותרות להתקיים. נדרש בחינה מקיפה ואסטרטגית יותר לחקירת הסיבה הבסיסית.
עם זאת, למרות האתגרים שנפגשים בתהליך הבדיקה החזרה, הארגון חייב להתמקד בשיטות הבדיקה בכפיית מקצוע. זה יכול להתבצע באופן טוב יותר על ידי ביצוע בדיקות חזרה בענן. בואו נבחן זאת בפירוט.
איך לבצע בדיקות חזרה בענן?
אוטומציה של תהליך הבדיקה החזרה אינה אפשרית תמיד, ודרוש בדיקה ידנית להבטיח איכות התוכנה. עם זאת, זה עשוי להיות זמני במקרים מסוימים ולא תהליך מתקדם. פלטפורמות בדיקות ענן עוזרות לך להתגבר על אתגרים קשורים לתשתית הבדיקות.
Source:
https://dzone.com/articles/retesting-tutorial-a-comprehensive-guide-with-exam