עד כמה להשקיע בבדיקות תוכנה?

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

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

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

כן נרצה לעמוד כל מספר כללים חשובים בתהליך הבניה הבדיקות:

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

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

אם אתם זקוקים לייעוץ בבניית אסטרטגית בדיקות, צרו קשר.

בודקי תוכנה הזקוקים לכלים פרקטיים לבדיקות, כנסו לקורס הדיגיטלי שלנו.