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

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

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

he icon   en icon

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

האם כדאי להיות סקרן? חוויותיו של בודק מתחיל

נכתב על ידי 
ראשון, 22 נובמבר 2015 18:28
דרגו כתבה זו
(2 הצבעות)

"חיפוש כשלים במערכת דורש סקרנות.." (סילבוס ISTQB פרק "הפסיכולוגיה של בדיקות")

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

לקרוא ולהבין זה לא מספיק, צריך גם ליישם. התרגיל הכיתתי היה לבדוק אפליקציה שמחברת אנשים ברחבי העולם. כל התלמידים בדקו בדיקות פונקציונליות, ואני החלטתי לבדוק משהו יותר מעניין. השתמשתי בדף של אליזבט הנדריקסון, Cheatsheet, והתחלתי לבדוק את מנוע החיפוש של האפליקציה, מנוע שעוזר למצוא מקומות ברחבי העולם אשר בהם אתה מעוניין להזמין מישהו או להיות מוזמן. כדי למצוא מקום יש להקיש אות או אותיות, והמנוע משלים שמות מקומות לפי האותיות שהיקשת. בדף של הגב' הנדריקסון יש סעיף שנקרא "Data Type Attack". הכנסתי סימנים מסוגים שונים למנוע החיפוש, ביצעתי "העתק-הדבק" מקבצי PDF למנוע החיפוש, מחקתי אותיות מהשמות שמנוע החיפוש נתן לי, וקיבלתי תוצאות מוזרות: שמות של מקומות עם מספרים, הזמנה לארח אנשים בשום מקום וכדומה.

לאחר בדיקה של כשעתיים, החיבור לאינטרנט נותק באופן פתאומי. לאחר שחזר, התברר שהחלק של מנוע החיפוש אשר אותו בדקתי (מקומות שמתחילים באות a) כמעט לא מתפקד.

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

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

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

בשלב הבא, הסקרנות הובילה אותי לחפש בספרה של הגברת הנדריקסון: Explore It בנושא Exploratory Testing. שם נתקלתי במשפט שאומר שמשתמשים בתוכנה עושים את הדברים המשוגעים ביותר. וכבר קיבלתי קצת הצדקה לבצע פעולות משוגעות במערכת שאני בודק אותה. אם המשתמשים הפוטנציאליים עלולים לבצע פעולות מוזרות, עדיף שאני אהיה שם קודם...

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

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

הבנתי שבגישה של הגברת הנדריקסון לבדיקות חוקרות (ET) טמון דבר חדשני. משמעות הדבר היא שאכן לא ניתן לתכנן ולהגדיר תוכנה בשלמות כל זמן שהתוכנה לא מגיעה לעולם הממשי! משמעות הדבר לגבי הבודקים היא שהם המבצעים את שלב ב' של הגדרת התוכנה ופיתוחה.

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

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

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

ועוד תזכורת: אשמח לכל הצעת עבודה, רצוי בירושלים.

בברכה,

אברהם שנקר

This e-mail address is being protected from spambots. You need JavaScript enabled to view it.

טל: 0527610919

382 junge01

שונה לאחרונה ב רביעי, 25 נובמבר 2015 06:32

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

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

  • Day 6: Read and share an interesting blog post on API testing.

    Day 6: Read and share an interesting blog post on API testing. Yet Another Challenge! Ministry of Testing got us 30 days Testing Challenge.This time topic is on API Testing.Challenge Link:  https://www.ministryoftesting.com/dojo/lessons/30-days-of-api-testing  It has been long time I have worked on API Testing, after learning from API Testing Dojo (year 2015).Sixth Challenge is Read and share an interesting blog post on API testing.          Sharing will enrich everyone with more knowledge.I will actually share couple of posts which help in learning. a. Danny Dainton's GitHub Post on All Things Postman - https://github.com/DannyDainton/All-Things-Postmanb. Recent blogpost by Anne-Marie Charrett - https://mavericktester.com/2018/11/05/rest-apis-written-by-women/This blogpost includes collation of posts written female software craftspeople.Please do check out them, there are plenty of interesting blogposts.Ministry of Testing Discussion Thread:  https://club.ministryoftesting.com/t/30-days-of-api-testing-day-6-interesting-blog-post-on-api-testing/19595/18

    14.11.2018 | 11:23 קרא עוד...
  • 30 Days of API Testing – Mock, Stub, Fake

    Today’s challenge is about explaining mocks, stubs and fakes. I don’t know if I can pull it off. The problem is, different teams will use these words in different ways. I don’t think it makes a lot of sense to argue about what exactly each of them means and how they are distinct from each other, but there is some value in at least understanding the general idea that these terms are meant to communicate. In the broadest terms, when we talk about these things we are talking about something that is a substitute for a piece of production code. For example, we might have a database that stores some values. When running tests though, it might expensive to go retrieve those values many times, so instead we might make a local text file that has a few of the values we care about hard coded into it and just use that instead of the ‘real’ databases. No matter what term we are talking about – mocking, stubbing, faking, etc. – what we are doing is using something that is not the production code to simplify in some way what we are doing for our tests.  This helps us isolate things to just the specific part of the code we are interested in and can be used in some really powerful ways. I wouldn’t worry too much about understanding in an absolute sense what these various terms means. What matters in figuring out what they mean in your context. How[…]

    14.11.2018 | 9:48 קרא עוד...
  • Quality is the Responsibility of the Whole Team

    Originally this article was postet on trendig.com English & Deutsch Since 2001 we have the agile manifesto in place and since then the whole industry is learning to use agile principles and values in their daily work of software development.   agile manifesto One of the problems I see, is that many who claim to be … Continue reading Quality is the Responsibility of the Whole Team

    14.11.2018 | 5:23 קרא עוד...

טיפים

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