למה לאנשי QA צריך להיות אכפת מ- DevOps

ישנם מספר יתרונות למהנדסי QA שעובדים במקום שמיישם DevOps.

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

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

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

אחריות משותפת

ב-DevOps כל חברי הצוות חולקים את האחריות על שיפור האבטחה, התאימות (compliance) והאיכות של התוכנה. אחריות משותפת זו מקטינה את החיכוכים בין המפתחים והבודקים ועוזרת לכולם להשלים מהר יותר את המשימות, לתקן מהר את הבאגים, ובכלל – לעבוד ביחד. ב-DevOps, כולם – מהנדסי בדיקות, מפתחים, מהנדסי deployment – יכולים להוסיף בדיקות חדשות (test cases) לתוכנית ה-QA.

Upstream Automation

מתכננים, מפתחים ומהנדסי בנייה, הם כולם בעלי ידע רב ומוכשרים, אבל לפעמים שגיאות קורות בגלל בעייה "בין מקלדת לכיסא" ("PEBKAC – "problem exists between keyboard and chair) . ההתמקדות של DevOps באוטומצייה של אישורים, commit-ים ו-build-ים משמעותה פחות אפשרויות לשגיאות של משתמשים – אפילו בשלבים ש-QA אינו בודק באופן פעיל. 

השילוב של צוותים רב-תחומיים ושל Upstream Automation גורמות לגילוי מוקדם של בעיות (MTTD – Mean Time to Detection). השגיאות נלכדות מוקדם יותר בתהליך הפיתוח לפני שהן הופכות לבעיות למשתמשי קצה.

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

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

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

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

כיסויי בדיקות (Test Coverage)

ככל שאינטגרציה של קטעי תוכנה והארכיטקטורה נעשים מורכבים יותר, כך הופך תפקיד ה-QA לקריטי יותר. דאגו לאיכות גבוהה של בדיקות ולכך שאתם בודקים מספיק את הקוד היישומי, התכונות והדרישות, וזאת ע"י מדידת כיסוי בדיקות כללי (overall test coverage) וכיסוי בדיקות אוטומטיות (automated test coverage).

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

כלי בדיקה עבור DevOps

היעזרו בכלים כמו GitLab, GitHub, Jira וכו' לבניית בדיקות אוטומטיות  ולניראות (visibility) של כיסוי הבדיקות.