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

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

מה הקשר בין טמפונים לאלגוריתמים?

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

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

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

---

מה הם טסטים בפרודקשן?

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

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

• בדיקת קוד מול נתונים אמתיים.
• הרצת קוד חדש במקביל למהלכים קיימים ולוודא שהתוצאות המתקבלות זהות.
• שימוש ב- A/B testing על קבוצות משתמשים.
• ביצוע מעבר הדרגתי ומבוקר מקוד ישן לחדש.

למה כדאי לעשות בדיקות בסביבת פרודקשן?

לבדיקות בסביבת פרודקשן ישנם יתרונות גדולים על פני בדיקה לוקאלית בלבד: 

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

לבדיקות בסביבת פרודקשן ישנם גם חסרונות כמובן:

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

---

איך בונות סביבה תומכת לבדיקות בפרודקשן?

בואו נסתכל רגע על ה-lifecycle הקלאסי של פיתוח עם בדיקות לוקאליות.
בתהליך ה״רגיל״ יש לנו שלב אחד של בדיקות – אחרי הפיתוח, ולפני השחרור. התהליך הזה יהיה מאוד ארוך ויסודי כדי לוודא שהגרסה שמשתחררת לציבור תהיה כמה שיותר נקייה משגיאות.
חשוב לציין שאני לאו דווקא מתכוונת רק לפיתוח תוכנה עם שחרור גרסאות מאוד רחוקות זו מזו, גם מקומות שעובדים עם CI\CD יכולים להיות תקועים הרבה זמן בתהליך הפיתוח והבדיקות הפנימיות. 

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

חשוב לזכור שהשינוי כאן הוא לא של טכנולוגיה אלא של מתודולוגיה. 

הדרך שבה בדיקות בפרודקשן משתלבות בתהליך פיתוח בריא היא שילוב של מספר אלמנטים:

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

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

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

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

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

---

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

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