הבטחת איכות תוכנה – הבדלי גרסאות

תוכן שנמחק תוכן שנוסף
שורה 11:
דוגמה לתהליך המושפע מעקרונות הבטחת האיכות הוא שימוש ב[[תקן|תקנים]] עבור מסמכים המתעדים את הפיתוח (לדוגמה - תקן ISO-830, או [[נוהל מפת"ח]], לתיעוד דרישות המערכת (SRS)).
 
דוגמה נוספת לתהליך שמושפע מעקרונות הבטחת האיכות הוא [[בקרת איכות|בקרת איכות תוכנה]], הלא הוא תהליך הבדיקות. השלב הראשון בבקרת איכות תוכנה הוא היכרות עם המערכת הנדרשת לבדיקה. השלב השני הוא כתיבת תסריטי בדיקה שמטרתם לבחון את כשירותם של המודלים השונים של התוכנה במצבים שונים. לעתים מתלווה לבדיקה הידנית או מחליפה אותה בדיקה באמצעות כלי בדיקה אוטומטיים (ישנם מספר מוצרים מסחריים, וגם כלים חופשיים תחת רישיון קוד פתוח, כמו CUnit/[[JUnit]]/CPPUnit לבדיקות רמת היחידה, [[BugZilla]] לניהול תקלות, וכדומה). בבדיקה מסוג זה נכתב תסריט המורץ באופן אוטמטיאוטומטי על ידי התוכנה במצבים שונים. בין סוגי כלי הבדיקה הקיימים ניתן לציין כלי בדיקה שמטרתם לבדוק עומסים על אתרי אינטרנט. כלים אלו מדמים כניסה של משתמשים לאתר כדי לבחון את מהירויות הגלישה בעומסים שונים.
 
למרות שחברות העוסקות בייצור תוכנה מעסיקות אנשי הבטחת איכות, מהנדסי בדיקות תוכנה ובודקי תוכנה, במרבית התוכנות היוצאות לשוק נמצאים באגים. דבר זה נובע מכמה סיבות:
שורה 18:
* באגים יכולים להיות "יחסיים" - מה שלאחד נראה תקין, לאחר יראה כתקלה, וכל עוד אין הגדרה מסוימת בדרישות התוכנה (ולעתים גם אם יש), תיקון הבאגים יהיה תוצר של פשרה בין צוותי הפיתוח והשיווק.
 
המטרה של בדיקות תוכנה היא לוודא שהמוצר עונה על הדרישות שהוצבו (ולידציה), וכן למצוא באגים בתחומים שלא מכוסים על ידי הדרישות (או לא מכוסים מספיק).
 
==הפן המחקרי==