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