לחם מסתורי
המטרה של צוות QA היא לא בדיקות טובות.
זה גם לא לבדוק את הדברים הנכונים בדרך הנכונה.
המטרה האמיתית היא לעזור לצוותים לבנות תוכנה שעובדת. בדיקות הן כלי אחד להשגת המטרה הזו. זה לא הכלי היחיד. לעיתים קרובות זה גם לא הכלי הטוב ביותר.
חברות רבות מתמקדות רק בבדיקות ובכיסוי (coverage). זו טעות.
לבדיקות יש שימושים ספציפיים:
- בדיקות אוטומטיות מספקות משוב מהיר על פונקציות חשובות.
- בדיקות חקרניות (Exploratory testing) עוזרות לך להבין איך התוכנה מתנהגת.
עם זאת, צוותים רבים משתמשים בבדיקות כדי לתקן הכל. הם משתמשים בהן כדי למלא פערים שהותירה תכנון לקוי. הם משתמשים בהן כדי להחליף ניטור (monitoring) ותצפיתיות (observability).
להסתמך על כיסוי בדיקות (test coverage) כאות האיכות העיקרי שלך זה כמו לנסות לעצב לחם אחרי שהוא יצא מהתנור.
תחשבו על התוכנה שלכם כעל לחם. המרכיבים הם הדברים שאתם צריכים לפני שאתם כותבים קוד:
- הגדרה ברורה של מה התוכנה חייבת לעשות.
- הסכמה על איך נראית איכות.
- הבנה של סיכונים ומגבלות.
אם תשתמשו בקמח הלא נכון או תדלגו על המלח, שום עיצוב מחדש לא יתקן את הבצק.
קל לעצב תוכנה כשהיא עדיין בצק. הכוונה היא לשלב מוקדם בפיתוח. ברגע שהקוד נכתב, הבצק מתקשה. ביצוע שינויים אז עולה יותר זמן ומאמץ.
כיסוי בדיקות אומר לכם איפה הסתכלתם. הוא לא אומר לכם אם מה שהסתכלתם עליו חשוב. מספר כיסוי של 80% לא אומר שהתוכנה שלכם באיכות גבוהה. זה עשוי פשוט להעיד שיש לכם יותר מדי בדיקות חסרות תועלת.
תפסיקו לרדוף אחרי מספרי כיסוי. במקום זאת, שאלו את השאלות הבאות:
- איפה התנהגות התוכנה שלנו אינה ידועה?
- מהי הדרך המהירה ביותר לגלות זאת?
לפעמים התשובה היא בדיקה. לעיתים קרובות, התשובה היא שיחה. אתם צריכים לשאול את השאלות שכולם מניחים שהן מובנות מאליהן.
רוב התוכנות נשברות בסופו של דבר. כשזה קורה, אתם צריכים לדעת מהר. ניטור בסביבת הייצור (Production monitoring) אומר לכם שמשהו לא בסדר לפני המשתמשים שלכם. בדיקות לא יכולות לעשות זאת בצורה זולה.
הבינה המלאכותית (AI) הופכת את זה לקשה עוד יותר. כעת ניתן לייצר קוד