בגוגל הבדיקות שייכות לארגון שנקרא Engineering Productivity. אני מניח שהכוונה היא ברמת ההצהרה, שכמו באג'ייל הבדיקות נועדו לתמוך בפיתוח. ב"תמיכה בפיתוח" הכוונה היא שהבדיקות נכנסות משלב אפס פחות-או-יותר ונותנות משוב מהיר בזמן אמת. זה תומך בפיתוח כיוון שזה מגלה בעיות בשלב מוקדם מאוד ולא אחרי כמה ימים או שבועות אחרי תהליך "ווטרפולי" ארוך. כמו באג'ייל גם כאן האחריות על האיכות היא אצל כולם, מה ששונה בגוגל להבנתי הוא שהאיכות היא בעיקר עניין של המפתחים. אם למשל יש בעיה ב-production, פונים למפתח לקבלת דין וחשבון, לא לבודק. ולכן המהנדסים של גוגל (לפחות בתיאוריה) מעדיפים איכות על פני פיצ'רים. הבדיקות והפיתוח הולכות יד ביד. קצת מפתחים, קצת בודקים, עוד קצת מפתחים, עוד קצת בודקים. האיכות, לתפיסת עולמם, היא עניין של מניעה יותר מאשר גילוי והבדיקות הן לוודא שהמניעה עבדה.
תפקידי הפיתוח העיקריים בגוגל הם:
Software Engineer - SWE – כלומר מפתח.
Software Engineer in Test - SET – מפתח שאחראי על הטסטביליות והתשתיות של הבדיקות. הם מפתחים framework לאוטומציה ול-unit tests ומפתחים אוטומציה, דברים שעוזרים למפתח לבדוק את הקוד שלו.
Test Engineer - TE – בניגוד ל-SET מהנדס הבדיקות שם לנגד עיניו את משתמש הקצה ורק אח"כ את המפתחים. הוא לוקח את המוצר השלם ומוצרים שעובדים אתו ביחד ובודק אם המשתמש מקבל את הערך שהוא אמור לקבל. תפקידו אינו למצוא בשלב זה באגים פשוטים – אלה היו אמורים להימצא לפני כן – אלא לבדוק האם הביצועים טובים, האם המוצר מאובטח, בינלאומי, נגיש וכד'.
בגוגל המבנה האירגוני מחולק ל-Focus Area, למשל קליינט (כרום וכד'), פרסומות, גאו (מפות למשל), מובייל וכד'. הבדיקות אינן חלק אינטגרלי מקבוצות אלה. ה-TE מושאלים לקבוצות השונות בהתאם לחשיבות, מורכבות וצרכי הקבוצה והם עוברים מקבוצה לקבוצה בערך כל שנה וחצי (אם הם רוצים). כך שרעיונות טובים מופצים בחברה. אני מניח שכך מונעים "הזדהות" גדולה מידי בין הבודק למפתחים.
סוגי הבדיקות הם:
Small Tests – בד"כ הבדיקות הללו הן אוטומטיות ובודקות פונקציה או מודול (כלומר Unit Test) ונכתבות בעיקר ע"י המפתחים. בד"כ מצריכים מוקים וסביבות לא אמתיות. הבדיקות אמורות לענות לשאלה: האם הקוד עושה את מה שהוא אמור לעשות?
Medium Tests – בד"כ בדיקות אוטומטיות של שני פיצ'רים או יותר (כלומר בדיקות אינטגרציה). הפוקוס הוא על האינטראקציה ביניהם. הם נקראים פונקציות מהסביבה הקרובה. בהמשך תהליך הפיתוח גם ה-TE יכולים להריץ בדיקות אלה אן ידנית (במקרה שקשה או לא שווה להפוך לאוטומטי) או בהרצה של אוטומציה. הבדיקות אמורות לענות לשאלה: האם סט של פונקציות מהסביבה הקרובה עובדות האחת עם השנייה בדרך בה הן אמורות לעבוד?
Large Tests – מכסות שלוש אך בעיקר יותר פיצ'רים ומדמות משתמש קצה (בדיקות מערכת): תרחישים של משתמשים, דטה של משתמשים ולוקחים שעות או יותר להריץ. הבדיקות אמורות לענות לשאלה: האם המוצר מתפקד בדרך לה המשתמש מצפה והוא מייצר את התוצאות המצופות?
למרות ההעדפה הברורה של גוגל שמה שאפשר יהיה אוטומטי, בסופו של יום רוב הבדיקות בגוגל הן ידניות, בין אם סקריפטד או אקספלורטורי.
היחס בין סוגי הבדיקות:
כלל האצבע הוא: 70% בדיקות קטנות, 20% בדיקות בינוניות ו-10% בדיקות גדולות. לא ברור לי איך הם מכמתים את המספר (Test cases? Run Time?) אבל הכיוון ברור. בהרבה מהמקומות שאני מכיר המצב אינו כזה, והוא נא מבדיקות ידניות בלבד עד לאיזה ערבוב של מעט בדיקות אוטומטיות, מעט Unit Test והרבה ידני.
איך בודקים תוכנה בגוגל: תפקידים ובדיקותאיך בודקים תוכנה בגוגל: תפקידים ובדיקות
לחלק השני של המאמר לחץ כאן.
אין תגובות:
הוסף רשומת תגובה