הנתיב הקריטי בבדיקות תוכנה QA
כל בודק תוכנה מכיר את שיטות העבודה המקובלות היום בתהליכי פיתוח תוכנה, מנהל הפרויקט / מנתח המערכות מגיע עם מסמך איפיון ובמקש לייצר מסמך STP ומסמך STD לטובת ניהול תרחישי הבדיקות.
מסמך הבדיקות יכול להיות במטריצות בדיקה של עשרות מאות ואף אלפי צעדי בדיקה, שבעולם המציאותי של זמן = כסף מחוייבותו של בודק התוכנה להפעיל שיקולי עלות תועלת בבדיקות ולרכז את הנתיב הקריטי והפחות קריטי בבדיקות.
אז איך מוצאים את הנתיב הקריטי בבדיקות תוכנה? לאחר שבינינו את מטריצת הבדיקות שהינה מכפלה קרטזית של הערכים אל מול השדות ותהליך הבדיקה. ליד כל עמודה נדגיש את אחוזי החשיבות והשכיחות של כל תרחיש, נכפיל את האחוז עם כמות ונחלק באופן יחסי. בצורה כזו נקבל לכל תרחיש את חשיבות הבדיקה, ויש להתחיל עם התרחישים הגבוהים ביותר בחשיבות שלהם ועד לתוצאת ה 50% לפחות. כמובן שמנהל הפרויקט יכול לקבל החלטה גם לעלות ולהוריד את הסיכון ובהתאם למצב הפרויקט או חשיבות התהליך.
בהצלחה…
TesQA 