בדיקות מערכת בכלל ובדיקות תוכנה בפרט הוא נושא מרכזי במחזור חיי מערכת. זהו השלב בו נבדקת ונבחנת המערכת לעומק, הן מול הדרישות המקוריות והן מול "היגיון הפשוט" שיש לכל אחד. זהו שלב קריטי לתוכנות שנכתבו in-house וגם לתוכנות של מוצרי מדף הנמכרים בשוק הכללי.
כל באג ותקלה שלא יאותרו בשלב הבדיקות יעלו פי כמה וכמה בתהליכי התחזוקה והשירות ללקוח (CRM), שלא לדבר על פגיעה במוניטין החברה וחוסר שביעות רצון בקרב הלקוחות.
עם זאת, שלב הבדיקות סובל ממספר בעיות רציניות, בראשן שתי הבעיות הבאות:

1. זהו שלב לחוץ ביותר בתהליך פיתוח מערכת. הפיתוח בדרך כלל גולש בלוחות זמנים ותקציב ושואב לתוכו את כח האדם הטוב ביותר. לשלב הבדיקות נשארים "השיריים": לוח זמנים בלתי אפשרי, תקציב מדולדל וכח אדם בדרגה נמוכה יותר (כי הטובים נמצאים בפיתוח).
2. גילוי תקלות ובעיות בשלב הבדיקות הוא מאוחר מדי ועולה הרבה יותר אילו התגלו תקלות ובעיות אלו בשלב הפיתוח.

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

אימות והוכחת תקפות (V&V), או בשמו האחר "פיתוח מלווה איכות כוללת", הוא אוסף פעולות, שיטות וכלים התורמים לאמינות המערכת ותקפותה. ניתן לחלק תחום רחב זה לשני פלחים עיקריים:

1. בדיקות מלוות פיתוח
   פלח זה הוא "פריסת" שלב הבדיקות על פני מחזור החיים וגלגול תכנית הבדיקה משלב לשלב. הדגש כאן הוא על מכלול הבדיקות המתבצעות לאורך מחזור החיים של הפרויקט החל מאפיון המערכת, דרך שלב עיצוב ובנייה, התקנה והרצה, תפעול ותחזוקה, כולל שלב הבדיקות עצמו, כמובן. פלח זה מכיל מגוון רחב ביותר של טכניקות וסוגי בדיקה שחלקן מתבצע ע"י צוות הפיתוח ולאו דווקא ע"י בודקים מקצועיים. ביתר פירוט, מכיל נושא זה את הבדיקות הבאות (נוסף לשלב הבדיקות עצמו):
   
   • בדיקות יחידה – Unit Tests
   • בדיקות קוד – Code inspection
   • בדיקות שילוב – Integration Tests
   • בדיקות התקנה –Installation Tests
   • בדיקות רגרסיה – Regression Tests
   • סימולציות
   • בדיקות בסביבות פיתוח דינאמיות: RAD
סוג הבדיקה הבולט ביותר הן בדיקות היחידה (Unit tests) אשר מדגישות את אחריות המתכנתים ומעורבותם בתהליך ומשתלבות היטב בגישת הפיתוח החדישה של תורת האובייקטים.

2. ניהול איכות
   הפלח השני הוא פעילויות איכות כלליות שאינן נופלות תחת ההגדרה של בדיקות, אדרבא, הן חוסכות בדיקות. בפלח זה כלולות הפעילויות החשובות הבאות:
   
   • עריכת סקרים ושיקופים – Review
   • ניהול סיכונים – Risk Management לאורך כל תהליך הפיתוח
   • ניתוח חלופות
   • תיעוד: כתיבה, ניהול ובקרה
   • אמידת עלויות
   • עלות\תועלת
   • עמידה בתקני איכות (ISO9000, CMMI)
   • ניהול תצורה

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