Global Side Menu Width
Placeholder

עקרונות QA

שבעת עקרונות הבדיקה

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

הפסיכולוגיה של בדיקות

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

בדיקות מאפשרות למדוד את איכות תוכנה – QA.

מדוע בדיקות נחוצות ועד מתי לבדוק ?

ללא QA המוצרים יהיו עם הרבה BUGS וכתוצאה מזה יהיו FAILURES. כלומר בעזרת QA אנשי בדיקות תוכנה בודקים ש-BRS-Business Requirement Specification
ו-System Requirement Specifications
שזה אכן מתקיימים כנדרש.

QA מעלה את ה-QUALITY של המוצר ומוריד RISK של FAILURES

כמה צריך לבדוק?

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

בנוסף במסמך STP מוגדרים מתי יש להפסיק תהליך בדיקות (מקרים קיצונים).

תפקידים ראשים בעולם QA ?

Test leader/manger

מוביל בדיקות – אחרי על אנשי בודקי תוכנה (testers) שמנהל את כל תהליך של הבדיקות. להלן תפקידים של מוביל בדיקות (Test leader)

  • בניית אסטרטגיית הבדיקות בתיאום עם הנהלה.
  • הערכת זמן ומאמץ כולל עלות הבדיקות.
  • כתיבת מסמך STP, מעקב אחרי תוצאות הבדיקה של מסמך STD.
  • כתיבת דוחות סיכום STR.

TESTERS – בודקי תוכנה

  • אחרים על כתיבת מקרי בדירה
  • כותבים מסמך STD
  • מעריצים ומדווחים גל הבאגים
  • עושים בדיקות רגרסיה ו-RE-TESTING …

ארגון הבדיקות

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