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

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

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

he icon   en icon

Mor Shaul

Mor Shaul

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

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

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

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

 MindMap2

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

Mandatory fields:

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

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

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

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

Mandatory

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 יחזור להופיע.

Placeholder

ToolTip:

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

Tooltip

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 או חץ-למטה ולקוות לטוב.

Scroll

Refresh:

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

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

Popup window:

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

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

Screen size:

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

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

Syntax:

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

Double negative:

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

Leave without saving

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

Permanent change

 

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

 

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

חמישי, 15 יוני 2017 08:50

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

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

למעשה מדובר בתהליך, שמתחיל בצעדיי הראשונים שלי עם 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.

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

 

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

MorS auto

ראשון, 04 ספטמבר 2016 10:46

מנהלי בדיקות ב Agile - יש דבר כזה?

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

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

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

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

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

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

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

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

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

ראשון, 28 אוגוסט 2016 09:33

למה אין Full Stack QA?

למה אין 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?