איך לשלב סוגי בדיקות שונים באסטרטגיה הגיונית שמתאימה לפרויקט שלכם.
איזה כיף שחזרת! במאמר הקודם הצגנו את הבסיס לגישה לסוגי הבדיקות השונים ולמה שהם מכילים, והבהרנו את ההגדרות של סוגי הבדיקות. זוכרים את התמונה הזו של המם הקטן? יכול להיות שאתם תוהים איך כל סוגי הבדיקות שלמדתם עליהם יכולים לעבוד ביחד.
בשלב הבא נסביר איך עושים את זה. במאמר הזה נסביר איך לשלב את סוגי הבדיקות האלה באסטרטגיות הגיוניות ולבחור אסטרטגיה שמתאימה לפרויקט שלכם.
כדי להבין טוב יותר את המשמעות של האסטרטגיות, אפשר להשוות אותן לכמה צורות. ברשימה הבאה מפורטות אסטרטגיות עם הגדלים והיקפי הפיתוח המתאימים.
בואו נבחן את האסטרטגיות מקרוב ונבין את המשמעות של השמות שלהן.
הגדירו את יעדי הבדיקה: מה אתם רוצים להשיג באמצעות הבדיקות האלה?
לפני שמתחילים לבנות אסטרטגיה טובה, צריך להגדיר את מטרת הבדיקה. מתי לדעתך האפליקציה נבדקה מספיק?
מפתחים רבים רואים בהשגת כיסוי בדיקה גבוה את המטרה הסופית של הבדיקות. אבל האם זו תמיד הגישה הכי טובה? יכול להיות שיש עוד גורם קריטי שצריך להביא בחשבון כשמחליטים על אסטרטגיית בדיקה – מענה על צורכי המשתמשים.
כמפתחים, אתם משתמשים גם בהרבה אפליקציות ומכשירים אחרים. במובן הזה, אתם המשתמשים שמסתמכים על כך שכל המערכות האלה "פשוט יעבדו". בתורכם, אתם מסתמכים על אינספור מפתחים שיעשו כמיטב יכולתם כדי שהאפליקציות והמכשירים שלהם יעבדו. כמפתחים, אתם צריכים לשאוף להצדיק את האמון הזה. לכן, המטרה הראשונה שלכם צריכה להיות תמיד להשיק תוכנה שפועלת ולשרת את המשתמשים. זה כולל גם את הבדיקות שאתם כותבים כדי להבטיח את איכות האפליקציה. קנט ס. Dodds מסכם את זה היטב בפוסט שלו Static vs Unit vs Integration vs E2E Testing for Frontend Apps:
ככל שהבדיקות דומות יותר לאופן שבו משתמשים בתוכנה, כך הן יכולות לתת לכם יותר ביטחון.
מאת קנט ס. Dodds
קנט מתאר את זה כצבירת ביטחון בבדיקות. ככל שתבחרו סוג בדיקה שמתאים יותר למשתמשים, כך תוכלו להיות בטוחים יותר שהתוצאות של הבדיקות יהיו תקפות. במילים אחרות, ככל שמטפסים גבוה יותר בפירמידה, כך רמת הביטחון עולה. אבל רגע, מהי הפירמידה?
הגדרת אסטרטגיות בדיקה: איך בוחרים אסטרטגיית בדיקה
בשלב הראשון, צריך לקבוע אילו חלקים בדרישות צריך לבדוק כדי לוודא שהם מתקיימים. כאן תוכלו לגלות באילו סוגי בדיקות כדאי להשתמש ובאיזו רמת פירוט תוכלו להשיג את רמת הוודאות הגבוהה ביותר, תוך שמירה על מבנה עלויות יעיל. הרבה מפתחים משתמשים באנלוגיות כדי להסביר את הנושא הזה. אלה הסוגים הנפוצים ביותר, החל מהקלאסיקה המוכרת.
הקלאסי: פירמידת הבדיקות
ברגע שתתחילו לחפש אסטרטגיות בדיקה, סביר להניח שתיתקלו בפירמידת הבדיקות האוטומטיות כאנלוגיה הראשונה. מייק קוהן הציג את הקונספט הזה בספרו "Succeeding with Agile". בהמשך, מרטין פאולר הרחיב את הרעיון במאמר שלו Practical Test Pyramid. אפשר לייצג את הפירמידה באופן חזותי כך:
כמו שמוצג בתרשים, פירמידת הבדיקות מורכבת משלוש שכבות:
יחידה. הבדיקות האלה נמצאות בשכבת הבסיס של הפירמידה כי הן מהירות לביצוע ופשוטות לתחזוקה. הן מבודדות ומטרגטות את יחידות הבדיקה הקטנות ביותר. לדוגמה, ראו בדיקת יחידה אופיינית למוצר קטן מאוד.
שילוב. הבדיקות האלה נמצאות באמצע הפירמידה, כי מהירות הביצוע שלהן סבירה, אבל הן מקרבות אתכם למשתמש יותר מאשר בדיקות היחידה. דוגמה לבדיקת שילוב היא בדיקת API. אפשר לסווג גם בדיקות רכיבים כסוג כזה.
בדיקות מקצה לקצה (נקראות גם בדיקות ממשק משתמש). הבדיקות האלה מדמות משתמש אמיתי ואת האינטראקציה שלו. בדיקות כאלה דורשות יותר זמן לביצוע ולכן הן יקרות יותר. הם נמצאים בראש הפירמידה.
רמת מהימנות לעומת משאבים
כמו שציינו בקצרה קודם, סדר השכבות הוא לא מקרי. הם מציגים את סדרי העדיפויות ואת העלויות המתאימות. כך תוכלו לדעת כמה בדיקות צריך לכתוב לכל שכבה. כבר ראיתם את זה בהגדרה של סוגי הבדיקות.
בדיקות E2E הן הכי קרובות למשתמשים, ולכן הן נותנות את הביטחון הגבוה ביותר שהאפליקציה פועלת כמצופה. עם זאת, הן דורשות מחסנית אפליקציות מלאה ומשתמש מדומה, ולכן הן גם עלולות להיות היקרות ביותר. לכן, רמת הסמך מתחרה באופן ישיר במשאבים שנדרשים כדי להריץ את הבדיקות.
הפירמידה מנסה לפתור את הבעיה הזו בכך שהיא גורמת לכם להתמקד יותר בבדיקות יחידה ולתעדף באופן קפדני את המקרים שמכוסים על ידי בדיקות E2E. לדוגמה, התהליכים הכי חשובים שהמשתמשים עוברים או המקומות שבהם הכי סביר שיהיו תקלות. כפי שמרטין פאולר מדגיש, שתי הנקודות החשובות ביותר בפירמידה של קוהן הן:
- כותבים בדיקות ברמות פירוט שונות.
- ככל שהרמה גבוהה יותר, כך צריכות להיות פחות בדיקות.
הפירמידה התפתחה! התאמות של פירמידות הבדיקה
במשך כמה שנים, הדיונים התמקדו בפירמידה. נראה שהפירמידה מפשטת מדי את אסטרטגיות הבדיקה, משמיטה הרבה סוגי בדיקות וכבר לא מתאימה לכל הפרויקטים בעולם האמיתי. לכן, יכול להיות שהמידע מטעה. האם הפירמידה איבדה את הצורה שלה? ל-Guillermo Rauch יש דעה בנושא:
כותבים בדיקות. לא יותר מדי. בעיקר שילוב.
מאת Guillermo Rauch
זה אחד הציטוטים הכי נפוצים בנושא הזה, אז בואו ננתח אותו:
- "כתיבת בדיקות". לא רק כי זה בונה אמון, אלא גם כי זה חוסך זמן בתחזוקה.
- "לא יותר מדי". כיסוי של 100% הוא לא תמיד טוב, כי אז הבדיקות לא מתועדפות ויהיה צורך בהרבה תחזוקה.
- "בעיקר שילוב". גם כאן הדגש הוא על בדיקות אינטגרציה: הן מספקות את הערך העסקי הגבוה ביותר, כי הן נותנות לכם רמת סמך גבוהה מדי יום, תוך שמירה על זמן ביצוע סביר.
זה גורם לכם לחשוב שוב על פירמידת הבדיקות ולהעביר את המיקוד לבדיקות אינטגרציה. בשנים האחרונות הוצעו הרבה התאמות, אז בואו נסתכל על הנפוצות ביותר.
יהלום לבדיקה
ההתאמה הראשונה מסירה את הדגש המוגזם על בדיקות יחידה, כפי שמופיע בפירמידת הבדיקות. נניח שהגעתם ל-100% כיסוי בבדיקות יחידה. עם זאת, בפעם הבאה שתארגנו את הקוד מחדש, תצטרכו לעדכן הרבה מבדיקות היחידה האלה, ויכול להיות שתתפתו לדלג עליהן. לכן הם נשחקים.
כתוצאה מכך, ובשילוב עם ההתמקדות הגבוהה יותר בבדיקות אינטגרציה, יכולה להיווצר הצורה הבאה:
פירמידה שהופכת ליהלום. אפשר לראות את שלוש השכבות הקודמות, אבל בגודל שונה, ושכבת היחידה נחתכה:
- יחידה. כותבים בדיקות יחידה (unit testing) כמו שהגדרתם אותן קודם. עם זאת, מכיוון שהם נוטים להישחק, כדאי לתעדף ולכסות רק את המקרים הקריטיים ביותר.
- שילוב. בדיקות השילוב שאתם מכירים, שבודקות את השילוב של יחידות בודדות.
- E2E. השכבה הזו מטפלת בבדיקות של ממשק המשתמש, בדומה לפירמידת הבדיקות. חשוב לכתוב בדיקות E2E רק למקרי הבדיקה הכי קריטיים.
בדיקת חלת דבש
יש עוד גרסה, שהוצגה על ידי Spotify, שדומה למעוין הבדיקות אבל מותאמת יותר למערכות תוכנה שמבוססות על מיקרו-שירותים. חלת הדבש של הבדיקות היא עוד אנלוגיה חזותית לרמת הפירוט, להיקף ולמספר הבדיקות שצריך לכתוב למערכת תוכנה שמבוססת על מיקרו-שירותים. בגלל הגודל הקטן של המיקרו-שירותים, המורכבות הגדולה ביותר שלהם היא לא בשירות עצמו, אלא באינטראקציה שלו עם שירותים אחרים. לכן, אסטרטגיית בדיקה של מיקרו-שירות צריכה להתמקד בעיקר בבדיקות שילוב.
הצורה הזו מזכירה לנו חלת דבש, ומכאן השם. הוא כולל את השכבות הבאות:
- בדיקות משולבות. במאמר של Spotify יש ציטוט של ג'. ב. Rainsberger כדי להגדיר את השכבה הזו: "בדיקה שתעבור או תיכשל על סמך התקינות של מערכת אחרת". לבדיקות כאלה יש יחסי תלות חיצוניים שצריך להביא בחשבון, ולעומת זאת, המערכת שלכם עשויה להיות יחס תלות שמשבש מערכות אחרות. בדומה לבדיקות E2E בהקשרים אחרים, צריך להשתמש בבדיקות האלה בזהירות, רק במקרים החיוניים ביותר.
- בדיקות אינטגרציה. בדומה להתאמות אחרות, כדאי להתמקד בשכבה הזו. הוא מכיל בדיקות שמאמתות את תקינות השירות בצורה מבודדת יותר, אבל עדיין בשילוב עם שירותים אחרים. כלומר, הבדיקות יכללו גם מערכות אחרות ויתמקדו בנקודות האינטראקציה, למשל באמצעות בדיקות API.
- בדיקות של פרטי ההטמעה. הבדיקות האלה דומות לבדיקות יחידה (unit tests) – בדיקות שמתמקדות בחלקים של הקוד שמבודדים באופן טבעי, ולכן יש להם מורכבות פנימית משלהם.
כדי לקבל מידע נוסף על אסטרטגיית הבדיקה הזו, אפשר לעיין בפוסט שמשווה בין פירמידת הבדיקה לבין חלת הדבש מאת מרטין פאולר ובמאמר המקורי של Spotify.
גביע בדיקה
כבר אפשר לראות התמקדות חוזרת בבדיקות אינטגרציה. עם זאת, סוג אחר שנתקלתם בו במאמר הקודם הוא לא בדיקה בתיאוריה, אבל הוא עדיין היבט חשוב שכדאי להביא בחשבון באסטרטגיית הבדיקה. ניתוח סטטי לא מופיע בפירמידת הבדיקות וברוב ההתאמות שראיתם עד עכשיו. יש את ההתאמה של גביע הבדיקות שמביאה בחשבון ניתוח סטטי תוך שמירה על ההתמקדות בבדיקות אינטגרציה. גביע הבדיקות נוצר בהשראת הציטוט של גיירמו ראוך ופותח על ידי קנט סי. דודס:
גביע הבדיקות הוא אנלוגיה שמתארת את רמת הפירוט של הבדיקות בצורה קצת שונה. יש בו ארבע שכבות:
- ניתוח סטטי. הוא ממלא תפקיד חיוני באנלוגיה הזו ומאפשר לכם לזהות שגיאות הקלדה, שגיאות סגנון ובאגים אחרים, פשוט על ידי הפעלת שלבי ניפוי הבאגים שכבר תיארנו.
- בדיקות יחידה. הם מבטיחים שהיחידה הקטנה ביותר נבדקת כראוי, אבל גביע הבדיקה לא ידגיש אותם באותה מידה כמו פירמידת הבדיקה.
- שילוב. זהו המוקד העיקרי, כי הוא מאזן בין העלות לבין רמת הסמך הגבוהה יותר בצורה הטובה ביותר, כמו בהתאמות אחרות.
- בדיקות של ממשק המשתמש. כולל בדיקות E2E ובדיקות חזותיות, הן נמצאות בראש גביע הבדיקות, בדומה לתפקיד שלהן בפירמידת הבדיקות.
כדי לקרוא עוד על גביע הבדיקות, עיינו בפוסט בבלוג של קנט סי. Dodds בנושא הזה.
עוד כמה גישות שמתמקדות בממשק המשתמש
הכול טוב ויפה, אבל לא משנה איך תקראו לאסטרטגיה שלכם, "פירמידה", "חלת דבש" או "יהלום", עדיין חסר משהו. אוטומציה של בדיקות היא כלי חשוב, אבל חשוב לזכור שעדיין צריך לבצע בדיקות ידניות. בדיקות אוטומטיות אמורות להקל על משימות שגרתיות ולפנות את מהנדסי אבטחת האיכות להתמקד בתחומים חיוניים. במקום להחליף את הבדיקה הידנית, האוטומציה צריכה להשלים אותה. האם יש דרך לשלב בדיקות ידניות עם אוטומציה כדי לקבל תוצאות אופטימליות?
גביע גלידה לבדיקה וסרטן לבדיקה
יש שתי גרסאות של פירמידת הבדיקות שמתמקדות יותר בשיטות הבדיקה האלה, שמתמקדות בממשק המשתמש. לשתי השיטות יש יתרון של רמת סמך גבוהה, אבל באופן טבעי הן יקרות יותר כי ביצוע הבדיקה איטי יותר.
הראשון, חרוט הקרח לבדיקה, נראה כמו פירמידה הפוכה. בלי שלב הבדיקה הידנית, הוא נקרא גם "פיצת הבדיקה".
בגביע הגלידה, ההתמקדות העיקרית היא בבדיקות ידניות או בבדיקות של ממשק המשתמש, וההתמקדות המינימלית היא בבדיקות יחידה. הוא נוצר בדרך כלל בפרויקטים שבהם המפתחים התחילו לעבוד עם כמה רעיונות בלבד לגבי אסטרטגיית הבדיקה. הקוד הקפוא נחשב לתבנית אנטי-תבנית, ובצדק. הוא יקר מבחינת משאבים ועבודה ידנית.
סרטן הבדיקות דומה לחרוט הגלידה של הבדיקות, אבל הוא מתמקד יותר בבדיקות מקצה לקצה ובבדיקות חזותיות:
אסטרטגיית הבדיקה הזו כוללת היבט נוסף: היא מוודאת שהאפליקציה פועלת ונראית טוב. הסרטן שמבצע את הבדיקות מדגיש את החשיבות של בדיקות חזותיות, שמוגדרות במאמר הקודם. בדיקות אינטגרציה, שמחולקות לבדיקות רכיבים ובדיקות API, עוברות עוד יותר לרקע, ובדיקות יחידה ממלאות תפקיד עוד יותר משני כאן. פרטים נוספים על אסטרטגיית הבדיקה הזו זמינים במאמר הזה על בדיקת סרטנים.
למרות שהן יקרות יותר, שתי אסטרטגיות הבדיקה האלה מתאימות למקרים מסוימים: למשל, בפרויקטים קטנים יותר שבהם נדרשות פחות בדיקות, או שצריך לכסות פחות מורכבות. במקרה כזה, אסטרטגיית בדיקה מקיפה שמתמקדת בבדיקות שילוב עלולה להיות מורכבת מדי.
למרות ששתי אסטרטגיות הבדיקה האלה יקרות יותר, יש להן מקום, למשל בפרויקטים קטנים יותר שדורשים פחות בדיקות ולא צריכים לכסות הרבה מורכבות. במקרה כזה, אסטרטגיית בדיקה בקנה מידה מלא שמתמקדת בבדיקות שילוב עשויה להיות מורכבת שלא לצורך.
עצות מעשיות: בואו נתכנן אסטרטגיה!
עכשיו אתם מכירים את אסטרטגיות הבדיקה הנפוצות ביותר. התחלתם עם הקלאסיקה – פירמידת הבדיקות – והכרתם את הגרסאות הרבות שלה. עכשיו צריך לבדוק אותם ביחס למוצר שלכם ולהחליט איזה מהם הכי מתאים לפרויקט. התשובה לשאלה הזו מתחילה במשפט שכולם אוהבים: "זה תלוי". אבל זה לא הופך את התוצאות לפחות מדויקות.
הבחירה באסטרטגיית הבדיקה המתאימה ביותר מבין אלה שמתוארות – ואפילו אלה שלא נכללות – תלויה באפליקציה שלכם. הוא צריך להתאים לארכיטקטורה, לדרישות, וגם למשתמשים ולדרישות שלהם. כל זה עשוי להשתנות מאפליקציה לאפליקציה. זה נורמלי לחלוטין. חשוב לזכור שהמטרה הכי חשובה היא לשרת את המשתמשים, ולא לעמוד בהגדרה תיאורטית.
ברוב המקרים, קשה להפריד בין בדיקות בעולם האמיתי ולהגדיר אותן בנפרד. אפילו מרטין פאולר עצמו מדגיש את ההיבט החיובי של הגדרות שונות, כמו במקרה של בדיקות יחידה. כמו שג'סטין סירלס ציין בצדק בציוץ שלו:
[…] לכתוב בדיקות אקספרסיביות שקובעות גבולות ברורים, פועלות במהירות ובאמינות, ונכשלות רק מסיבות מועילות.
מאת ג'סטין סירלס
התמקדו בבדיקות שמדווחות על שגיאות אמיתיות שהמשתמשים עלולים להיתקל בהן, ואל תסיטו את תשומת הלב מהמטרה שלכם. הבדיקות צריכות להיות מתוכננות כך שיועילו למשתמש, ולא רק כדי לספק כיסוי של 100% או כדי להתווכח על אחוז הבדיקות שצריך לכתוב מכל סוג.
התמקדו בבדיקות שמדווחות על שגיאות אמיתיות שהמשתמשים עלולים להיתקל בהן, ואל תסיטו את תשומת הלב מהמטרה שלכם. הבדיקות צריכות להיות מתוכננות כך שיועילו למשתמש, ולא רק כדי לספק כיסוי של 100% או לעורר ויכוחים על אחוז הבדיקות מסוג מסוים שצריך לכתוב.