בדיקות אוטומציה – האם אוטומטורים הם הדור החדש של הבודקים? ואיך שילוב בין בדיקות ידניות ובין בדיקות אוטומטיות מוביל לצוות מנצח…
מה קופץ לך לראש כאשר אתה שומע את המילים בדיקות אוטומציה או בדיקות אוטומטיות?
צוות של אנשי בדיקות אוטומציה אשר כותבים בדיקות אוטומציה?
מתכנתים אשר כותבים בדיקות אוטומטיות?
או אולי צוות של אנשי QA, שהיו פעם אנשי בדיקות ידניים ועכשיו עושים את תהליך הבדיקות הידניות וגם כותבים בדיקות אוטומציה כחלק מתפקידם כאנשי בדיקות ידניות ואוטומטיות?
ההתייחסות לאוטומציה, צורת ההתנהלות הפנימית בתוך החברה
ותפקידם של האנשים שכותבים אוטומציה היא שונה בין חברה לחברה,
ולכל צורת עבודה יש יתרונות וחסרונות.
הפוסט הזה מיועד בעיקר למנהלי QA וראשי צוותים ב-QA,
אבל הוא עלול לעניין אותך גם אם אתה בודק תוכנה שרוצה להבין את האתגרים במעבר לאוטומציה ואתה רוצה להבין איך עולם הבדיקות משתנה.
בפוסט הזה אני הולך להסביר על הדור החדש של הבודקים,
על תהליך ההחלטה במעבר לבדיקות האוטומציה ומי לדעתי צריך לכתוב בדיקות אוטומציה?
אז מה אתה חושב?
האם לדעתך צריך לקחת אנשים שלמדו תכנות בשביל לכתוב בדיקות אוטומציה?
או האם לדעתך המתכנתים הם שצריכים לכתוב בדיקות אוטומטיות?
ואולי לא צריך בכלל בודקים ידניים ואפשר להסתמך רק על בדיקות אוטומטיות?
לפני הכל … (בעיניי),
בשביל לכתוב בדיקות (בדיקות ידניות או בדיקות אוטומטיות) בצורה טובה ואיכותית,
צריך אנשים שמבינים עניין בעולם הבדיקות.
חייבים בודקים שאוהבים את העולם הזה, וחייבים אנשים שזווית הראייה שלהם היא זווית ראייה של בודקים ולא של מתכנתים.
ולכן גם איש בדיקות אוטומציה אשר כותב אוטומציה חייב להיות קודם כל איש בדיקות, אחרת הוא פשוט רובוט שמתרגם תסריטים ידניים לתסריטים של אוטומציה.
האם האוטומטורים הם הדור החדש של הבודקים? האם אפשר לכתוב בדיקות ידניות וגם לכתוב בדיקות אוטומציה?
בשנים האחרונות שינה עולם ה-QA פאזה,
וחלק גדול מהפוקוס והזמן מוקדש על מנת לשפר את תהליך ה-QA ובמיוחד לעשות אותו למהיר הרבה יותר.
ומהירות זה אומר אוטומציה!
אז בוא נראה איך עושים את התהליך הזה של מעבר מהבדיקות הידניות לאוטומציה בצורה נכונה
ואיך מטמיעים אוטומציה בצורה נכונה בצוות קיים שהיה מורכב עד היום מצוות של בודקים ידניים?
המטרה:
לעשות זאת תוך כדי שיפור מתמיד באיכות המוצרים,
ותוך כדי שיפור במהירות הוצאת הגרסאות ותוך כדי שימור האנשים בצוות.
בפוסט הזה אני נותן את הזווית האישית שלי לניהול הצוותי,
וכן להחלטות שצריך לקחת על מנת שהתהליך כולו יעבור בצורה חלקה,
ועל מנת שתהנה מהיתרונות שמוזכרים בהמשך.
אני יכול לציין שאחרי 20 שנה של ניהול צוותים בתחום הבדיקות ראיתי הרבה טכנולוגיות מתחלפות,
אבל מה שלא ראיתי זה שינוי בנפש האדם,
ולכן אני חושב שאוטומציה זה קודם כל אנשים.
בינינו,
אנשי פיתוח לא ממש אוהבים לעשות בדיקות וגם הראיה שלהם שונה.
ולכן מנהלים שרוצים לבנות אוטומציה איכותית לאורך זמן צריכים להסתמך על אנשים שהבדיקות זורמות להם בדם.
איך עוברים מבדיקות ידניות לביצוע של בדיקות אוטומטיות?
בואו נחשוב על התסריט הבא:
יום אחד החברה שלך מחליטה לעבור לתהליכי פיתוח מהירים (agile) והמטרה שלכם היא להוציא גרסה כל לשבועיים.
מהר מאוד אתם רואים איך שה-QA הופך להיות צוואר הבקבוק בשחרור הגרסה,
היות ואנשי הבדיקות לא מספיקים לבדוק שוב ושוב את כל המוצר.
המצב הזה רק הולך ומחמיר וכולם מבינים שאין סיכוי לעמוד בזמנים האלה אם לא נכניס לתהליך בדיקות אוטומטיות.
אז מה הפתרון?
מנהל הבדיקות(אתה?) מגיע להחלטה שהוא הולך להקים אוטומציה,
והוא הולך להתחיל ולכתוב בדיקות אוטומטיות.
אבל מה לעשות שיש לו רק 4 אנשי QA ידניים בצוות שלו?
ועכשיו עולה השאלה מה עושים?
האם מביאים מישהו מבחוץ להקים את האוטומציה ולכתוב בדיקות אוטומציה?
או ש…לוקחים את אחד מאנשי הצוות ומכשירים אותו להיות איש האוטומציה?
או אולי מעבירים את כלל אנשי ה-QA קורס אוטומציה והופכים את אנשי הבדיקות כולם לאוטומטורים,
כך שכולם יעשו את התפקיד שלהם ובנוסף יוסיפו לתהליך את החלק של בדיקות האוטומציה.
מה לדעתך צריך לעשות?
מה אתה היית עושה?
בוא נעצור לרגע ונבין איך כרגע נראה תפקיד ה-QA.
באופן מופשט מאוד הוא נראה בצורה הבאה:
איש הבדיקות מקבל feature אחד או יותר בכל איטרציה, הוא אחראי עליו מההתחלה ועד הסוף והוא בעצם כותב ומריץ את הבדיקות, הוא מדווח באגים ואף בודק את התיקונים. ממש כמו שתראה בתמונה הבאה:
כולנו יודעים שהיתרונות בתהליך הזה הם רבים:
איש אחד מכיר את הפיצ’ר מההתחלה ועד הסוף, הוא אחראי עליו בלעדית, וקל לו לבדוק את החלק הזה במוצר.
איש ה-QA מבין בדיוק איך ללכת שמאלה וימינה בבדיקות, והוא יודע בדיוק איך לשחזר את הבאגים במידה והם תוקנו על ידי הפיתוח.
וגם במידה ובאגים התפספסו כולם יודעים אל מי לפנות בקלות כדי “לסקול אותו באבנים”.
(טוב נו…לא באמת:)
עכשיו,
כחלק מהתהליך מנהל ה-QA יכול לגייס איש אוטומציה אשר יקבל את התסריטים מהבודקים ויכתוב אותם לכל הבודקים.
ואז התהליך שלנו יראה כמו התהליך בתמונה פה.
בוא נעצור לרגע ונחשוב…
מה ההבדל בין לכתוב אוטומציה לבין כתיבה של SQL על מנת לבדוק דברים?
הרי גם SQL וגם אוטומציה הם בסה”כ עוד כלים בידיו של הבודק…
ולכן,
הרעיון הוא לשמר את אותו תהליך כך שהבודק ימשיך ויהיה אחראי על כל התהליך של בדיקת הפיצ’רים מההתחלה ועד הסוף.
ובשביל לעשות זאת נוסיף לארגז הכלים של איש הבדיקות את היכולת לכתוב אוטומציה, ותהליך הבדיקה שלנו ישתנה רק במקצת.
התהליך החדש יראה בצורה הבאה:
לאחר קבלת פיצ’ר חדש איש ה-QA ימשיך להיות אחראי על כל התהליך,החל מקבלת הפיצ’ר, הוא יבין איך הפיצ’ר עובד, הוא יהיה אחראי על כתיבת ה-STD,
אבל בנוסף הוא יהיה אחראי על כתיבת התסריט בצורה אוטומטית.
בצורה כזאת איש הבדיקות נשאר אחראי על הפיצ’ר ברמת התהליך המלא, ותהליך הבדיקה נראה כך.
ועכשיו…
היות ויש לנו 5 אוטומטורים אז תהליך הבדיקות ישאר באותו צורה כמו שהוא היה לפני כן והוא יראה בצורה כזאת.
כמו בכל החלטה אותה אנו לוקחים יש יתרונות ויש חסרונות,
אך מניסיוני ולטעמי היתרונות עולים על החסרונות לאורך זמן.
בוא נראה,
מה היתרונות בהסבה של אנשי הבדיקות לאנשי בדיקות אוטומציה?
- שימור עובדים לאורך זמן –
שימור עובדים הוא אחד האתגרים הגדולים למנהלי QA ושימור עובד לאורך זמן הוא רווח לחברה.
שימור עובדים לאורך זמן יתקיים רק במקרים בהם יש מצב שהוא win-win
(שני הצדדים זוכים: גם העובד וגם החברה).
זאת אומרת שאיש ה-QA תורם מהידע שלו ועוזר לחברה להתקדם,
ומצד שני החברה מנסה לדאוג שהעובד יהיה מרוצה וירגיש שהוא מתקדם וישאר בחברה לאורך זמן.
המעבר מבדיקות ידניות לתוך בדיקות אוטומציה זו דרך מצויינת להשיג עובדים מרוצים, וכך לשמר אותם ואת הידע שלהם. - קידום אנשי הצוות ולא אנשים מבחוץ –
אנשים הם בני אדם, ולכן הם רואים בעין לא יפה כאשר מביאים מישהו מבחוץ לתפקיד בדיקות אוטומציה כאשר היה אפשר לבנות אותו בצורה נכונה מתוך האנשים בחברה וכך לקדם אותם.
כאשר מביאים מישהו מבחוץ ולא מפתחים את האנשים בתוך החברה זה אומר משהו על החשיבה וההתנהלות של המנהלים וההנהלה בתוך החברה, מניסיון חלק גדול מאנשי הבדיקות יעזוב את החברה בגלל חוסר היכולת להתקדם, ולא בגלל השכר או נושאים אחרים.
אל תתפלאו אם פתאום אנשים מתחילים לעזוב אחרי שמביאים אדם אחר שנכנס לתוך תפקדי של בדיקות אוטומציה ותופס להם את המקום אליו יכלו להתקדם. - ורסטיליות מלאה בין הבודקים –
בתור מנהל, כאשר כל אנשי הבדיקות מכירים ועושים את אותו תהליך,
אז פשוט לנו לנהל ו”להזיז” אנשים בין המשימות כי כולם מכירים את כל התהליך.
כאשר אנשי ה-QA ממשיכים לעשות תהליך מלא של בדיקות ידניות וכן בדיקות אוטומציה אז יותר פשוט לנו לנהל את התהליך ואת האנשים.
במידה ואיש אחד כותב את הטסטים הידניים ומישהו אחר מתרגם אותם לאוטומציה וכותב בדיקות אוטומציה,
יש נתק בתהליך ואין בכלל אפשרות להזיז אנשים בין התפקידים השונים. - אין תלות במישהו אחד – תחשבו מה קורה אם אתם מביאים מישהו יחיד לכתוב בדיקות אוטומציה, מן תותח אוטומציה כזה.
הוא מתחיל את כל התהליך, כותב טסטים, אבל אחרי מספר חודשים לא רב הוא מתחיל להשתעמם כי הוא מוצא את עצמו כותב בעיקר תסריטי בדיקות
ואז הוא עוזב לאתגר הבא.
ואתם?
שמתם את כל הביצים בסל אחד והסל נעלם!
ברגע שהוא עוזב פרוייקט האוטומציה שלכם קורס מיידית!
כאשר הופכים את אנשי הבדיקות לאוטומטורים, התלות הזאת נעלמת והסיכון נעלם!.
- שימור הידע בין האנשים –
לא תמיד אנחנו חושבים על זה כי רובינו עסוקים בכיבוי שרפות, וענייני היום יום,
אבל אחד הדברים הקריטיים להצלחה של חברה לאורך זמן היא שימור הידע.
ראיתי הרבה מקרים בהם בודק או אדם אחר בחברה עוזב כאשר ברשותו ידע קריטי ואז החברה מאבדת המון ידע ומבזבזת המון זמן לנסות ולהשלים את החסר.
הרבה יותר קל ופשוט לשמר ידע בין בודקים שונים באופן שוטף כאשר כולם עושים את אותו התהליך,
ובפועל כל אחד יכול לבדוק כל פיצ’ר מההתחלה ועד סופו, כולל כתיבה של אוטומציה. - איך לדעת מי הם הבודקים הכי טובים שלך?
ואיך אתה יכול להבין האם צריך לגייס עוד בודקים?
בתור מנהלי QA, אנחנו תמיד רוצים לדעת מי הבודקים היותר איכותיים שלנו.
הרבה יותר פשוט וקל לנו בתור מנהלים להשוות בין הביצועים של הבודקים בצוות כאשר כולם עושים פחות או יותר את אותו הדבר.
ובנוסף,
הרבה יותר קל להבין האם חסרים לנו בודקים בתהליך, וכמו כן כמה בודקים בדיוק חסרים.
בצורה כזאת אנחנו יודעים בקלות אם יש צורך לגייס עוד אנשים לצוות,
וכן קל לנו להציג למנהלים את החוסר בבודקים.
לסיכום = אוטומטורים הופכים להיות הדור החדש של אנשי הבדיקות, גם בדיקות ידניות וגם בדיקות אוטומטיות.
לאף אחד אין ספק כי אוטומציה היא חלק בלתי נפרד מתהליך הבדיקות היום.
עתיד האוטומציה הוא ברור לגמרי ובמילים פשוטות בכל מקום שאפשר להכניס אוטומציה…יכניסו אוטומציה.
לא בגלל שזה buzzword אלה בגלל שיש צורך אמיתי.
ועכשיו,
השאלה העיקרית היא איך מנהלים את התהליך הזה בצורה נכונה, ואיזה החלטות לקחת בתור מנהל QA.
מניסיוני,
צורת הניהול של תהליך מלא וכתיבת אוטומציה על ידי הבודקים (אוטומטורים)
היא הדרך היחידה בה אפשר לנהל את התהליך לאורך זמן
ובוא בזמן לשמר את אנשי הבדיקות בתוך החברה.
עובדים שירגישו שהם דורכים במקום, במוקדם או במאוחר יפזלו לצדדים.
הם יתחילו לחפש את השלב הבא בקריירה שלהם, אם לא תעזרו להם להיכנס פנימה לתוך בדיקות אוטומציה.
ולכן הרחבת יכולות פיתוח האוטומציה של הבודקים יכולה להיות הדרך הטובה ביותר לשמר את העובדים ולגרום להצלחת ה-QA.
בתור מנהל QA, הדבר הכי חשוב שתמיד עמד לנגד עיניי = זה שימור האנשים האיכותיים שאיתי.
ברגע שלאנשים בצוות הבדיקות יש עניין בעבודה, אתגרים אישיים והרגשת שותפות בתהליך ובעשייה.
וכמו כן ברגע שהם מקבלים את ההערכה הנכונה,
אז…
החברה זוכה באנשי בדיקות איכותיים וטובים יותר,
גם תהליך הניהול והבדיקות הוא פשוט יותר,
גם שימור הידע נעשה בצורה טובה יותר,
וגם האנשים מרוצים יותר.
בדרך זו אנשי ה-QA נשארים לאורך זמן בתוך החברה, וגם איכות המוצרים עולה.
win-win אמרתי כבר, לא? 🙂
מה איתכם מנהלים?
איך אתם מסתכלים על העובדים שלכם? בתור פועלים? או בתור אנשים שחשוב לקדם ולדאוג לקידום המקצועי שלהם בנוסף למשימות של החברה?
מה איתך איש בודק ידני?
אם המנהלים שלך עדיין לא השכילו שחלק מההצלחה של החברה זה גם הקידום שלך,
אז אני ממליץ לך ללדאוג לקידום שלך לבד, כי כנראה שאף אחד לא ידאג לך.
מרגיש תקוע ולא מתקדם?
הצטרף עכשיו לקורס אוטומציה בכיתה או קורס אוטומציה אונליין ותוך 3 חודשים בלבד אתה גם יודע לכתוב קוד ואוטומציה.
