סוגי בדיקות הולידציה

יש שני סוגים של בדיקות וריפיקציה:

1. "קופסה לבנה", white box. אלו בדיקות שבהן נדרש הבודק בידע תכנותי. עליו למצוא בעיות ולהביא את הסיבות להן. בד"כ אנשי הפיתוח עורכים בדיקות אלה.
2. "קופסה שחורה", black box. בדיקות "חיצוניות" של האפליקציה מבלי להכנס לקוד.

בדיקות white box כוללות:

1. בדיקות יחידה, unit tests. הכוונה היא שכשמוצר מורכב מכמה חלקים, כמו שבד"כ זה קורה, והיישומים כוללים אינטגרציה בין החלקים, אז קודם כל בודקים חלק חלק בנפרד.
   למשל נניח שהמוצר הוא אתר אינטרנט, והוא מורכב מחלק שקשור לבסיס נתונים, חלק שקשור ל-GUI או לממשק הגראפי וחלק שהוא מנוע חיפוש. אם מוסיפים יכולת למנוע החיפוש אלו שינויים בכל התחומים הללו: יש להוסיף את האפשרות למשתמש ב-GUI, לשדרג את אלגוריתם החיפוש ולשנות בהתאם את בסיס הנתונים. אז לפני שמחברים את הכל ביחד כל פונקציה פיתוחית מתאימה בודקת את החלק הרלונטי שלה. לזה אין בד"כ ממשק משתמש וגם לכן דרוש מפתח.
   סיבות ותועלת:
   א. תיקון באג בשלב הזה יעיל וחסכוני לאין שיעור ממציאתו בנקודות הבאות בתהליך (אינטגרציה, בדיקות וכו'). גם כי זה "טרי" אצל המפתח בראש, גם כי ברור שהבעיה היא בחלק שלו (מה שלא ברור תמיד במוצר הגמור), וגם אם יש שינוי שקשור לקומפוננטה אחרת זה המקום החסכוני לעשות זאת.
   ב. לבודק ייקח הרבה יותר זמן להבין ולשחזר את הבעיה.
2. בדיקות אינטגרציה של היחידות (נקרא גם: Private Integration): בדיקות של החיבור בין המערכות, גם באחריות הפיתוח. על צוות הבדיקות לוודא שבדיקות האינטגרציה התבצאו במלואן, ואם משהו לא תוקן לקבל עליו מידע. מן הראוי שמהנדסי הבדיקות יעברו על מסמך הבדיקות של הפיתוח ויוסיפו אם צריך.

בדיקות black box כוללות:

1. בדיקות אינטגרציה "חיצוניות": במקרים של מערכות גדולות שיש הרבה סיכון ברבדים הנמוכים של האפליקציה: התקנה מסובכת, דרייברים חדשים, חומרה חדשה וכו' לעתים יש צוות אינטגרציה בעל ידע ספציפי בתחומים הללו, לפעמים גם ידע תכנותי. היתרון: מציאה וטיפול מהיר בבעיות שלא תמיד יכולות להתגלות ע"י הבדיקות. גם הפיתוח מתייחס אליהם אחרת, מהר יותר, כי הבעיות שהם מגלים בד"כ קריטיות.
2. בדיקות יוזביליות: לוודא את התאמת האפליקציה לדרך בה משתמשים בה משתמשי הקצה והאדמיניסטרטורים, ולא מאלצים את המשתמשים להתאים את עצמם לתוכנה.
   א. בדיקת קיום סטאנדארטים. אם לא הרשמיים שיוצאים ע"י האגודות, לפחות את הסטאנדרטים המקובלים.
   ב. גישתיות (Accessibility). האם המשתמשים יכולים לנווט ולצאת באופן אינטואיטיבי (או עם הסברים נאותים).
   ג. Responsiveness. האם המשתמשים יכולים למלא את רצונם, בזמן שהם רוצים ובצורה ברורה?
   ד. יעילות. האם המשתמשים יכולים למלא את רצונים במינימום צעדים וזמן?
   ה. הבנתיות. האם המשתמשים מבינים את מבנה המוצר, את מערכת העזרה ואת התיעוד שלה?
3. בדיקות פונקציונליות:
   א. שימוש נכון במוצר. בדיקה של הדרישות: אם עושים X קורה Y.
   ב. שימוש שאינו נכון. לחיצות חוזרות ונשנות על אותו כפתור למשל.
   ג. בדיקות GUI. מיקום המסגרות, אי-חריגה בשל טקסט רק.
   ד. פעילויות של משתמש קצה. חשוב ביותר. למשל משתמש "רגיל" מתחבר, הולך למקום מסויים, עושה פעילות כזו או אחרת, חוזר, הולך למקום אחר וכד'.
   ה. שימוש אפקי, או זרימה. מתחיל תהליך מסויים עם המשתמש למשל, הוא מכניס מידע, וידוא שהמידע עובר נכון בכל נקודה, שהמערכת אח"כ משתמשת נכון במידע וכד'.
   ו. מקרי קצה. הכנסת ערכים גבוהים או שליליים או נמוכים, תמונה במקום של טקסט וכד'.
   ז. בדיקה שכל היישומים הרשומים בדרישות נכנסו (ברור למה) וגם מה שאינו שם לא נכנס (לכרואה יופי, עוד פונקציונליות, אבל אם זה לא רשום זה לא ייבדק כראוי ויביא לתלונות מרובות של המשתמשים).
   ח. אינטגרציה עם אפליקציות אחרות. אם המוצר שומר למשל קבצי אקסל, יש לפתוח ולראות תאימות.
4. בדיקות מערכת:
   א. האם יש התראות לכל בעיה שצצה?
   ב. שימוש בבסיסי נתונים גדולים.
   ג. בדיקות עומס.
   ד. security.
   ה. ביצועים.
   ו. שימוש במשאבי מערכת.
   ז. התקנות.
   ח. recovery. של המערכת.
   ט. recovery. של נתונים.
   י. מהימנות. עבודה לאורך זמן.
   יא. רשיונות (גם של צד ג').
   יב. תאימות לדרישות.
   יג. האם זה באמת נותן ללקוח את הכלים שלהם הוא זקוק?
5. acceptness tests או ATP, או GFAT. בדיקות סופיות של המוצר מהקיט הסופי. התקנה וריצה על פונקציונליות מרכזית, קיימת וחדשה.