יום שלישי, 25 במרץ 2008

תכולת בדיקות הרגרסיה בגרסה


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

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

מה עושים?
מתכננים היטב את סוגי הרגרסיות שיש להריץ.

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

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

#
Feature
Build
Regression name
Time (d)
1
הוספה של פורמט SMIL
1
פורמטים,
2
שליחת מיילים,
4
שילוב מדיות
1
ועוד....

2
שיפור טיפול בדואר זבל
2
דואר זבל,
5
שליחת מיילים
4
עיבוד דואר נכנס
2
ועוד...

איור מס' 1

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

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

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

4. קביעת הרגרסיות פר סבב (cycle):
לאחר שלב שלש יש לנו רשימה מעודכנת של איור מס' 1. כעת יש להריץ את הרגרסיות כך:
אם יש רגרסיה בשל פיצ'ר אחד בלבד - יש להריץ אותה ב-build שבו הפיצ'ר נכנס.
לגבי רגרסיות שיש להריץ בשל מס' פיצ'רים - יש לנסות להריץ כאשר כל הפיצ'רים הוכנסו, כלומר לא להריץ אותה ב-build 1, 3 ו-4 אלא ב-4 בלבד. אבל, לעתים עדיף להריץ פעמיים - אם הרגרסיה X ב-build ראשון היא בשל פיצ'ר מרכזי, אבל לפי הטבלא יש להריץ אותה ב-build האחרון עדיין כשאי להריץ אותה לפני בכדי לא לגלות בסוף שאולי כל הפיתוחים החדשים עובדים, אבל האפליקציה מתרסקת בכל פעם שפותחים פיצ'ר קיים מרכזי.
יש להכין טבלא בדומה לזו למעלה כאשר העמודה הראשונה היא ה-build ואח"כ הרגרסיות הרלוונטיות.

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

יום ראשון, 23 במרץ 2008

ניהול סיכוני בדיקה או תוכנה

ניהול סיכונים קיים בכמה רמות:
  1. ניהול סיכונים לפרוייקט. כלומר: האם כח האדם מספיק בכדי לעמוד בזמנים, האם יש לבודקים את הידע המתאין וכו'.
  2. ניהול סיכוני בדיקה. מה הסיכון בפיצ'רים החדשים וכד'.
ניהול סיכונים צריך להתחיל ברמת ה-SysRD.
על כל פיצ'ר שעולה שם יש לתת ציון מבחינת הסיכון.
יש שני קריטריונים:
  1. הסבירות שבעייה תתגלה. הציון: מ-1 עד 5, כאשר 1 הוא שאין סבירות, 5 - כמעט בוודאות.
  2. דרגת החומרה שהבעייה עלולה להגיע אליה. הציון: מ-1 עד 5, כאשר 1 הוא שאין חומרה, 5 - המערכת או הפיצ'ר לא יתפקדו.
למשל אם אנו מפתחים מעבד תמלילים והחלטנו להוסיף לו פיצ'ר חדש: שמירה אוטומאטית.
הביצוע הוא קל - בסה"כ פונקציית שממתינה 5 ד' (או כל פרק זמן) ושומרת את המידע. הסבירות לבעייה הוא 1 או 2 (תלוי באפשרויות הקיימות למשתמש).
אבל פיצ'ר כזה הוא קריטי ברמה שאם הוא לא יעבוד, והמשתמש לא ידע על כך, מישהו עלול לאבד מידע חשוב ולתבוע אותנו. לכן החומרה היא 4.
עכשיו מכפילים וזה יוצא 8 במרחב של מ-1 עד 25.
מה שמאוד חשוב להבין שזה כלי עזר, לא מדוייק מתימטית. לכן צריך גם להסתכל בתוצאה ולראות שזה עושה שכל, ואם אתם לא שלמים איתה אתם יכולים לשנות.
מצד שני זה כן חשוב כיוון שקודם כל זה ברמה מודעת, דבר שני זה בכל זאת נותן כלי טוב למדידת הסיכון.
ומה עושים עם התוצאות?
  1. אם יש קבלה ושיתוף בפיתוח הוא יאמץ את המדדים הללו (או טוב יותר - יהיה שותף מלא) וישים לב לפיצ'רים הבעייתיים במובן של code analysis, unit testing וכד'.
  2. להתחיל בכתיבה וביצוע של בדיקות לפי מדדי הסיכון.
  3. לשים לב במיוחד למקרי הקצה בבדיקות.
  4. לתת להן את הזמן הראוי.
  5. אולי לתת לבודק מנוסה יותר לבדוק.
  6. אולי יהיה מקום ליותר בדיקות רגרסיביות.
את הערכת זמן הבדיקות יש לחלק לשלוש:
  1. בדיקה של הקריטי (נניח ציון מ-16 עד 25)
  2. בדיקה של ה-medium (נניח ציון מ-8 עד 15)
  3. בדיקה של ה-low (נניח ציון מ-1 עד 7)
ואז ניתן לומר: להבטיח שאין באגים קריטיים יקח לי 5 ימים לצורך הדוגמא, בינוניים 3 ונמוכים שניים.
דבר אחד חשוב יש לזכור: לפעמים אפשר לטעות ולא לצפות לכל הבאגים. לכן עדיף להשלים מחזור בדיקות הכולל את המוגדרות כביינוניות.
בנוסף, ייתכן שלאחר זמן בדיקות מסויים נקבל ביטחון בגרסה וניתן יהיה אף להוריד מספר מסויים של בדיקות.

יום שלישי, 18 במרץ 2008

כמה עצות למראיינים

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

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

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

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

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

אח"כ (ולא בסוף) - שתי מילים על התהליך.

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

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

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

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

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

לבסוף, תמיד לקחת ממליצים.

רשומות פופולריות