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

איתי ששון: המעבר מסטארט-אפ לחברה מסחרית מנקודת המבט של QA ואוטומציה

בפרק זה של פודקאסט TestIL, נתנאל הרוש מארח את איתי ששון לשיחה מרתקת על המעבר בין סטארט-אפ שנמצא בשלב הוכחת הרעיון לבין חברה שמתחילה למכור מוצר ללקוחות אמיתיים. איתי משתף מניסיונו לשעבר כ-automation teach lead בחברת CathWorks וכיום QA Lead בחברת UNIXi באתגרים של בניית תרבות Quality, תהליכי QA ותשתיות Automation בחברת Medical Device הנמצאת תחת רגולציה מחמירה.

סטארט-אפ רפואי שונה מסטארט-אפ "קלאסי"

בניגוד לחברות SaaS או Cyber שמחפשות מהר את הלקוח הראשון ואת ה-Proof of Concept, בעולם המכשור הרפואי הדרך ארוכה ומורכבת יותר. לפני שניתן למכור מוצר, יש צורך במחקרים קליניים, עבודה מול בתי חולים, הוכחת יעילות, קבלת אישורים רגולטוריים ואישור FDA. רק לאחר קבלת האישור מתחיל האתגר האמיתי – מעבר ממוצר שנועד להוכיח יכולת למוצר מסחרי שנדרש לשרת לקוחות באופן יציב ואמין.

ה-Shift הגדול: מהישרדות לאיכות

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

אחד המסרים המרכזיים בפרק הוא ש-Quality אינו אחריות של צוות QA בלבד. איכות מתחילה כבר בכתיבת User Stories, ממשיכה דרך Design, Code Review, Unit Tests, Automation, Release Management ומסתיימת רק אצל הלקוח.

מצב ה-QA כאשר איתי הצטרף לחברה

כאשר איתי הגיע לחברה, מצב האוטומציה היה רחוק מלהיות אידיאלי:

• כ-89 בדיקות אוטומטיות בלבד.
• רוב הבדיקות נכשלו באופן קבוע.
• ההרצות בוצעו מתוך סביבת הפיתוח.
• Regression בוצע אחת לשלושה חודשים באופן ידני על ידי כלל עובדי החברה.
• לא היה תהליך מסודר להכנסת קוד ל-Master.
• Product Managers ראו את התוצרים רק לאחר שכבר שולבו בגרסה הראשית.

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

QA כבעלים של איכות המוצר

איתי מאמין שאנשי QA חייבים להכיר את המערכת בצורה הרחבה ביותר בארגון. הם צריכים להבין את המוצר End-to-End, לזהות סיכונים, להשתתף ב-Backlog Refinement וב-Planning ולהעלות Riskים עוד לפני שהפיתוח מתחיל.

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

בניית אמון מחדש ב-Automation

אחד האתגרים הגדולים ביותר היה חוסר אמון מוחלט ב-Automation.

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

השלב הראשון היה להפוך את ה-Automation למוצר פנימי שאפשר לסמוך עליו:

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

בניית תשתיות DevOps ו-Quality Monitoring

בהמשך הוקמו תשתיות שאפשרו מעקב מלא אחר מצב האיכות:

• חיבור האוטומציה ל-Database.
• הצגת נתונים באמצעות Grafana.
• התקנת Jenkins Agents על שרתים ייעודיים.
• ניטור תוצאות ריצות לאורך זמן.
• מעקב אחר מגמות ויציבות המערכת.

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

הכנסת Gate לפני Merge

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

כדי שקוד יוכל להיכנס ל-Master נדרש:

• Build תקין.
• יצירת Installer בהצלחה.
• מעבר של Unit Tests.
• מעבר של בדיקות Automation קריטיות.
• עמידה בתהליך Code Review.

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

Definition of Done אמיתי

לאחר שהאוטומציה הוכיחה את עצמה, היא שולבה בתוך ה-Definition of Done הארגוני.

כל Feature חדש נדרש לכלול:

• בדיקות ידניות.
• בדיקות אוטומטיות.
• תיעוד רגולטורי.
• מעבר של כל ה-Gates.
• תהליך Code Review מלא.

בפועל, Feature שלא כלל Automation כאשר הדבר היה אפשרי – לא נחשב מוכן.

איך מודדים הצלחה של Automation?

איתי מדגיש ש-Code Coverage אינו המדד החשוב ביותר.

הצלחה של Automation נמדדת ביכולת:

• לזהות Regression במהירות.
• לקשר Bug לשינוי ספציפי.
• לספק Feedback מהיר למפתחים.
• לצמצם Context Switching.
• לקצר את זמן גילוי התקלות.

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

האם Automation מחליף Manual QA?

התשובה של איתי ברורה – לא.

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

למה לעבוד בסטארט-אפ?

לקראת סיום הפרק, איתי מסביר מדוע הוא מעדיף לעבוד בסטארט-אפים:

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

השורה התחתונה

הפרק ממחיש כיצד QA ו-Automation יכולים להיות גורם אסטרטגי בצמיחת החברה. באמצעות בניית תהליכי Quality נכונים, יצירת אמון באוטומציה, שילוב Gates בתהליך הפיתוח והטמעת תרבות של Ownership, ניתן להפוך מוצר שנמצא בשלב הוכחת הרעיון למוצר מסחרי איכותי, יציב ומוכן לשוק.

לקבוצת הוואצאפ של קהילת הבודקים: https://bit.ly/TestIL_Whatsapp

קישור לפרופיל לינקדאין של נתנאל: https://www.linkedin.com/in/netanel-harush/ 

קישור לפרופיל לינקדאין של איתי: https://www.linkedin.com/in/itay-sasson-793058b8/ 

אם גם אתם מעוניינים להשתתף בפודקאסטים, אנא צרו עימנו קשר במייל: [email protected]

קישור לערוץ הפודקאסט שלנו