אוטומציה - תחליף לבדיקות ידניות [?]

קיימים מימושים שונים לאוטומציה וניתן להיעזר בה במגוון דרכים - לאו דווקא כתחליף לבדיקות הידניות.
בפוסט הזה נדבר כיצד יש לתכנן את האוטומציה ולשלב אותה בתוך צוות בדיקות ידני קיים או במקביל להקמת הצוות עוד בשלבי הקמת הפרוייקט.


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

כדי לתכנן נכון אוטומציה צריך לקחת בחשבון את החסרונות שלה והחיסרון המרכזי שלה הוא - זמן.
מצד שני, זו בדיוק החוזקה של בדיקות ידניות - תוך זמן קצר יחסית, ניתן להכשיר צוות בודקים שיתחיל לבדוק את המוצר ולדווח כבר מהיום הראשון.

לכן, עדיף שבזמן שצוות הבדיקות הידניות עושה את שלו, צוות האוטומציה יכין את הכלים כדי שבבוא הזמן הוא יוכל "להתניע" אותם ולהצטרף למאמץ הבדיקות - אם בהפעלת האוטומציה או בכתיבת כלים אוטומאטים לצוות הבדיקות הידני.

כעת, נדון באופציות הרלוונטיות לתכנון מטרות האוטומציה:

• אופציה ראשונה - כלי להכשרת Build
• אופציה שנייה - כלי לאיתור רגרסיות
• אופציה שלישית - כלי להפעלת בדיקות ידניות 
• אופציה רביעית - כלי לבדיקות בהיקפים גדולים

כלי להכשרת Build

ניתן לתכנן סט בדיקות שירוץ על כל Build שהפיתוח מוציא ויבצע בדיקות בסיסיות שיתנו דוח מצב לגבי יציבות הגירסה והאם היא עומדת בדרישות ה-ATP.

ניתן להתחיל בבדיקות בסיסיות שיוודאו שה-Build לא מת [DOA] ע"י קומפילציה, הרצה של ה-Binary ובדיקה שיש ריצה מוצלחת ושיש תנאים בסיסים שמוכיחים חיוניות, כמו למשל - פורטים פתוחים ב-Server, מענה של OK לשאילתה בסיסית וכדו'

עם הזמן, ניתן לתגבר את הבדיקות עד לרמה שהם יוכלו לבצע סט של בדיקות Sanity.

זה יסייע, מן הסתם לצמצם או להעלים לגמרי את תופעת ה"פינג פונג" הידוע בין צוות הפיתוח לצוות הבדיקות עקב גרסאות שבורות או לא מתפקדות.

כלי לאיתור רגרסיות

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

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

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

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

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

כלי להפעלת בדיקות ידניות

את האופציה הזו אני ממליץ לשקול בזהירות. אני הייתי ניגש לפיתוח אוטומציה לבדיקות ידניות רק לאחר שסיימתי או מיציתי את שאר האפשרויות.

כדי לתפעל בדיקות ידניות בצורה אוטומטית ואמינה, דרוש לרוב ציוד ייעודי שאמור לשלוט על פעולות פיזיות על המוצר כמו חיבור וניתוק של כבלים ו/או חשמל והאוטומציה תידרש לאבחן בין מצבי הצלחה וכישלון שאולי ברורים מאד לעין האנושית אבל קשים להבחנה עבור קוד - למשל, הבהובים על לוח אלקטרוני או חיווי מתוך GUI.

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

גם אם אין אפשרות או לא מעוניינים שהצוות הידני יעבוד במקביל - עדיין כדאי להתחיל עם בדיקות שיש להם reference ברור כדי שבמידה ותתעורר שאלה לגבי תוצאה של בדיקה, יהיה ניתן לוודא את תוצאת האמת בקלות.

עם הזמן, ניתן יהיה להסתמך על דוחות הבדיקות האוטומטיות ולצרף אותם לדוח הכללי.

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

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

כלי לבדיקות בהיקפים גדולים

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

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

בדיקות כאלה ישולבו לרוב בשלב מאוחר - רק אחרי שהמוצר כבר יציב ועבר כבר מספר סבבים שאישרו זאת.
מה שנותר הוא לוודא שהכל עובד באותה צורה מול תוכנות צד שלישי אחרות - כמו מערכות הפעלה למשל.

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


סיכום

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