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

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

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

הניסיון של Wrike בארגון בית ספר

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

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

— אילו קשיים היו לתלמידים?

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

- האם בית הספר השתלם?

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

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

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

טיפים לארגון

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

שלב 0. צור מילון

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

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

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

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

שלב 1. חזור על ביטויים

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

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

כתוצאה מכך, מי שהקשיב ועשה הכל יוכל:

1. ללמוד לעבוד עם ממשק סביבת הפיתוח: יצירת סניפים, מקשי קיצור, מתחייבים ודחיפות;
2. לשלוט ביסודות המבנה של השפה והשיעורים: היכן להכניס זריקות והיכן לייבא, מדוע יש צורך בהערות, ואיזה סוג של סמלים נמצאים שם, מלבד השלבים;
3. להבין את ההבדל בין פעולה, לחכות ולבדוק, היכן להשתמש במה;
4. שימו לב להבדל בין בדיקות אוטומטיות לבדיקות ידניות: בבדיקות אוטומטיות תוכלו למשוך מטפל כזה או אחר במקום לבצע פעולות דרך הממשק. לדוגמה, שלח הערה ישירות לחלק האחורי במקום לפתוח תצוגת משימות, בחירת הקלט, הקלדת טקסט ולחיצה על כפתור השליחה;
5. לנסח שאלות שייענו בשלב הבא.

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

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

מה לא לתת:

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

שלב 2. מבט מקרוב על הדקדוק

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

ובפנים יש לנו את הדברים הבאים:

onCommentBlock(userName).comment(expectedText).should(displayed());

היכן נמצא OnCommentBlock

onCommonStreamPanel().commentBlock(userName);

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

לא, עדיין לא הגיע הזמן לדבר על xpath. רק ציין בקצרה שכל ההוראות הללו מתוארות על ידם והירושה עוברת דרכן. אבל אנחנו צריכים לדבר על כל השדכנים והמלצרים האלה, הם מתייחסים ספציפית לצעד הזה והם נחוצים כדי להבין מה קורה. אבל אל תעמיס יותר מדי: התלמיד שלך יכול ללמוד קביעות מורכבות יותר בעצמו מאוחר יותר. סביר להניח ש- should, waitUntil, displayed();, exist();, not(); אמור להספיק.

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

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

שלב 3. טבילה מלאה

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

ראשית, הבה נבהיר שכל אלה ב-CommentBlock והתגובות מתוארות על ידם.

סך הכל:

"//div[contains(@class, ‘stream-panel’)]//a[contains(@class,'author') and text()='{{ userName }}’]//div[contains(@class,'change-wrapper') and contains(.,'{{ text }}’)]"

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

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

בשלב זה, הקהל היה צריך להבין היטב כיצד הם עוברים בירושה ומה ניתן להזין אחרי הנקודה ב-onCommentBlock. בשלב זה, אנו מסבירים את כל האופרטורים: /, //, ., [] וכן הלאה. אנו מוסיפים ידע על שימוש לעומס @class ועוד דברים נחוצים.

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

למה דווקא הנתיב הזה?

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

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

מקור: www.habr.com