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

בטח שמתם לב, שכמעט לא עובר חודש בלי וידאו הכרות עם “כלי אוטומציה חדש ומבטיח”. טרנד לוהט בתחום הבדיקות – כולם עוטפים את סלניום ו- Appium. הם עטופים יפה ללא ספק, מאפשרים הקלטות, יכולות קידוד בצורה פשוטה, נעימים לעין עם דו”חות במיליון חתכים שונים, וגם לא עושים חור בכיס. אז מה בעצם הבעיה שלי?

א. ה- product

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

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

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

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

ב. העטיפה

כשחברת מוצר בונה כלי אוטומציה, יש לה אחת משתי אפשרויות לתכנן את המימוש. או שהיא בונה כלי סביב רכיבים קיימים, לרוב open source, כמו רכיב unit test, לוגים, דו”חות, תזמון, התממשקות ל- CI וכו’, או שהיא בונה את הרכיבים הללו בעצמה.

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

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

ג. האלטרנטיבה

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

אז מה בעצם קורה פה?

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

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

Happy Testing