במוצרי תוכנה תמיד יש מתח בין זמן אספקת התכונה או הגרסאות והתיקונים שלה, לבין איכות המוצר. כולנו מסכימים שאיכות תוכנה ירודה היא אסון, אף מנהל פרויקט או מנהל מוצר לא מוכן לשחרר מוצר באיכות ירודה העיקר לעמוד בלו"ז, עם זאת המשאבים שלנו בודקי התוכנה בציר זמן הפרויקט מאוד מאוד מוגבל. אז מה עושים ומה המתח הנכון בין זמן הבדיקות לאיכות התוכנה?
שיטות עבודה
אחד מהגורמים המשמעותיים המעכבים את הפרויקט בזמן הבדיקות הוא היעדר שיטות עבודה ומסכמות. במידה ואנחנו לא נגדיר את מספר סבבי הבדיקות מראש, את מדדי האיכות במעבר בין סבב לסבב (לדוג' אין תקלות גבוהות בכלל ועד חמש תקלות בינוניות פתוחות) זה מתיחת זמן ארוכה מדי של בודקי התוכנה במוצר או זמן קצר מאוד לשלב זה מאוד תלוי בפוליטיקה האירגונית והחשיבות של ה QA במקום להסתכל עניינית על המוצר והאיכות שלו.
פינגפונג תקלות בין צוות הפיתוח לבין הבודקים ועד סגירה מוסכמת של תקלות עשויות אף הן להאריך בצורה מיותרת את זמן הבדיקות, שיטות עבודה כגון האג'יל יקטינו מעבר התקלה בין התחנות השונות והבקרה עליהן. כתוצאה מהצוות אחד המתנהל באינטרס משותף לאיכות תקלות גבוהה וסגירת מרווחי זמן קצרים לטובת פתיחת הספרינט הבא.
אוטומציה
שילוב של כלים אוטו' עוזר מאוד כשיש לנו מוצר עובד ואנחנו בשלב שחרור גרסאות באופן תדיר, למעשה את כל בדיקות הרגרסיה אנחנו יכולים ושאופים לסגור באמצעות בדיקות אוטו' וחיסכון בזמן של בודק ידני שיכול להתפנות ולבדוק פיצ'רים חדשים וחוקה עסקית שטרם נבנו עליה תסריטים אוטו'.
מעוניין להתמקצע בבדיקות תוכנה? כנס עכשיו לקורס שלנו >>
TesQA 