הרבה זמן ידעתי שאני אגיע ל european testing conference. למעשה שנה שלמה.
על הכנס שמעתי באמצע 2017, כאשר התחלתי להרגיש שיש לי ידע שאני יכולה לשתף בו אחרים. לכן חיפשתי כנסים בארץ ובחו"ל.
מצאתי את Agile Teating Days ואת European Testing Conference (או בקיצור AgileTD ו ETC בהתאמה).
שמחה ומאושרת, הגשתי הצעה לשני הכנסים.

לשמחתי הגדולה, מארגני ETC אינם מסתפקים בהגשת הצעה כתובה. לכל הצעה מוקצבת שיחת סקייפ בת 15 דקות.
בשיחת הסקייפ שלי, הכרתי לראשונה את מאארט ופרנצי.
למרות שההצעה שלי לא התקבלה, שיחת הסקייפ שלנו הייתה השלב הראשון שהביא אותי להיום.
מאארט זיהתה מצידה פוטנציאל הטעון טיפוח. ומייד דחפה אותי קדימה.
החל מקריאה לעקוב אחריי בטוויטר (מה שדרש ממני להתחיל להשתמש בטוויטר - כדאי לכם לנסות), מאארט הכניסה אותי לרשימת הבודקות שכדאי לעקוב אחריהן וצירפה אותי אל קהילת Women in Testing בסלאק (וזוהי כעת קריאה נרגשת לנשים שאוהבות בדיקות תוכנה, להצטרף אליי שם).

אז לא התקבלתי ל ETC 2018 או ל AgileTD 2017, אך כן לכנס סיגיסט 2017, שבו זכיתי להזדמנות ראשונה "לדבר בדיקות" לפני קהל.
מאחר שהתחלתי להשתמש בטוויטר, בעקבות דחיפתה של מאארט, ראיתי דיווחים על הנעשה בשני הכנסים ונפעמתי.
חגיגת ידע, נטוורקינג והנאה. קיבלתי החלטה - בשנה הבאה אני שם.

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

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

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

השנה הכנס התקיים בולנסיה, ספרד, בתאריכים 14-15.2.2019.
טסתי אל מדריד, משם לקחתי רכבת לולנסיה. (בחירה שאיפשרה לי לטייל מעט במדריד טרם הכנס מתחיל).
אל המלון הגעתי יחסית מאוחר, 9 בערב, כאשר מספר רב של משתתפים בכנס כבר משוטטים להם ברחבי העיר.
במלון פגשתי את ליסה ומאארט. את ליסה כבר פגשתי ב AgileTD, וזה הרגיש כמו לפגוש חברה ותיקה. זו הייתה פעם ראשונה שאני פוגשת את מאארט, שלא בשיחת וידאו. מאארט הייתה מקסימה כמו תמיד, וגם איתה תחושת החברות הייתה כבר מבוססת.
את הערב בילינו בשיחות בבר המלון עד שעות הלילה המאוחרות. מבחינתי הכנס כבר התחיל.

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

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

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

הפעילות הבאה הייתה Speed-meet. כל אחד מהמשתתפים הכין מבעוד מועד mind map על עצמו, עיסוקיו השונים, מה מעוניין ללמוד ובמה יכול לשתף אחרים. בשיחות קצרות, של כ 2 דקות לכל שיחה, המשתתפים דיברו עם הפרטנר שלהם על נושא שעניין אותם בהתאם ל mind map של הפרטנר. לאחר 2 דקות, הזוגות היו מתחלפים והמשתתפים קיבלו פרטנר חדש.
זו פעילות כיפית, מעניינת, יוצרת קשרים, ועם זאת - גם מתישה. אני מצאתי את עצמי לוקחת הפסקה קלה לאחר שיחה עם כ 5 אנשים. ואז חזרתי להשתתף. כמוני, רבים אחרים בחרו לעצור או להפסיק כאשר התאים להם.

לאחר מכן, בחרתי ללכת לסדנה של ליסה ומליסה בנושא Using Dependency Mapping to enhance testing techniques. הן הדגימו ותירגלו איתנו כיצד המחשה ויזואלית של תלויות שונות בין רכיבי המערכת יכולה לתרום לנו. לי היא תרמה להזהות אילו איזורים אינני מכירה במידה מספקת ועליי להשלים מידע לגביהן. כמו כן, גם להבין כיצד שינויים ברכיב אחד ישפיעו באופן ישיר או עקיף על רכיבים אחרים במערכת.

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

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

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

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

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

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

ההרצאה הבאה שאליה בחרתי ללכת הייתה של פרנציסקו גורטזר בנושא Brining Production observability to your testing environments.
מה שלקחתי מההרצאה שלו היה שאנחנו כל כך עסוקים בפיצ'ר בודד, בפונקציונליות, עד שאנחנו לעיתים שוכחים שזה עובר לשימוש בסופו של דבר. ואם לשימוש הזה אין מדדים, ייתכן שהחמצנו לחלוטין את המטרה והלקוחות נמנעים משימוש בפיצ'ר שעבדנו עליו רבות. אם נמדוד ובחין כיצד הלקוחות משתמשים בפועל בפיתוחים שלנו, נלמד כיצד לבדוק ולאתר תקלות ריאליות ויותר "customer facing".

ההרצאה הבאה הייתה של אלכס שלדבאך בנושא Heuristics and hunches in exploratory testing. לא היה לי ספק לרגע שאותה אני הולכת לשמוע.
ההרצאה הייתה מרתקת וסיפקה לי המון חומר למחשבה. בעיקר על מדוע אינני עושה שימוש רחב יותר ב ET?

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

משבצת זמן ראשונה - הסמכות בבדיקות תוכנה, כיצד הן תורמות, אילו קיימות ומציעות ידע אשר אינו נצבר בעבודה השוטפת ובהשתתפות בכנסים.
להפתעתי, הדעה הרווחת הייתה שיש צורך בהסמכות וצבירת ידע מתודולוגי רשמי. דיברנו על רמת הרלוונטיות ולמי מיודעות הסמכות ברמות שונות.
סקרנו בין היתר את רמות ההסמכה השונות של ISTQB, BBST, Agile Testing Fellowship ו IIST.

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

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

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

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

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

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

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

זהו תרגול ראשון מתוך סדרת תרגולים, אשר תעלה כאן בבלוג.

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

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

בהצלחה, מור

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

מערכת: תדלוק לרכבים

תחנת הדלק היא תחנה סטנדרטית, המתאפיינת:

1. תדלוק בסוגי דלקים שונים (בנזין, סולר, דיזל)

2. זיהוי אוטומטי של התקן תדלוק, אם קיים ברכב.

3. אפשרות למצב שירות מלא (בתוספת תשלום) ואפשרות למצב שירות עצמי.

4. תמיכה בתשלום בכרטיסי אשראי שונים ובמזומן.

5. לכל סוג דלק יש מחיר שונה.

6. בכל ראשון לחודש בשעה קבועה מתעדכן מחיר הדלק.

7. תהליך ביצוע התדלוק הינו:

הכנסת פיית המשאבה אל מיכל הדלק

העברת אמצעי תשלום

זיהוי מספר רכב

זיהוי תעודת זהות

התחלת התדלוק

8. סוג הדלק הנבחר הינו מזוהה על בסיס המשאבה שאת הפתיחה שלה לקחנו לתדלוק.

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

אבל זה רק קצה הקרחון.

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

אז דבר ראשון, התחלתי לחבב Mind Maps, זה עוזר מאוד להדגים את מה שעובר לי בראש וזה נראה כך:

אז נתחיל מהפשוט...

Mandatory fields:

סימון של שדה חובה – על מנת שהמשתמש לא יהיה מופתע בסוף התהליך.

האפרת שדות או כפתורים אשר תלויים בשדות אחרים – על מנת לא לאפשר למשתמש להמשיך ללא שדה חובה.

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

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

Data types:

כאשר אנחנו בודקים תקינות של תווים חוקיים בשדות טקסט, אנחנו מקפידים על בדיקה של מספרים, אותיות ותווים מיוחדים (!@#$....), אבל יש עוד לאן לנדוד.

כאשר מדובר על טקסט, מהי מגבלת התווים הנדרשת? בטוויטר זה 140 תווים. בשדה Description כלשהו עלולה להיות מגבלה של 255 תווים שאולי לא תתאים. מומלץ לתת על זה את הדעת.

כאשר מדובר במספרים, יש הרבה אפשרויות – כמובן שכדאי לשמור על הגיון והקשר. מספרים שליליים, אפס, מספר מחוץ לתחום של int (גדול מ- 2,147,483,647 או קטן מ- 2,147,483,647-), מספר עשרוני לא שגרתי (מספר ספרות אחרי הנקודה גדול מ 4), מספר רכב עם 6, 7 או 8 ספרות.

תאריכים ניתן לבחור באמצעות date-picker, אבל ניתן גם להכניס תאריך ידנית. ומה לגבי הפורמט של התאריך? dd/mm/yyyy או שאולי mm/dd/yyyy, ויכול להיות שיש גם שעה – dd/mm/yyyy hh:mm:ss. כל הנתונים האלה בסופו של דבר נשלחים מצד ה Client אל ה Server ויכולים להיכשל.

Default value:

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

ומה בנוגע ל Radio buttons? אנו צריכים לוודא איזה ערך מסומן מבין הכפתורים או האם מסומן ערך כלשהו כלל.

מכירים את שדה ה "...I agree to the terms and"? אז השדה הזה כברירת מחדל צריך להיות לא מסומן.

ושדה ה "...I want to receive e-mails on promotion"? השדה הזה צריך להיות מסומן?

בחלק משדות הטקסט, תהיה דוגמה לערך הרצוי – למשל This e-mail address is being protected from spambots. You need JavaScript enabled to view it., צריך לוודא שהערך ישנו ושניתן למחוק אותו.

Placeholder:

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

ToolTip:

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

Media:

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

Animation:

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

האירועים שאנו נבצע יכולים להיות מעבר עם הסמן על אזור/לינק, כניסה לשדה או יציאה משדה, לחיצה על Enter או Esc ועוד.

Tabs order:

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

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

Field types:

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

Date-picker – שדה בחירת תאריך מתוך לוח שנה

Radio button – שדה בחירה בודדת מתוך מספר אפשרויות

Textbox – שדה טקסט חופשי

Combo-box – שדה בחירה מתוך רשימה

Button – כפתור לחיץ

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

Check-box – שדה המאפשר בחירה בין שני מצבים, מסומן או לא מסומן.

Toggle button – כפתור אשר מבצע החלפה בין שני מצבים (On/Off, שתי תצוגות וכו').

Table – בטבלת נתונים, הכותרות והנתונים המוצגים בה צריכים להיות ניתנים לקריאה וגודל העמודות ניתן לשינוי/קבוע (בהתאם לצורך).

Keyboard functions:

זה אולי נשמע דומה לנושא ה Tabs order, אבל רק חלקית.

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

Esc – יציאה משדה ללא שינוי התוכן

Enter – יציאה משדה עם שמירת השינויים

Tab – מעבר לשדה הבא

Shift-Tab – חזרה לשדה הקודם.

ובנוסף:

Space – שינוי מצב של Check-box, Toggle button, Radio-button.

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

PageUp/PageDown – משמשים לגלילה בדף.

* היכולת לעבור שורה מבלי לצאת מהשדה. (לא מחייב אבל ייתכן שנדרש)

Scroll:

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

אנחנו רוצים לוודא שזה לא קורה אצלנו.

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

Refresh:

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

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

Popup window:

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

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

Screen size:

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

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

Syntax:

Syntax כולל דקדוק, פיסוק, אות גדולה בתחילת שם, מקום, משפט וכותרת.

Double negative:

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

צריך לשים לב לזה כאשר הפעולה שנשאלים עליה "מסוכנת" למשתמש.

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

* תודות למי שתרם לתכני ה Mind Map:
Assaf Lowenstein
Kobi Halperin
Doron Bar
Yoni Flenner

השנה הראשונה שלי באוטומציה

למעשה מדובר בתהליך, שמתחיל בצעדיי הראשונים שלי עם Selenium.

לפני כן, יצא לשחק קצת עם QTP, להשתמש מעט ב OmniTest ולהתנסות ב 30 ימי ניסיון עם Test Studio, אבל לא מעבר לזה.

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

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

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

אני מוכנה לאוטומציה!

באחת מקבוצות הפייסבוק של קהילת הבודקים, יוני פלנר (קרדיט!!!) פרסם סדנת-ערב בת 3 שעות חינמית, שבה ילמד מבוא לסלניום. הגעתי לסדנא וממנה יצאתי בודקת אוטומציה. בנפש.

רציתי ליישם את כל מה שלמדתי, אז המשכתי והתאמנתי על אתר הדמו של יוני (אני אחראית על מאות כניסות לאתר הדמו, שוב תודה ליוני).

כאשר הייתי מרוצה ממה שכתבתי, הראיתי את היצירה שלי (טסט שמבצע Login) לאחד המפתחים בעבודה.

הוא עזר לי לשפר את הטסט שכתבתי, להשתמש ב Page-objects ולייעל את הכתיבה שלי.

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

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

כאשר זה היה מוכן, הצגתי את הפרויקט שלי למנהל ה R&D והוא היה מוכן לשמוע על אוטומציה.

בשלב זה קיבלתי משימה רשמית להציג חלופות אפשריות לצורך הקמת תשתית אוטומציה. (שלא הייתה קיימת עד כה)

במהלך החודש הזה בחנתי כל מיני שפות פיתוח, כלים OpenSource ומסחריים ו frameworks. ביניהם Java, JavaScript, Ruby, RedwoodHQ, TestComplete, Cypress, ScalaTest, Spock, Watir, TestNG ו Protractor.

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

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

בחרתי להריץ את הטסטים באמצעות Protractor, בחירה שבינתיים נראית טבעית מפני שצד ה Client שלנו מפותח ב Angular.

על מנת להריץ את הטסטים isolated, אנחנו מתכננים לשהתמש ב Docker על מנת להקים במהירות instances חדשים של ה DB. את הדאטה עבור הטסטים אנחנו שומרים בקבצי Json.

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

תעזו, תעשו, תצליחו. 

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

לאן נעלמו המנהלים?

האם עולם ה Agile גרם לנו להתפתח? או שאולי הוא מתאים רק בסוג מסוים של אנשים? או שאין מקום/צורך במנהלים בעולם ה Agile?

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

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

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

אז אני חוזרת לשאלה הראשונה, מנהלי הבדיקות נעלמים? האם מקומם הינו רק בעולם ה Waterfall?

לדעתי, יש מקום וצורך לטפח בעולם ה Agile, את תפקיד ה QA Tech Lead, שיהיה מוביל ונותן טון עבור הבדיקות, תוך כדי עבודה בצוות הפיתוח – 100% hands-on.

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

למה אין Full Stack QA?

בימים שבהם מקצוע בדיקות התכנה מקבל הרבה הכרה וגם כל כך הרבה שמות, איך זה שעדיין לא תבענו את המושג Full Stack QA?

QA Tester, QA Analyst, QA Engineer ו – QA Expert הינם שמות פופולריים לתיאור תפקידנו, אך אינם מייצגים את הידע או יישום בפועל של תפקידנו במקום העבודה.

בעולם ה Web, כבר השאירו מאחור את מפתחי ה Client/Server, ופנו ל Full Stack Development.

Full Stack Developers מוכרים כאנשי פיתוח אשר מיישמים ביום-יום - פיתוח front-end ופיתוח back-end. סל הכישורים שלהם כולל תחומים רבים ברמת ידע בסיסית ומעלה.

אז מדוע בודקי תוכנה בעולם ה web אינם Full Stack QA? הרי גם לנו יש ידע בסיסי ומעלה במגוון נושאים, ביניהם: API, WS, DB, HTML, XML, תכנות/כתיבת סקריפטים, CI ועוד. רובנו אף משקיעים ולומדים אוטומציה במסגרות שונות.

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

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

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

שפות סקריפט: Java, JavaScript, Mocka, Chai, Cy, Scala, Ruby, VBScript

דרייברים: Selenium, Watir

BDD frameworks: Cucumber, Spock, Serenity, ScalaTest

כלי אוטומציה ברישיון: TestStudio, UFT, TestComplete

אז יכול להיות שגם QA Automation הוא מושג כללי מידי.

אז אם כל הידע שרכשתי והתנסיתי בו, האם אני QA Engineer? QA Analyst?

או שאולי Full Stack QA?