יום ראשון, 28 ביוני 2015

Form for Exploratory Testing - טופס לניהול אקספלורטורי טסטינג

So it's clear to everyone that exploratory testing is more than just "testing". They should be planned and, at some level, documented.

Attached is a form, if you wish, to be filled in before, during and after the tests.

  ×™×œ×“ שמבין באקספלורטורי יותר מאיתנו
Exploratory Tests Form

Date: Feature to be tested:

The scope of testing:
Examples: UI
Functionality Validation Usability Validation etc.

Time Frame (recommended: up to 2 hours):

The technique to be used (mark the relevant one/s or add new ones):
Examples:
Risk management (tests what is more risky) Use case / User stories “Drifting” vs. the spec Scenario based (Soap Opera) These are tests where one assumes that the user has everything going on. Invariance testing changes things that shouldn't affect the product and then makes sure that they indeed don't Gorilla testing is a quick attempt to determine the level of risk of a subsystem It can also be used to find major bugs early in the cycle run tests that emulate user tasks. Some testers should explicitly be given a task focus, not a feature focus. Their job is to do whatever users do in order to accomplish whatever it is that users try to accomplish. Run the tests based on the Manual of the product Bug based testing. Run tests based on bug types found in the feature/application going over the menus

Test mission:

Examples:
Does something work as requested in the requirement? How does something work under this and that conditions? Is documentation of something aligned with the actual something behavior? What is the performance of something? Does something behaves user-friendly way? Does something affected current and existing behavior of something

Running log (please fill while you go):

Testing the: Conjecture(or: what could go wrong and how to find it): Flows that I run in high level: a. b. c.... Conjecture refuted / corroborated: New conjecture etc.... I saw something strange… Bugs found in high level (will be reported later):

My impressions:
Feelings I had about the product, about specific features, flows etc. (Bad and good  ). Thoughts about the testing: is the product good? Reliable? Does it serve its purpose? Will users like it?

Thoughts about the test itself: (what was good, what we can improve, what was missing). what should be tested next based on my experience.

Jun 28, 2015

יום שישי, 26 ביוני 2015

אג'ייל: האם כדאי לדווח על באגים במערכת ניטור

בעד:
1. כבר רגילים, אין צורך ללמוד משהו חדש.
2. יש בבאג הרבה מידע (סביבות, לוגים, על מי הבאג, באיזה הקשר התגלה וכד').
3. נח להוסיף לו דברים כמו צילומי מסך.
4. שמירת מידע על באגים שתוקנו, נדע למשל מתי תוקנו ואיך במידה שהם חוזרים. או למשל אם באג התגלה כבר כ-invalid חוסך זמן לבודק לתעד שוב.
5. מדידות.
6. במקרה שיש כמה קבוצות ויכולה להיות השפעה הדדית. יחד עם זה תמיד עדיף לתקשר את הבאגים בשיחה.
7. אם מודדים באגים.
  
באג מדווח
נגד:
1. צורך זמן.
2. הרבה באגים בכלל לא מתכוונים לתקן.
3. מספיק פתק פשוט עם הבאג והכנסת הסנריו לרגרסיות.
4. גם היום מפתחים בד"כ לא מכניסים בגים שהתגלו בקידוד.
5. ניתן לשמור מידע גם בדף FAQ.
6. מעודד פחות תקשורת ורבלית בין צוותים.
7. דורש טיפול רב: כתיבה, טריאג'ים, הסברים, שחזורים, הערות.
  
דעתי:
אם הבאג מתוקן יחסית במידי (הייתי אומר: באותו יום) - אין צורך לדווח.
אם הבאג מתוקן בספרינט (אבל לא היום) - כדאי לכתוב על הבאג בכמה מילים במקום הזמין לכולם.
אם הבאג אינו מתוקן בספרינט - יש לדווח אותו.

Jun 26, 2015

יום חמישי, 25 ביוני 2015

Planning Poker

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

יחידות המדידה בהן בוחרים הן שיטה אחת מאלה:
1. פשוט מספרי ימים.
2. סדרת פיבונאצ'י. כיוון שההערכה היא גסה ולא מדוייקת, הסדרה אמורה לשקף זאת.
3. לפי מידות בגדים: S, M, L, XL, XXL.
4. Story points. זו שיטה שמגיע לה פוסט כשלעצמה. בעיקרון אלו יחידות מידה יחסיות לא חופפות זמן אלא לפי מורכבות או גודל הסטורי.
5. Ideal days - זמני נטו של העבודה.



איך זה מתנהל?
1. ה-product owner מציג את הסטורי לקבוצה אך אינו משתתף בהערכה.
2. המשתתפים מורידים את האפליקציה ומקנפגים אותה ליחידות המדידה שהוסכם עליהן.
3. כל משתתף בוחר את ההערכה המתאימה.
4. לאחר שכולם בחרו הם מציגים את ההערכות שלהם.
5. בעל ההערכה הגבוהה ביותר והנמוכה ביותר מסבירים את השיקולים שלהם.
6. חוזרים על 3-5 עד שמושגת הסכמה.


יום שבת, 20 ביוני 2015

DNS והקשר לבדיקות קליינט סרבר ובדיקות ווב

ראיינתי עשרות אנשי בדיקות, חלקם בתחום שנים רבות, שלא ידעו לענות לי, אפילו בדרגה שטחית, על המושגים הבסיסיים ביותר בתחום. אם תסלחו לי רגע על הצדקנות, בודק ווב 5 שנים שלא ממש מבין מה זה cookie, כמעט בוודאות לא בדק את המוצר שלו כמו שצריך. סתם לצורך אנקדוטה, מישהו אפילו הסביר לי שפעם הוא שאל את המפתח מה זה cookie, אבל התשובה הייתה "מסובכת נורא". בכדי לדעת לבדוק מוצרי client-server בסביבת web צריך להתחיל מהיסודות הטכניים, להבין את זרימת המידע בין הקליינט לסרבר ועוד.
ידע זה אינו נשאר בספירה תיאורטית,  זה יכול לעזור גם לבדיקות עצמן:
1. בתכנון הבדיקות.
2. בהבנת מיקומה של הבעיה.
3. ככלים העוזרים לבדיקות.
  
כשלא יודעים מה זה cookie, אתה (בהתאמה):
1. לא יכול לבדוק שהצבת ה- cookie השיג את מטרתו (למשל לשמור מידע מאוד ספציפי על המשתמש), האם המידע שם שצריך להיות אכן מוצפן ועוד בדיקות.
2. לא תדע איפה להתחיל לדבג בעיות. למשל  איך זה שאני נזרק מהאתר במעבר בין דפים.
3. לעשות מניפולציה על ה- cookie בשביל לבדוק מה קורה כשלמשל תוקף ה-cookie פג.
  
אבל עכשיו אדבר דווקא על DNS, Domain Name System.
מה זה בעצם DNS? DNS הינו בראשונה פרוטוקול המשרת מערכת שמטרתה להמיר שמות דומיין מתווים שאמורים להיות בעלי משמעות (למשל: google.com) לכתובת IP (למשל: 173.194.112.169).
אפשר למצוא את כתובת ה-IP ידנית ע"י הרצת שורת הפקודה (windows+r, הקלקת CMD ו-Enter), ואז הפקודה: ping google.com.
אם אפשר להגיע לשרת נקבל את ה-IP.
בתסריט שהמחשב / הטלפון לא מכיר את ה-IP (תיכף אסביר איך ייתכן שהוא מכיר) זה עובד כך:
את מקלידה google.com ב-address bar של הדפדפן, מקליקה על ה-enter -> הדפדפן מחפש אצלו את ה-IP של גוגל. אם מצא הוא משתמש בו בכדי להגיע לשרת. אם לא מצא -> פניה לשרתי DNS. מדובר במספר רב של שרתים שמאחסנים כל אחד מידע יחסית קטן. זה מתחיל בפניה לשרת ה-ISP (ספק האינטרנט שלך – Internet Service Provider) שבמידה ואינו מוצא את ה-IP הוא מעביר את הבקשה לשרת DNS root שמעביר אותך לשרת אחר שאמור לספק את התשובה.
הכנתי תרשים לוגי בכדי להקל על ההבנה, לאו דווקא מדוייק במאת האחוזים.

DNS והקשר לבדיקות קליינט סרבר ובדיקות ווב

אבל אולי אותנו כבודקים יעניין התהליך הפנימי שקורה בתוך המחשב, תיכף אסביר למה.
לפני שהמחשב בכלל פונה לשרת DNS הוא פונה לקובץ מוגן משינוי שנקרא hosts ונמצא ב-C:\Windows\System32\drivers\etc (בווינדואוס כמובן. לגבי אנדרויד למשל אפשר לראות כאן). שם הוא מחפש את השם שהוקלד, למשל google.com. אם הוא מוצא אותו, זה יראה כך:
מה זה אומר? בעצם דבר פשוט: עזוב אותך אחי מללכת לשרת DNS וכאלה בזבוז זמן, אני יודע את הכתובת המדויקת של מה שאתה מחפש – זה 173.194.112.169. וזה מה שקורה – הדפדפן מחפש ישירות את 173.194.112.169.
  
למה זה טוב (פרט מלשגע מישהו ולתת לו IP של פייסבוק בכל פעם שהוא מקליד google.com)? זה טוב כשאנו צריכים לעבוד בבדיקות מול שרת מקומי. למשל את עובדת על אתר בשם atar.com. כשמקליקים את זה ברגיל, נגיע לאתר העובד שכל העולם יגיע אליו באותה דרך. אבל אנחנו בודקים את הגרסה החדשה של האתר בסביבת הבדיקות טרם עלייתו לפרודקשין. ולאתר בסביבת הבדיקות יש IP משלו. אז נכניס לקובץ hosts את השם atar.com עם ה-IP של שרת הבדיקות. עכשיו כשנקליק את שם האתר הדפדפן ונלחץ Enter, המחשב יחפש קודם בקובץ, ימצא את ה-IP הפנימי ויפנה אליו.
  
אבל אם אין את האתר בקובץ ה- hosts אנחנו עדיין לא ברשת. המחשב מחפש ב-DNS cache הפנימי שלו. רוצים לראות אותו? הקלידו את הפקודה הבאה:
ipconfig /displaydns
זה יראה כך:
ואם אתם תמיד מגיעים בבדיקות לאתר הלא נכון, כדאי למחוק את ה-DNS cache כך:
ipconfig /flushdns
  
ואם אתם רוצים להתחבר ישירות לשרת DNS מסויים:
בקונטרול פאנל לכו לרשתות לפי מה שמצויין בתמונה, פרופרטיס של ה-local area connection, פרופרטיס של Internet Protocol version 4:
בעקבות הערה בפורום, יש עוד פקודה המזכירה את ה-ping ונקראת nslookup. הפינג מורה לאן אתה מגיע בפועל. כלומר הוא עובד דרך הקש וקובץ ההוסטס, ואם הוא מגיע לשרת הוא יחזיר את ה-IP.
 nslookup יביא הכתובת האמיתית של השרת מבלי התייחס לקש, להוסטים או למצב השרת (הוא בודק בשרתי ה-DNS).
כלומר nslookup יותר מדוייק מפינג, אבל השאלה מה אתה צריך: להבין לאן אתה מגיע בפועל, או מה כתובת השרת.
  
  
  
  
  
מקורות:

  

יום חמישי, 4 ביוני 2015

תעלומת החולצה הכחולה

עבדתי בסטארט-אפ שאיפשר שידורים חיים ברשת, מעיין "בלוג" אישי שמשודר ב-live. כל מה שצריך זה מחשב ומצלמה.
  
בתחילה היה שדר אחד, אח"כ הקלטות של השידור. כחלק מתהליך הבדיקות בדקנו את איכות השידורים וההקלטות, והיו לנו כל מיני שיטות לבדוק אותם. היינו מקליטים את עצמנו מדברים עם עצמנו בשביל לבדוק תזוזה, שמיעה, איכות שידור והקלטה וכד'. לפעמים היינו משדרים שעון או פשוט מריצים סרטים.
  
במהלך הזמן הוספנו פיצ'ר - שידור ראשי, של המנחה כביכול, עם שידור מישני. ה"מישני" הועלה לשידור ונשלט ע"י ה"ראשי".
אח"כ הוספנו אפשרות הקלטה של השידור הכפול. בעצם שתי ההקלטות היו נשמרות בתור שני קבצים מסונכרנים, בתוך תיקיה אחת. שם התיקיה היה שם השדרן, וכל תיקייה ספציפית של הקלטות כללה את שעת סיום ההקלטה.
בדקנו את הסנכרון בבהקלטות בין ההמנחה לשדר המשנה, החלפה של שדרים משניים במהלך השידור ועוד. לבסוף היינו ממש קרובים לשחרור הגרסה.
הקלטנו כמה הקלטות בסטייג'ינג, ליתר בטחון. הכל נראה בסדר, וכבר הייתי מוכן לתת את האישור של הבדיקות. לפתע, לנה, אחת הבודקות בצוות,  אמרה משפט שהפך את הכל:
תעלומת החולצה הכחולה
תעלומת החולצה הכחולהתעלומת החולצה הכחולה
"אבל החולצה שלי כחולה". "מה?" שאלתי, לא מבין למה עברנו לדבר על אופנה לפני שחרור גרסה כזו חשובה.
"החולצה שלי כחולה, אבל בתור שדרנית המשנה בהקלטה אני בחולצה ירוקה. בעצם," הוסיפה, "זו החולצה שלבשתי אתמול."
התברר ששבמקרים מסיימים למרות שההקלטות היו נשמרות במקום הנכון (בדקנו!), את שדר המשנה השרת היה לוקח דווקא מספרייה אחרת, קודמת, אם היתה קיימת שם הקלטה כזו. במקרה הקלטנו תחת השדר / המשתמש הספציפי ההוא גם יום לפני עם שדר משנה, וכך הוצפה הבעיה.
  
האם יכלנו לחשוב על תסריט כזה, של בדיקת הקלטת שדר משנה כשיש כבר ספרייה עם שדר משנה? אני לא יודע, אבל ברור לי דבר אחד: במציאות של ה-production, זה היה מתגלה מהר מאוד, כי השידור עם שדר המשנה וההקלטה שלו היו נפוצות, ובמציאות מיד היית מזהה ששדר משנה של היום הוא בעצם זה של אתמול.

רשומות פופולריות