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