נהוג לחשוב על בדיקות תוכנה בהיבטי לו"ז סיכון, כלומר כשאנחנו ניגשים לתוכנה וממפים את התכולות העסקיות, ואפשרויות הבדיקה, אנחנו יכולים להגיע לקירוב של אין ספור בדיקות, צמתי החלטה שונים מסתעפים ומייצרים מכפלות בדיקה ארוכות ומורכבות. כשניגשים למיפוי תרחישי הבדיקות, אנחנו מסווגים אותם על פי קריטריון של שכחיות האירוע, כלומר עד כמה התהליך העסקי או המקרה הפונקציונאלי שכיח שיתרחש אל מול הקריטיות וחומרת הבעיה למקרה שיתקיים תהליך שגוי באירוע מסוג זה. בצורה כזו אנחנו מגיעים למטריצה של בדיקות המבוססת סיכונים.
אז מה זה פרמידת הבדיקות?
היא מבוססת על כמות של סוגי בדיקות שכדאי להשקיע בהם וככל שמתקדמים לשפיץ הפרמידה כך סוגי הבדיקות ילכו ויתמעטו.
בבסיס הפרמידה נמצא Unit Test – שהגישה היא לבצע כמה שיותר בדיקות מסוג זה, הרי וקל ופשוט לבדוק אותם, ניתן למצוא מהר מאוד תקלות ולתקן אותם בקירוב לבדיקה.
שכבה אחת מעלה נמצא בדיקות האינטגרציה – קצת יותר מורכב לבצע בדיקות אינטגרציה מבדיקות היחידה, אולם לא נדרש להפעיל מסכים ו GUI מושלם כדי לקבל תמונת מצב איכותית.
בדיקת קומפוננטה – כשיש לנו כבר רכיבים עובדים, מסכים עובדים, אבל לא מושלם ב UI / UX ניתן לבצע בדיקות פונקציונאליות, כדי להבין את הלוגיקה התהליכית, ובדיקות הערכים וגבולות קצה.
בדיקות E2E – זה השלב הסופי בפרמידה, כי ההשקעה בתהליך בדיקות זה מצריך משאבים רבים יותר משאר הבדיקות, שכלל רכיבי התוכנה עובדים ונבדקים.
TesQA 