בדיקות לתשתית האוטומציה שלנו | למה?


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

בין השאלות היו, "מי כאן כותב אוטומציה?" (כמעט כל הקהל הרים את ידו)
"מי כאן מגדיר את עצמו כמפתח?" (ידיים בודדות)
והשאלה האחרונה הייתה - "מי כאן כותב בדיקות לתשתיות האוטומציה שלו?"

הייתה דממה בקהל. מתוך כ-60 אנשים אף לא יד אחת.

הנתון הזה לא הפתיע אותי במיוחד, שהרי זהו לא דבר טריוויאלי (לפחות לא כרגע).


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

3 סיבות עיקריות לכתוב בדיקות לאוטומציה שלנו?

סיבה ראשונה - אנחנו מפתחים!

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

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

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

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

נצטרך לדעת לכתוב קוד יותר טוב, להכיר design patterns, לעבוד אל מול source control, לעשות אחד לשני code review, לנהל את פרויקט האוטומציה שלנו ב Jira והכי חשוב, המוצר שלנו - כמו המוצר של ה-R&D יצטרך להבדק.

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

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

תוצאת תמונה עבור ‪developers gif‬‏


סיבה שנייה - אסור לסנדלר ללכת יחף!

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

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

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

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

תוצאת תמונה עבור ‪not sure if wrote good code or shitty unit tests‬‏

סיבה שלישית - אוטומציה לא איכותית == מוצר לא איכותי!

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

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

תשתית אוטומציה היא קוד, בקוד בדרך כלל יש באגים (גם בקוד שאנשים מאוד מוכשרים כתבו).

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

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

סיכום

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

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

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

נתראה בפוסט הבא :)



תגובות

הוסף רשומת תגובה

פוסטים פופולריים מהבלוג הזה

תכנות מונחה עצמים | Dependency Inversion Principle

מהם קבצי DLL ואיך להשתמש בהם?

מה ההבדל בין אוטומציה לפיתוח רגיל