אוטומציה היא מושג רחב. אולי אפילו רחב מדי. רבים מתייחסים למושג הזה מטאפורית, ללא הגדרה ברורה למה הם מתכוונים כשהם מדברים על אוטומציה. ראיתי את זה קורה מספר פעמים בארגונים שעבדתי בהם.
מעתה ואילך נתמקד בנושא האוטומציה וננסה לזרוע קצת סדר בבלגן. נדבר על בדיקות המתייחסות לקוד, לבדיקות מוקדמות ולבדיקות End 2 End או בשמם האחר System Tests.
בפוסט הזה אנסה לפזר מעט את הערפל ולהגדיר מעט את המושג, לפחות בראייתי.
ניתן לומר הרבה דברים על אוטומציה:
היא מבוקשת מאד, כולם אוהבים לדבר עליה ובמיוחד מנהלים שאוהבים לנפנף בכיסויי אוטומציה גבוהים בארגון שלהם.
היא נחשבת כמי ש"עושה לך את העבודה" בעודך ישן, משתזף בים או שותה קפה.
היא מפחידה בודקים ידניים לא מנוסים כמי שתחליף אותם ביום מן הימים ותגרום לפיטוריהם, אם לא להיותם מובטלים.
אבל, כשמסיימים עם סיפורי הגבורה והסופרלטיבים - לרוב נשארים הרבה סימני שאלה באוויר.
סימני שאלה בעיקר עבור אלה שקיבלו את הכבוד לנהל את האוטומציה או ליישם אותה בפועל.
עם הזמן, סימני השאלה מתחלפים להם בתסכול גדול, אם של המנהלים או של העובדים.
כפי שכתבתי בפתיח - אוטומציה באופן כללי, היא מושג רחב. רחב מדי מכדי שניתן לדבר עליו בצורה פרקטית ופרגמטית.
כדי לפרוט את הבעיה לפרוטות, מומלץ להבין קודם מה המטרות בשימוש באוטומציה, לפני שרצים ליישם אותה ואת זה נעשה בפוסטים הבאים.
לפני כן, כדאי שנציג גם את החסרונות של האוטומציה והם לא מעטים:
היא דורשת זמן רב והשקעה מרובה בעיקר בשלבי ההקמה שלה.
גם כשהיא כבר עובדת, היא לרוב "נשברת" בקלות ודורשת תחזוקה קבועה לאורך זמן.
כאשר אלה שהקימו אותה עוזבים, או עוברים תפקיד, קורה שנשארים עם שבר כלי ולא עם משהו שימושי שאפשר להמשיך לעבוד איתו.
בנוסף לכך, יש נטייה "לקדם" אנשי בדיקות וותיקים מהתחום הידני לאוטומטי כדי למנוע שחיקה וגם אולי מתוך אמונת-שווא שהניסיון שלהם עם המוצר יסייע בפיתוח האוטומציה.
אז צר לי לנפץ משאלות לב, אבל תחום האוטומציה אינו קשור לפחות לא כמו שחושבים לתחום הבדיקות הידניות.
הקשר המשותף הוודאי לשניהם הוא ששניהם עוסקים בבדיקות.
זה לא אומר, כמובן, שאנשי בדיקות ידניות לא יכולים להיות אנשי בדיקות אוטומציה, אך לא מדובר ב"קידום" טבעי ועליהם יהיה ללמוד הרבה על התחום בכלל ועל תחום התוכנה בפרט, כמעט באותה מידה בה היו נדרשים עבור משרת תוכנה.
איש אוטומציה מוצלח עשוי להיות מתכנת טוב, יותר מאשר בודק טוב.
גם אם הוא אינו בודק טוב במיוחד, הוא תמיד יכול לבקש ולקבל מאנשי הבדיקות הידניות אפיונים שיעזרו לו לפתח.
בעיני, אוטומציה היא נושא שדורש צוות מתכנתים במשרה מלאה שיפתח פתרונות עבור הבודקים או במקביל אליהם.
לצורך כך יש לגייס אנשים מוכשרים עם ניסיון בתחום התוכנה בהתמקדות בכלי בדיקה.
כל ניסיון של המנהלים "לסחוט" עד תום את התקנים שלהם ולנסות לתת לאנשי הבדיקות הידניים למנף את הנושא סופו שיעלה בתוהו ויגרום ליוזמה להיכשל בתירוץ הכללי "ניסינו, זה לא עבד".
מצד שני, זה לא קל למנהלים לאשר תקציב מוגבל עבור עובד שישב ויתכנת כל היום, במיוחד כאשר עמיתיו בתחום הבדיקות כורעים תחת נטל הבדיקות.
אני מניח שהם גם יודעים ש"לשלוף" איש אוטומציה לבדיקות ידניות, לא יהיה רעיון טוב.
בנוסף, תמיד קיים החשש שאיש האוטומציה ישב לו חודשים, נאבק לו ב-POC, מבלי להציג פתרון ראוי שניתן להראות להנהלה הבכירה, כדי להסביר את העלויות הנדרשות.
קשה לי לענות על זה, בעיקר מכיון שאני לא מכיר את המוצר - עליו נשאלת השאלה. אני כן יכול לתת טיפים כלליים מניסיוני ולנסות לתת מספיק חומר למחשבה כדי שאתם תוכלו לדעת את התשובה ובכך נעסוק בפוסטים הבאים.
לסיום הפוסט, אני רוצה לסכם כמה רעיונות גרועים שיש סיכוי גבוה שיגרמו לפרויקט האוטומציה להיכשל:
מעתה ואילך נתמקד בנושא האוטומציה וננסה לזרוע קצת סדר בבלגן. נדבר על בדיקות המתייחסות לקוד, לבדיקות מוקדמות ולבדיקות End 2 End או בשמם האחר System Tests.
בפוסט הזה אנסה לפזר מעט את הערפל ולהגדיר מעט את המושג, לפחות בראייתי.
ניתן לומר הרבה דברים על אוטומציה:
 |
היא מבוקשת מאד, כולם אוהבים לדבר עליה ובמיוחד מנהלים שאוהבים לנפנף בכיסויי אוטומציה גבוהים בארגון שלהם.
היא נחשבת כמי ש"עושה לך את העבודה" בעודך ישן, משתזף בים או שותה קפה.
היא מפחידה בודקים ידניים לא מנוסים כמי שתחליף אותם ביום מן הימים ותגרום לפיטוריהם, אם לא להיותם מובטלים.
אבל, כשמסיימים עם סיפורי הגבורה והסופרלטיבים - לרוב נשארים הרבה סימני שאלה באוויר.
סימני שאלה בעיקר עבור אלה שקיבלו את הכבוד לנהל את האוטומציה או ליישם אותה בפועל.
עם הזמן, סימני השאלה מתחלפים להם בתסכול גדול, אם של המנהלים או של העובדים.
אז מה נכון ?
כפי שכתבתי בפתיח - אוטומציה באופן כללי, היא מושג רחב. רחב מדי מכדי שניתן לדבר עליו בצורה פרקטית ופרגמטית.
כדי לפרוט את הבעיה לפרוטות, מומלץ להבין קודם מה המטרות בשימוש באוטומציה, לפני שרצים ליישם אותה ואת זה נעשה בפוסטים הבאים.
לפני כן, כדאי שנציג גם את החסרונות של האוטומציה והם לא מעטים:
היא דורשת זמן רב והשקעה מרובה בעיקר בשלבי ההקמה שלה.
גם כשהיא כבר עובדת, היא לרוב "נשברת" בקלות ודורשת תחזוקה קבועה לאורך זמן.
כאשר אלה שהקימו אותה עוזבים, או עוברים תפקיד, קורה שנשארים עם שבר כלי ולא עם משהו שימושי שאפשר להמשיך לעבוד איתו.
בנוסף לכך, יש נטייה "לקדם" אנשי בדיקות וותיקים מהתחום הידני לאוטומטי כדי למנוע שחיקה וגם אולי מתוך אמונת-שווא שהניסיון שלהם עם המוצר יסייע בפיתוח האוטומציה.
אז צר לי לנפץ משאלות לב, אבל תחום האוטומציה אינו קשור לפחות לא כמו שחושבים לתחום הבדיקות הידניות.
הקשר המשותף הוודאי לשניהם הוא ששניהם עוסקים בבדיקות.
זה לא אומר, כמובן, שאנשי בדיקות ידניות לא יכולים להיות אנשי בדיקות אוטומציה, אך לא מדובר ב"קידום" טבעי ועליהם יהיה ללמוד הרבה על התחום בכלל ועל תחום התוכנה בפרט, כמעט באותה מידה בה היו נדרשים עבור משרת תוכנה.
 |
איש אוטומציה מוצלח עשוי להיות מתכנת טוב, יותר מאשר בודק טוב.
גם אם הוא אינו בודק טוב במיוחד, הוא תמיד יכול לבקש ולקבל מאנשי הבדיקות הידניות אפיונים שיעזרו לו לפתח.
בעיני, אוטומציה היא נושא שדורש צוות מתכנתים במשרה מלאה שיפתח פתרונות עבור הבודקים או במקביל אליהם.
לצורך כך יש לגייס אנשים מוכשרים עם ניסיון בתחום התוכנה בהתמקדות בכלי בדיקה.
כל ניסיון של המנהלים "לסחוט" עד תום את התקנים שלהם ולנסות לתת לאנשי הבדיקות הידניים למנף את הנושא סופו שיעלה בתוהו ויגרום ליוזמה להיכשל בתירוץ הכללי "ניסינו, זה לא עבד".
מצד שני, זה לא קל למנהלים לאשר תקציב מוגבל עבור עובד שישב ויתכנת כל היום, במיוחד כאשר עמיתיו בתחום הבדיקות כורעים תחת נטל הבדיקות.
אני מניח שהם גם יודעים ש"לשלוף" איש אוטומציה לבדיקות ידניות, לא יהיה רעיון טוב.
בנוסף, תמיד קיים החשש שאיש האוטומציה ישב לו חודשים, נאבק לו ב-POC, מבלי להציג פתרון ראוי שניתן להראות להנהלה הבכירה, כדי להסביר את העלויות הנדרשות.
אז איך עושים את זה טוב ?
לסיום הפוסט, אני רוצה לסכם כמה רעיונות גרועים שיש סיכוי גבוה שיגרמו לפרויקט האוטומציה להיכשל:
- לגייס איש אוטומציה חסר ניסיון. זה מפתה, בגלל עלויות השכר הנמוכות, אך קיים סיכון גבוה שהוא יבזבז את זמנו ב"ללמוד" את הנושא ולנדוד בין פתרון כושל אחד למשנהו.
- להשתמש בכל התקנים הפנויים לגיוס אנשי אוטומציה. אוטומציה הוא משהו המתפתח לאט ולא בלי טעויות. עדיף לתת למעט אנשים או לאחד לעבור את התהליך הלימודי ורק כשתכנית האוטומציה מלאה, לגייס את השאר.
- לשאוף ל-100 אחוז אוטומציה. יש מעט מוצרים שיכולים להיבדק באוטומציה מלאה אבל גם הם זקוקים מדי פעם לידיים ועיניים אנושיות כדי לקבל סטטוס.
80 אחוז לדעתי הם מטרה ריאלית יותר לרוב המוצרים. עבור חלקם גם זה יהיה גבוה מדי ולא ריאלי.
- להשקיע כסף רב ברכישת כלים אוטומאטים. אוטומציה היא משהו שדורש התאמה למוצר. גם אם השקעתם בפתרונות-מדף יקרים, כדאי לדעת שרוב העבודה הנדרשת היא דווקא בפיתוח כלים In House ובהתאמת הכלים שנרכשו למוצר החברה.
- לגייס איש אוטומציה ולשים אותו בצוות בדיקות ידני, כי זה נח ניהולית. איש אוטומציה צריך לקבל יעדים וביקורת בשונה מאנשי בדיקות ידניים. מנהל של בודקים ידנים סביר שיתקשה לקבל החלטות נכונות עבור איש אוטומציה, מה שעלול להוביל לזמן מבוזבז ויעלה את סיכון הפרוייקט.
עדיף, בתור התחלה לשים את איש האוטומציה תחת ניהול צוות זמני של מנהל פיתוח שהניסיון והכלים שלו יהיו דומים יותר למה שנדרש מניהול פרוייקט אוטומציה. עם הזמן, איש האוטומציה יוכל לגייס אנשים נוספים או שהארגון יחליט לגייס ר"צ אוטומציה מבחוץ.
אין תגובות:
הוסף רשומת תגובה