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