LOGIN
התחברות או הרשמה
Avatar
להמשך הרשמה ידנית – לחץ על כפתור ההרשמה, להרשמה/כניסה מהירה בעזרת חשבון רשת חברתית – לחץ על הלוגו בכותרת

אפס סיסמה - שכחתי את שם המשתמש

שם משתמש
סיסמה
זכור אותי

he icon   en icon

בכדי להוסיף פוסט בבלוג יש להרשם או להתחבר - ההרשמה/כניסה מתבצעת מכותרת האתר.

מיישמי אוטומציה – איזו מין חיה זו?

נכתב על ידי 
שישי, 02 מאי 2014 06:10
דרגו כתבה זו
(1 הצבעה)


לפני כמה חודשים קראתי את הפוסט הקצר הזה, גירדתי קצת בראשי, אמרתי לעצמי "טוב, אני לא מסכים עם זה אפילו קצת" והמשכתי הלאה בחיי.
מאז, כבר פעמיים או שלוש (שאני זוכר) שראיתי את קובי מקשר לפוסט הזה במסגרת דיונים. בכל פעם נזכרתי שוב שצריך לפתוח את הדיון סביב השאלה "מה היא אוטומציה ואיך צריך להתייחס אליה?". ואז הייתי עסוק ושכחתי.
בגדול, יש שלוש נקודות שמפריעות לי:
1) מה שעושה "מיישם אוטומציה" *אינו* אוטומציה, וכל דבר מעבר לטווח המיידי, גם אינו יעיל.
2) ההפרדה בין התפקידים מסרבלת את המערכת ומובילה לקוד פגום שאינו מותאם לצרכים.
3) הנקודה החשובה ביותר נשמטה ממנו – מי שמתעסק באוטומציה למוצרים הוא בראש ובראשונה בודק.

ועכשיו, עם טיפ-טיפה יותר פירוט.

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

יש היום בשוק לא מעט כלים שמתיימרים לספק לבודק חסר יכולת התכנות את היכולת לכתוב בדיקות אוטומטיות. חלקם בעלי מוניטין מפוקפק (מישהו אמר QTP?) חלקם ממש טובים במה שהם עושים (SoapUI, למשל, די מרשים) אבל לכל אלה בהם נתקלתי, יש חיסרון אחד מובנה – ההפרדה בין תשתית בדיקות לבין הגיון עסקי מובילה לכך שהמיישמים מוצאים את עצמם עם עשרות או מאות "תרחישים" שכל אחד מהם מורכב ממספר לא קטן של אבני בניין תלויות זו בזו. חלק גדול מדי מהכלים שראיתי לוקה ביכולת ניהול הזרם (תרגום עקום שלי לflow control) - הטובים שבהם ייתנו לבודק אפשרות לומר "אם הבדיקה עברה, לך לכאן, אם היא נפלה לך לשם", אבל אם אבן בניין יכולה להיכשל בכמה דרכים שונות (למשל, ניסיון כניסה למערכת יכול להיכשל עם שגיאה בגלל סיסמה שגוייה, עם הודעת שגיאה בגלל תקלת מערכת, או עם דף שפשוט לא זז) ואני לא נתקלתי ב"תשתית" שמאפשרת ירידה לרזולוציה שנדרשת לפעמים בניהול הזרם.

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

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

עד כאן לגבי הנקודה הראשונה. על למה מיישמי אוטומציה יתקשו מאוד לייצר משהו נורמלי. אבל, גם אם נתעלם מזה לרגע, ישנה בעיה חמורה יותר – ההפרדה מובילה למצב בו מי שכותב את התשתית לא צריך לבצע בדיקות בעצמו, לא משתמש בה ולא באמת יודע מה עושים איתה.
ומעשה שהיה כך היה – לפני בערך שנה נכנסנו למשימה בה יחס העבודה היה 3:1 בין הבודקים למפתחים (שלוש משימות בדיקה מול כל משימת פיתוח. משימה, לצורך העניין, היא משהו שאמור לקחת כיום עבודה לאדם אחד), בשל חופשות ושאר בלת"מים יחס האנשים היה 1:5 (בודק אחד, חמישה מפתחים) היה לנו ברור איפה נמצא צוואר הבקבוק הפעם. כדי להתגבר על זה, החלטנו להעביר למפתחים שתי משימות גדולות יחסית – הוספת היכולת של מערכת האוטומציה שלנו לייצר קבצי אקסל בצורה מסויימת, וייצור של קבצי XML. אפילו קיבלנו את מה שביקשנו – אלא מה? בשני המקרים, כדי שאוכל להשתמש במה שקיבלתי, הייתי צריך לבלות בין חצי יום ליומיים בעטיפה של הכלים שקיבלתי והתאמה שלהם לשימוש. זה עדיף על פני חמשת הימים שהיה לוקח לי לכתוב את הכל מאפס, אבל זה משהו שלא היה קורה אילו מישהו מהבודקים האחרים היה מייצר את הקוד הזה. זה קרה למרות שישבתי עם המפתחים והגדרנו יחד מה אני צריך ואיך אני רוצה שזה יתנהג. גם קיבלתי את מה שביקשתי.
מה לא קיבלתי? את מה שלא ידעתי לבקש מראש, או את מה שחשבתי שברור מאליו. שכחתי לבקש שאם ב90% מהמקרים רוב הפרמטרים קבועים אני לא רוצה להגדיר אותם מחדש עם כל אובייקט. ברור לי לגמרי שאם אני רוצה להכניס קבצים למערכת הבדיקות שלי לא מספיק לי לקבל .jar ואני רוצה את קבצי המקור כדי לשנות במידת הצורך. כל מיני דברים קטנים כאלה. חלק מהם אני מאמין שאפשר לפתור אם עובדים ככה לאורך זמן, חלק אחר יישאר, לדעתי, כל עוד יש פער בין כותב הכלי למשתמש.
עוד נקודה חשובה - במצב בו מישהו אחר כותב לי את התשתית, בקשות לשיפורי תשתית רלוונטיות רק במקרי קיצון, ולא תמיד אפשריות. למשל – העברנו את העבודה שלנו מול מסד הנתונים להיות מבוססת על מיפוי של כל הטבלאות לאובייקטים (Hibernate, אם להיות ספציפיים) – זה מצריך אותנו למפות כל טבלה, וחוסך לנו שכפול עצום של כתיבת אותו SQL כמעט. אם אני צריך לבדוק פעם שדה א' ובבדיקה אחרת שדה ב' לפי אותו where – אני מבקש את האובייקט ומתחקר אותו. לו כתבתי "תשתיות אוטומציה", המעבר הזה היה לא הגיוני. למה שאייצר תשעים אבני בניין, כשאני יכול לספק אחת שמקבלת מחרוזת SQL והוראות חיבור למסד הנתונים? פרוייקט הבדיקה שהיה מסתמך על התשתית שלי היה משכפל שאילתות וחורק בשיניו בכל פעם בה טבלה משתנה וצריך לעדכן את השאילתות עליה.

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

כל זה מוביל אותי לתהייה – את ההגיון שבשכירת בודקים ידניים ללא יכולת תכנות אני יכול להבין: השקעה באוטומציה דורשת לא מעט משאבים מהארגון, ולפעמים הגיוני להשקיע במקום אחר ולשמור את הבדיקות מסורבלות (וגם לשלם את הקנס שיבוא כשיחליטו להתחיל לבנות אוטומציה. את התועלת שבשכירת בודקים עם יכולות תכנות מלאות אני רואה בחיי היומיום, אבל מה ההיגיון בשכירת "מיישמי אוטומציה"? הכלים המסחריים בשוק מעודדים כתיבת בדיקות קשה מאוד לתחזוקה (וזה הגיוני, כי הכלים האלו כלליים מאוד), החזקת צוות פנימי שיפתח תשתיות אוטומציה ברמה שתאפשר לאלו שאינם מתכנתים לכתוב בדיקות חדשות דורשת את אותו סדר גודל של השקעה כמו שכירת מתכנתים לצוותי הבודקים מלכתחילה ומובילה לבדיקות מוגבלות יותר ומאורגנות פחות עם עלייה מהירה מאוד במחירי התחזוקה. למה שמישהו ירצה לשלם עבור דבר כזה?

שונה לאחרונה ב שבת, 03 מאי 2014 18:10

חובה להיות משתמש רשום במערכת בכדי להגיב - ההרשמה/כניסה בכותרת האתר

חדשות מעולם הבדיקות

  • Fifteen Free Tools to Help With Testing

    Fifteen Free Tools to Help With Testing There are a great many articles, blog posts, and presentations that discuss automation frameworks and strategies.  But even the most robust automation framework won't eliminate the need to do exploratory testing.  There will always be situations where we need to generate a large amount of text to test a text field or where we need to encode a string in HTML to test for cross-site scripting.  In this week's post, I share fifteen of my favorite free tools that make testing faster and easier.  Text Tools:1. Letter Count:  This tool will count the characters or words in a block of text.  I use it for creating strings with a specific character count when I test text fields.2. Lorem Ipsum Generator: I use this tool when I need to generate large amounts of text for text fields where a user will be able to enter several paragraphs of text.3. Convert Case: This tool comes in handy when I'm testing with Postman and my assertions are expecting the exact casing for string comparison.  Convert Case will set all the characters in a string to lower case, upper case, sentence case, alternating case, and more.JSON Tools:4. Pretty Print: JSON objects need indentation to be easily readable.  This tool will take care of all of the indentation and spacing for you.  This is especially helpful when you receive flattened JSON in a response and you want to be able to read through it.5. Online JSON Viewer: This tool will flatten your JSON for you by removing[…]

    15.12.2018 | 2:14 קרא עוד...
  • Hacking Password Reset Functionality

    Hacking Password Reset Functionality So I have recently returned from 3 months travelling around Colombia and Central America and I am ready to get back to work! One thing that stayed with me during my travels is the amount of time technology would generally appear in conversations from Bitcoin to GPS systems – this gave me further motivation to expand my career in this varied and extremely interesting field. I recently got an email from Pluralsight with an invitation to use the platform for their free weekend, so I thought it would be a good opportunity to take some security classes. Especially considering one of my 2019 goals is to complete the CEH qualification. The course I decided to do focused on web hacking password reset functionality. Please continue reading to learn more about the various ways password reset functionality is vulnerable to attacks. There are generally 3 different ways to reset user password on websites: Password reset links (by far the most common) Generating a new Password which is sent (in plaintext) to the users email Question and Answer style A typical password reset link could look like this: https://example.com/reset.php?token=12345ab6 or it could look like this, using two parameters -> user ID and token https://example.com/reset.php?userId=12345&token=12345ab6 The userId parameter is unnecessary in the second example, as each token should be unique to the user, making the userId parameter arbitrary. A vulnerability which can be easily fixed is that the link should only be valid for a certain amount of time (enough time for the[…]

    15.12.2018 | 1:20 קרא עוד...
  • I Represent the User! And We All Do

    As a tester, I try to represent the interests of users. Saying the user, in the singular, feels like a trap to me. There are usually lots of users, and they tend to have diverse and sometimes competing interests. I’d like to represent and highlight the interests of users that might have been forgotten or overlooked. There’s another trap, though. As Cem Kaner has pointed out, it’s worth remembering that practically everyone else on the team represents the interests of end users in some sense. “End users want this product in a timely way at a reasonable price, so let’s get things happening on schedule and on budget,” say the project managers. “End users like lots of features,” say the marketers. “End users want this specific feature right away,” say the sales people. “End users want this feature optimized like I’m making it now,” say the programmers. I’d be careful about claiming that I represent the end user—and especially insinuating that I’m the only one who does—when lots of other people can credibly make that claim. Meanwhile, I aspire to test and find problems that threaten the value of the product for anyone who matters. That includes anyone who might have an interest in the success of the product, like managers and developers, of course. It also includes anyone whose interests might have been forgotten or neglected. Technical support people, customer service representatives, and documentors spring to mind as examples. There are others. Can you think of them? People who[…]

    15.12.2018 | 11:33 קרא עוד...

טיפים

  • בודק - הבן את המודל והאתגרים העיסקיים
    בודק - הבן את המודל והאתגרים העיסקיים בודק - הבן את המודל והאתגרים העיסקיים המוצרים אותם אנו בודקים מיועדים (בין השאר) לקדם את מטרות הארגון בו אנו עובדים, ולנו מחוייבות לעזור בתהליך זה, שהרי לשם כך בעלי העסק מחזיקים בארגון ומעסיקים אותנו, לעיתים…
    קרא עוד...
  • טיפ - עבודת בודקים בצמד עם המפתח
    טיפ - עבודת בודקים בצמד עם המפתח  עבודת בודקים בצמד עם המפתח "עבודה בצמד עם המפתח" – לעבודה בצמדים יתרונות רבים אך לעיתים היא נזנחת בשל "העלות הכפולה". בשנים האחרונות עם עליית שיטות אג'יליות ו- Extreme Programming צורת עבודה זו יותר נפוצה. כששני…
    קרא עוד...
לרשימה המלאה >>