שיטות הבדיקות המסורתיות מייעלות את תהליך הבדיקות הגדול והריכוזי אך מתקשות לתמוך במסירה מהירה של פיתוח אג'ילי
מאת: דייגו לו ג'ודיצ'ה, אנליסט ראשי בחברת Forrester Research
שיטות הבדיקה המסורתיות נועדו לייעל את התפעול של קבוצות בדיקה גדולות וריכוזיות באמצעות מודל מרכזי בדיקות (TCoE). אך גישת השירותים המשותפים מתפרקת בארגונים אג'ילים מכיוון שהיא לא יכולה לתמוך בקצב המסירה של צוותי הפיתוח האג'ילי והמהיר.
בזמן שהמפתחים שלכם עוברים לשיטות עבודה גמישות ומהירות, הם יבצעו יותר ויותר בדיקות בעצמם. שיטות עבודה מתקדמות כגון פיתוח מונחה-בדיקות מגבירות את האוטומציה של הבדיקות, ובנייה ואינטגרציה מתמשכות משפיעות על הפעילויות היומיומיות של מפתחים ובודקים.
השינויים בשיטות הבדיקה משנים גם את האופן שבו צוותי הפיתוח בוחרים כלי בדיקה. המפתחים רוצים כלים שקל לחבר לסביבות הפיתוח המשולבות (IDE) שלהם, בזמן שאנשי ה-QA ומומחי בדיקות אחרים מעדיפים כלים שמציעים הפשטה ברמה גבוהה יותר וקלים יותר לשימוש.
מה מונע צוותי בדיקות מסורתיים מלהדביק את הצוותים האג'ילים ?
- נפח גדול של פעילויות בדיקה ידניות מאט את המסירה. בדיקות ידניות הן הגישה הוותיקה ביותר ועם זאת הנפוצה ביותר לבדיקת תוכנה במרכזי בדיקות (TCoE). מומחי בדיקה מפתחים מקרי בדיקות שמכסים כמה שיותר פונקציונליות, מה שמחריף את הבעיה. אי אפשר להתעלם מהעובדה שבדיקות ידניות דורשות זמן ומשאבים. אפילו גדוד של בודקים ידניים לא יכול להתמודד עם הבעיה; בדיקות ידניות פשוט לא יכולות להתמודד עם המבנים החדשים, האינטגרציה השוטפת, ועם קצב הבדיקות הפונקציונליות והלא פונקציונליות של צוותי המסירה האג'ילים. הנקודות הבאות מדגימות איך בדיקות מסורתיות משפיעות על מחזור החיים של פרויקט פיתוח IT:
- הצוותים דחו את הבדיקות לסוף הפרויקטים, ובכך דחסו אותן מאד. סתירה נוספת שמופיעה לעיתים קרובות בגישות בדיקה מסורתיות היא שהצוותים מתחילים את הבדיקות רק לאחר שפיתחו ושילבו את המערכת, מה שנגרם בין השאר בשל העלויות והזמן הכרוכות בבדיקות ידניות. למרבה הצער, פרויקטים בדרך כלל לא עומדים בלוחות הזמנים, ולכן הצוותים דוחסים ומקריבים את הפעילויות שנותרות בסוף התהליך. כתוצאה מכך, הזמן שמוקצה לבדיקות מוקרב על מנת לחפות על עיכובים בתהליכים אחרים, מה שמוביל להתפשרות על האיכות.
- ליקויים שהתגלו בשלב מאוחר יכולים להוריד פרויקטים מהפסים. ככל שליקוי נמצא בקוד יותר זמן ללא טיפול, כך יידרש למפתח זמן רב יותר לתקן אותו, וההשלכות על לוחות הזמנים של הפרויקט יהיו הרסניות. המפתחים ממשיכים לכתוב קוד חדש ובעיות חדשות ושוכחים את הקונטקסט של הפיצ'רים שהם כבר עבדו עליהם (אתם יכולים לזכור מה אכלתם לארוחת צהריים ביום שני שעבר?). כשהם חוזרים לליקוי שהם כתבו לפני מספר שבועות ואף חודשים, לוקח להם זמן להכיר מחדש את הקונטקסט של הקוד.
- הצוותים צוברים יותר מדי חובות טכניים. שיטה מובטחת לעכב את לוחות הזמנים היא לגלות בשלב מאוחר של מחזור הפיתוח שיש בעיות רציניות עם איכות היישום. גילוי מאוחר של ליקויים מוביל לשיעור גבוה של עבודה כפולה ובזבוז. הדבר גרוע אף יותר אם בעיות האיכות הן מערכתיות – כגון בעיות בתכנון הארכיטקטורה – או אם מישהו מגלה שחסרות פונקציות. בסיסיות למשתמש. כשמתחילים את הבדיקות בשלב מוקדם יותר – במיוחד בדיקות מערכת ובדיקות קבלה של המשתמשים – הסיכונים המערכתיים יצופו מוקדם יותר.