ראשית עלינו להבדיל בין בקרת איכות - QA, לבדיקות קבלה (Acceptance Test).
בקרת איכות היא תהליך החוזר על עצמו בכל פריסה של המוצר בסביבת הייצור. למעשה בקרת איכות היא בדיקת המוצר כWhite Box. ניתן על כן להוסיף בדיקות אילו כבדיקות האינטגרציה (Integration Tests) של המוצר, להם יש תפקיד דומה עם מספר הבדלים סמנטיים. בקרת איכות צריכות להתבצע במהירות מרבית, קרי דקות, בכל (!!!) פריסה ועל מגוון רחב של קונפיגורציות (למשל פרמוטציות על אוסף מערכות הפעלה ודפדפנים). על מנת להגיע לכך, בדיקות אילו חייבות להיות ממוכנות.
בדיקות קבלה הם בדיקות שהלקוח צריך לעשות על מנת לאשר שאכן המוצר תואם את הציפיות כפי שנכתבו בהגדרות המוצר (spec). על פי רוב הלקוח הוא מנהל המוצר המייצג את משתמש הקצה, ויש לדרוש ממנו להגדיר את הבדיקות בהגדרת המוצר. בדיקות הקבלה הם על פי רוב ידניות בהנחה שמדובר בממשק ויזואלי, והם מתבצעים ע"י מנהל המוצר באבני דרך או סיום המוצר.
בדיקת איכות צריכה לכלול לפחות את כל בדיקות הקבלה, מקרי קצה, טיפול בשגיאות, התקפות זדוניות (או יותר גרוע: משתמשים מבולבלים), ובדיקות של באגים שהתגלו עם הזמן.
מטבע הדברים בודק אנושי לא מסוגל לבצע את הבדיקות במהירות הנדרשת ולהבטיח חזרתיות מושלמת על פני כל הקונפיגורציות הרלוונטיות. כמו כן, ניתן לוודא שהבדיקה רצה ואף לבדוק את הבדיקה ע"י בדיקות צולבות שאנו עושים במקרים סבוכים, אך קשה לבדוק שבן אדם מבצע את הבדיקות כמו שצריך מבלי לחפף או לשכוח פרטים.
בעקרון, לא ניתן להגיע לפריסה ממשכת עם בקרת איכות ידנית, אף כי גם ללא פריסה ממשכת כדאי מאוד למכן שלב זה.
אולם הבעיה הגדולה ביותר לגבי בדיקות היא ההשלכה על התרבות הארגונית. כאשר ישנו אדם נוסף שאחראי לאיכות קטע קוד אז האחריות למעשה מתחלקת והמפתח נוטה להמעיט בכמות ואיכות הבדיקות. הדבר גורם לקטעי פונקציונליות ליפול בין הכיסאות ומשליך על ירידה באיכות המוצר.
