למה רוב פרויקטי האוטומציה נכשלים?

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

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

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

אז מה גורם לכישלון?

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

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

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

אז מה עושים?

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

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

מתבלטים אם להשתמש באוטומציה? אנחנו פה לתת יעוץ.

בודק תוכנה? תלמיד? רוצה להיכנס לתחום בדיקות התוכנה, כנס לקורס הדיגיטלי שלנו. (בדיקות ידניות)