תחום בדיקות התוכנה הוא סוג של עוף מוזר.
מצד אחד, תחום בדיקות תוכנה כדיסיפלינה דורש ורסטיליות, למידה עצמית והתחדשות תמידית. לא משהו שניתן ללמד באוניברסיטאות כתיאוריה או לעבד בתוך נוסחאות, חוץ אולי מלבד הבסיס.
מצד שני, יש הרבה מחזוריות, סיסטמתיות ומונוטוניות בפרקטיקה בתחום. ככל שתדייק ותחזור על אותם צעדים שביצעת בכל מחזור בדיקות - יקל עליך לפתוח באג ולשחזר את צעדיך.
יתירה מכך, בכל פעם שניסו להפוך את הדרך לשיטה כוללת, זה לא צלח - לפחות לא לכולם.
זה לא מנע מאנשים שונים לאורך השנים להתבונן על כל התחום תחת אותה מחיצה, בעיקר כדי לחזות להיכן הוא פונה.
בראיונות עבודה, אחת מהשאלות הקבועות שאני נוהג לשאול מרואיינים היא "איך אתה מתמודד עם המחזוריות והשחיקה של המקצוע?" בסופו של דבר, כל בודק יודע שעליו לחזור באופן סיזיפי על אותם טסטים בהתאם לנהלים כתובים ולפתוח את אותם באגים במצורה מכנית ויבשה.
אין מקום להרבה יצירתיות במקצוע הזה, זה ידוע. אבל עם זאת, לאורך השנים - התחום כולו לא יכול לעמוד במקום.
תחום בדיקות התוכנה קשור בחבל הטבור אל עולם פיתוח התוכנה ההולך ומתפתח בצעדי ענק והתקדמות מהירה של מוצרי התוכנה מכריחים את טובי הבודקים לאמץ את מוחם מחדש כדי לתכנן בדיקות או להחליט על סבבי בדיקות שיתאימו למוצר X ולמוצר Y באותה הצלחה.
ואז עולה השאלה הפשוטה לכאורה - "מהי הצלחה ?"
האם מוצר שיצא לשוק לאחר שעבר את סבבי הבדיקות אצל ה-QA ונתגלו בו באגים קריטים מעיד על כשלון מחלקת הבדיקות לעמוד ביעד שניתן להם ?
האם ניתן להגדיר בכלל כיעד "0 באגים" למוצר ?
כל מי שמנוסה בתחום יודע ששתי התשובות לשאלות אלה הן "לא" אדום בפונט 100 עם סימן קריאה.
מחלקת הבדיקות יכולה לעבוד קשה מאד במשך זמן ממושך על המוצר ועדיין להוציא דו"ח בדיקות שאינו מקיף את כל הבאגים ואולי אפילו לא את הרוב המוחלט של הבאגים.
תמיד ישנן פשרות, תמיד חסר זמן וכח האדם לא מספיק למשימה, תמיד יש טעויות שהבודקים עושים מתוך שעמום או עייפות.
אז קיימת גישה אחת שאומרת - תחום הבדיקות הידניות צריך לעבור מהעולם, הכל צריך לעבור אוטומציה - שם אגב, נדרשים להרבה יצירתיות ויש לא מעט אתגר אך מצד שני יש הרבה עבודה מול קוד או סקריפט והקשר אל עולם הבדיקות הולך ונחלש - ככל שההתמחות בקוד דורשת יותר תשומת לב מתכנון הבדיקות עצמן.
אריאל פייגון מספר באתר שלו Testing for Zero bugs איך ע"י Random Testing הם הצליחו בארגון שלו באמצעות מפתחים מוכשרים, תוך מספר חודשים לפתח אוטומציה שתריץ בדיקות אוטומאטיות רנדומליות שגילתה חצי מהבאגים שדווחו ע"י לקוחות תוך ריצת לילה אחת - מה שמחלקת הבדיקות הידניות שלהם לא הצליחה לעשות במשך שנים.
הטענה שהוא מציג באתר נכונה - אין שום דרך למחלקת הבדיקות הידניות לעלות על כל התרחישים והתזמונים הקיימים בשטח אצל הלקוחות. לא משנה כמה משאבים וכח אדם יושקעו בהם, הם תמיד יהוו סוג של "בדיקות מעבדה" ולעולם לא יהיה ניתן להשוות את הנעשה בהם לנעשה בשטח - מה שיגרום למציאות שבה הלקוחות מדווחים על כמות משמעותית של באגים שלא נמצאו ע"י מחלקת הבדיקות להמשיך ולהתקיים.
אז האם זה אומר שזה נכון עבור כל עולם הבדיקות ? האם כל הבודקים הידניים צריכים לעבור הסבה ?
כנראה שלא. כפי שציינתי מקודם - תחום הבדיקות הוא מגוון מדי מכדי שיהיה אפשר לשים אותו בהכללה או ליצור לו נוסחאות.
המוצר שעליו מדבר אריאל פייגון הוא קומפיילר - מוצר שקשה עד מאד אם לא בלתי אפשרי לבדוק ביעילות בצורה ידנית. כדי למצוא קוד שהקומפיילר נכשל לקמפל צריך להמציא כמות עצומה של קבצים ולבדוק אותם תחת הקומפיילר אחד אחד. זהו תחום שהבדיקות האוטומאטיות מצטיינות בו - כמובן שצריך לדעת איך לפתח את האוטומציה הזו - לשם כך נדרשים אנשי פיתוח מוכשרים לא פחות ואולי אף יותר מאנשי הפיתוח של המוצר עצמו, אך ברגע שהמטרה ברורה וברת תכנון - זה רק עניין של זמן ומשאבים מושקעים עד שמגיעים אליה לבסוף.
במציאות, רק חלק מהמוצרים יכולים להיות נבדקים ע"י אוטומציה טהורה מבלי שימוש בבדיקות ידניות בכלל. רק חלק מהמוצרים הם תוכנות טהורות שאינן מבוססות על אינטגרציה מול חומרה ושהפונקציונליות שלהן מסתכמת בקריאת קבצים.
גם מוצר תוכנתי טהור, ללא חומרה - מספיק שיש לו ממשק UI למשתמש כדי לגרום לתזמונים ותרחישים לא צפויים מצד המשתמש שיהיה בלתי אפשרי לשחזר בתנאי מעבדה גם לא באוטומציה.
זה לא אומר שאוטומציה לא תועיל במקרה הזה - זה רק אומר שיהיה בלתי אפשרי להגיע ל-0 באגים אפילו לא בקירוב - רק ע"י שימוש בטסטים רנדומליים.
זו אחת הסיבות שתחום הבדיקות הוא כל כך מעניין - קשה לבנות לו כללי אצבע ויש צורך ביצירתיות תמידית כדי לתפור לו פתרונות מתאימים לכל מוצר.
מצד אחד, תחום בדיקות תוכנה כדיסיפלינה דורש ורסטיליות, למידה עצמית והתחדשות תמידית. לא משהו שניתן ללמד באוניברסיטאות כתיאוריה או לעבד בתוך נוסחאות, חוץ אולי מלבד הבסיס.
מצד שני, יש הרבה מחזוריות, סיסטמתיות ומונוטוניות בפרקטיקה בתחום. ככל שתדייק ותחזור על אותם צעדים שביצעת בכל מחזור בדיקות - יקל עליך לפתוח באג ולשחזר את צעדיך.
זה לא מנע מאנשים שונים לאורך השנים להתבונן על כל התחום תחת אותה מחיצה, בעיקר כדי לחזות להיכן הוא פונה.
בראיונות עבודה, אחת מהשאלות הקבועות שאני נוהג לשאול מרואיינים היא "איך אתה מתמודד עם המחזוריות והשחיקה של המקצוע?" בסופו של דבר, כל בודק יודע שעליו לחזור באופן סיזיפי על אותם טסטים בהתאם לנהלים כתובים ולפתוח את אותם באגים במצורה מכנית ויבשה.
אין מקום להרבה יצירתיות במקצוע הזה, זה ידוע. אבל עם זאת, לאורך השנים - התחום כולו לא יכול לעמוד במקום.
ואז עולה השאלה הפשוטה לכאורה - "מהי הצלחה ?"
האם מוצר שיצא לשוק לאחר שעבר את סבבי הבדיקות אצל ה-QA ונתגלו בו באגים קריטים מעיד על כשלון מחלקת הבדיקות לעמוד ביעד שניתן להם ?
האם ניתן להגדיר בכלל כיעד "0 באגים" למוצר ?
כל מי שמנוסה בתחום יודע ששתי התשובות לשאלות אלה הן "לא" אדום בפונט 100 עם סימן קריאה.
מחלקת הבדיקות יכולה לעבוד קשה מאד במשך זמן ממושך על המוצר ועדיין להוציא דו"ח בדיקות שאינו מקיף את כל הבאגים ואולי אפילו לא את הרוב המוחלט של הבאגים.
תמיד ישנן פשרות, תמיד חסר זמן וכח האדם לא מספיק למשימה, תמיד יש טעויות שהבודקים עושים מתוך שעמום או עייפות.
אז קיימת גישה אחת שאומרת - תחום הבדיקות הידניות צריך לעבור מהעולם, הכל צריך לעבור אוטומציה - שם אגב, נדרשים להרבה יצירתיות ויש לא מעט אתגר אך מצד שני יש הרבה עבודה מול קוד או סקריפט והקשר אל עולם הבדיקות הולך ונחלש - ככל שההתמחות בקוד דורשת יותר תשומת לב מתכנון הבדיקות עצמן.
אריאל פייגון מספר באתר שלו Testing for Zero bugs איך ע"י Random Testing הם הצליחו בארגון שלו באמצעות מפתחים מוכשרים, תוך מספר חודשים לפתח אוטומציה שתריץ בדיקות אוטומאטיות רנדומליות שגילתה חצי מהבאגים שדווחו ע"י לקוחות תוך ריצת לילה אחת - מה שמחלקת הבדיקות הידניות שלהם לא הצליחה לעשות במשך שנים.
הטענה שהוא מציג באתר נכונה - אין שום דרך למחלקת הבדיקות הידניות לעלות על כל התרחישים והתזמונים הקיימים בשטח אצל הלקוחות. לא משנה כמה משאבים וכח אדם יושקעו בהם, הם תמיד יהוו סוג של "בדיקות מעבדה" ולעולם לא יהיה ניתן להשוות את הנעשה בהם לנעשה בשטח - מה שיגרום למציאות שבה הלקוחות מדווחים על כמות משמעותית של באגים שלא נמצאו ע"י מחלקת הבדיקות להמשיך ולהתקיים.
אז האם זה אומר שזה נכון עבור כל עולם הבדיקות ? האם כל הבודקים הידניים צריכים לעבור הסבה ?
כנראה שלא. כפי שציינתי מקודם - תחום הבדיקות הוא מגוון מדי מכדי שיהיה אפשר לשים אותו בהכללה או ליצור לו נוסחאות.
המוצר שעליו מדבר אריאל פייגון הוא קומפיילר - מוצר שקשה עד מאד אם לא בלתי אפשרי לבדוק ביעילות בצורה ידנית. כדי למצוא קוד שהקומפיילר נכשל לקמפל צריך להמציא כמות עצומה של קבצים ולבדוק אותם תחת הקומפיילר אחד אחד. זהו תחום שהבדיקות האוטומאטיות מצטיינות בו - כמובן שצריך לדעת איך לפתח את האוטומציה הזו - לשם כך נדרשים אנשי פיתוח מוכשרים לא פחות ואולי אף יותר מאנשי הפיתוח של המוצר עצמו, אך ברגע שהמטרה ברורה וברת תכנון - זה רק עניין של זמן ומשאבים מושקעים עד שמגיעים אליה לבסוף.
במציאות, רק חלק מהמוצרים יכולים להיות נבדקים ע"י אוטומציה טהורה מבלי שימוש בבדיקות ידניות בכלל. רק חלק מהמוצרים הם תוכנות טהורות שאינן מבוססות על אינטגרציה מול חומרה ושהפונקציונליות שלהן מסתכמת בקריאת קבצים.
גם מוצר תוכנתי טהור, ללא חומרה - מספיק שיש לו ממשק UI למשתמש כדי לגרום לתזמונים ותרחישים לא צפויים מצד המשתמש שיהיה בלתי אפשרי לשחזר בתנאי מעבדה גם לא באוטומציה.
זה לא אומר שאוטומציה לא תועיל במקרה הזה - זה רק אומר שיהיה בלתי אפשרי להגיע ל-0 באגים אפילו לא בקירוב - רק ע"י שימוש בטסטים רנדומליים.
גישה נוספת מרחיקת לכת הועברה בהרצאה בכנס אוטומציה של גוגל בה הוכרז כביכול על "מות תחום הבדיקות" והומלץ לכלל הבודקים לעבור הסבה או שדרוג משמעותי. הסיבה - הזמן המבוזבז על בדיקות מעכב את החברה לצאת עם מוצרים מהירים וגדולים יותר מה שעלול לגרום למתחרים להשיג את החברה שתשקיע בבדיקות. "מה עדיף ?" הוא שואל "מוצר יציב מאד או מוצר סביר עם מיליון משתמשים?"
זאת כמובן הכללה גסה. בבלוגים שביקרו את הגישה שהוצגה בהרצאה דובר על כך שזה יכול להיות נכון לחברות סטארטאפ בתנופה שמנסה לבסס את השם והבאזז שלה בשוק רווי תחרות. ברגע שיש לחברה מוניטין, קהל לקוחות קבוע והיא הופכת להיות גדולה - הלקוחות כבר לא יהיו סלחנים כבעבר לבאגים שיופיעו במוצרים שלה ויפסיק לרכוש את מוצריה.
זאת מבלי להזכיר חברות שמייצרות מוצרים רפואיים או מוצרי לחימה שעלות הנזק על באג קריטי הוא עצום ויכול לגרום לקריסתה של החברה.אם כן - אז מה המסקנה ?
תחום הבדיקות הוא חדש יחסית, לפחות ביחס לתחום פיתוח התוכנה והוא ורסטילי ותלוי במבנה המוצרים בהם הוא עוסק. יהיה קשה מאד להסיק מסקנות גורפות ולהכניס את התחום כולו אל תוך מסגרת אחת שתתוה את הכללים לבדיקה עבור מוצר כמו מערכת מידע יחד עם מוצרים תקשורתיים מודולריים ומורכבים שלא לדבר על מוצרים מתחום התעופה, הרפואה והלחימה.זו אחת הסיבות שתחום הבדיקות הוא כל כך מעניין - קשה לבנות לו כללי אצבע ויש צורך ביצירתיות תמידית כדי לתפור לו פתרונות מתאימים לכל מוצר.
אין תגובות:
הוסף רשומת תגובה