5 כללים להצלחה בבדיקות תוכנה

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

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

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

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

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

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

בודק תוכנה? רוצה להרחיב את ארגז הכלים שלך? כנס עכשיו >>