שאלות ותשובות


מהו תפקידו של בודק תוכנה ?

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

QA - Quality Assurance

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

STR

Software Test Report / Software Test Results  -  דו"ח ביצוע בדיקות תוכנה מסמך המכיל את תיעוד מהלך ביצוע הבדיקות ועוד נתונים חשובים כמו: 1. סיכום תקלות וחומרתן 2.נתונים סטטיסטיים על מהלך הבדיקות.

STP

Software Test Plan
מסמך המהווה מסגרת לפרוייקט בדיקות תוכנה:
*סקירת המערכת הנבדקת - מה מתוכנן לבדוק מבחינת QC .
* שיטת ותכולת הבדיקות.
* משאבים נדרשים לבדיקות - הכשרת צוות בודקים, כלי בדיקות.
* ניהול הבדיקות וניהול הממשק עם צוותים אחרים. * נקודת בקרה ודיווח.        
* בקרת סיכונים.

STD

Software Test Description - מסמך מפרט הבדיקות. * מסמך המפרט את מקרי הבדיקה המתוכננים מתוך התייחסות לנתוני הקלט והפלט הצפוי. * הגדרת דרישות מוקדמות מבסיס הנתונים ותאור מפורט של רכיבי סביבת הבדיקות.

SPR

Software Problem Report -
מסמך פרוט תקלות הפיתוח.
* מסמך המפרט את רשימת התקלות שהתגלו במהלך הבדיקות. * הדוח מפרט תקלות סגורות ופתוחות בחתכים שונים: פרויקט / צוות פיתוח / חומרה /פתוחת/סגורות.                                                                                                                             

Unit

בדיקות יחידה - מתוך ויקיפדיה, האנציקלופדיה החופשית

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

Integration

בדיקות אינטגרציה - מתוך ויקיפדיה, האנציקלופדיה החופשית

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

System

בדיקות מערכת - מתוך ויקיפדיה, האנציקלופדיה החופשית
בדיקות המערכת בכללותה, בדרך כלל בראיית המשתמש של יכולות המערכת.

Acceptance tests

בדיקות קבלה - מתוך ויקיפדיה, האנציקלופדיה החופשית

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

Functional

בדיקות פונקציונליות - מתוך ויקיפדיה, האנציקלופדיה החופשית - לאימות פעילות המערכת.
בדיקות אלו מבוססות על מסמך הדרישות ומסך האפיון ומטרתן לבדוק כי המערכת עושה את מה שהיא צריכה ולא עושה את מה שאינה צריכה לעשות (valid and invalid testing)

Usability

בדיקות שימושיות - מתוך ויקיפדיה, האנציקלופדיה החופשית
בדיקות נוחות השימוש ויעילות העיצוב של האפליקציה ונגישות לבעלי מוגבלויות. לדוגמה: נוחות השימוש בתפריטים, ניווט נוח והתמצאות באתר.

GUI

בדיקות ממשק לקוח - מתוך ויקיפדיה, האנציקלופדיה החופשית

בדיקות הפקדים והשדות במסך. התנהגות תקינה, פורמט של שדות, בהתאם לחוקיות המוגדרת ברמת המסך ולא הלוגיקה העיסקית. לדוגמה: בדיקת מינימום ומקסימום תווים בשדה.

Load

בדיקות עומס - מתוך ויקיפדיה, האנציקלופדיה החופשית

אימות יכולת התגובה של צד השרת במערכות שרת/לקוח בהן צפויים משתמשים רבים בו זמנית. בדיקות אלו מתמקדות במדידת זמני התגובה ובמציאת "נקודת השבירה" של המערכת. בודקות מלבד "משתמשים וירטואלים" גם עומסים הנובעים מטרנזקציות וג'ובים המתרחשים "בבטן" של המערכת (לא רק תהליכים עיסקיים).

Performance

בדיקות ביצועים - מתוך ויקיפדיה, האנציקלופדיה החופשית
בדיקת ביצועים של המוצר בקונפיגורציות ורמות עומס שונות, ומדידת הביצועים לצורך תיעוד/השוואה לדרישות. 

Regression

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

Compatibility

בדיקות שילוב מערכת - מתוך ויקיפדיה, האנציקלופדיה החופשית
לאימות יכולת שילוב התוכנה/רכיב תוכנה במערכת קיימת/חדשה (למשל - תאימות של התוכנה לעדכוני מערכת הפעלה, דפדפנים שונים, תוכנות אחרות שהתוכנה אמורה לעבוד בשילוב עימן, וכדומה).

Alpha/Betha Testing

בדיקות אלפא/בתא - מתוך ויקיפדיה, האנציקלופדיה החופשית
בדיקות שמבוצעות על ידי קבוצת משתמשים מוגדרת סגורה (אלפא) או פתוחה (בתא) אשר משתמשים במוצר ומדווחים על תקלות הצפות תוך כדי שימוש שוטף.

Sanity

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

Smoke

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

BlackBox

בדיקות קופסה שחורה -מתוך ויקיפדיה, האנציקלופדיה החופשית
בדיקות קופסה שחורה (באנגלית Blackbox testing) על פי ארגון ה-ISTQB הן 'בדיקות פונקציונאליות או לא פונקציונאליות המתבצעות ללא התייחסות למבנה הפנימי של הרכיב או המערכת'. זוהי שיטה להגדרת בדיקות ולא שלב במעגל החיים של המוצר. לפיכך ניתן לבצע בדיקות קופסה שחורה בכל אחת מהרמות של בדיקות התוכנה: בדיקות יחידה, בדיקות אינטגרציה, בדיקות מערכת ובדיקות קבלה.
בבדיקות קופסה שחורה מתייחסים אך ורק לקלט ולפלט שהבודק מכניס לתוך המערכת, והבדיקה היא שהפלט המתקבל או הפעולה שקרתה באמת זהה לצפי. בשל כך, רוב הבדיקות הנערכות במסגרת בדיקות אלו הן פונקציונאליות שכן בדיקות לא פונקציונאליות קשה יותר לבדוק במידה ואין יכולת לשנות את מצבה הפנימי של המערכת.
המשלים לבדיקות קופסה שחורה הן בדיקות קופסה לבנה, שהיא שיטה לבדיקת ההשפעה שיש לקלט או לפלט על המבנה הפנימי של המערכת.

White Box

עריכת בדיקות קופסה לבנה. מתמקדת במבנה הפנימי של התוכנית: מסלולים חישובים המתאימים למצבי קלט שונים.