"באג בהבנה" - סקירה אפיונית (review) כחלק מתהליך הבדיקות

"באג בהבנה" - סקירה אפיונית (review) כחלק מתהליך הבדיקות.

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

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

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

בארגונים בהם אני עבדתי, שום אפיון, Change Request, User Story, לא עובר לפיתוח בלי אישורו של הבודק האחראי על הפרויקט, המהווה בורג מרכזי ב life cycle של המוצר.

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

מדוע הבודק נדרש לסקור אפיונים?

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

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

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

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

"אילו הייתי שואל אנשים מה הם צריכים – הם היו עונים לי סוסים מהירים יותר"...

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

יישור קו בין כל המעורבים (ובפרט לוודא כי גם המפתח הבין את דרישות המשימה).

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

בדיקת האפיון:

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

אז איך זה מתבצע?

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

"יש להקים Tab בעמוד הראשי – עם הכותרת "צור קשר". בלחיצה על הטאב יפתח עמוד חדש, בו כל משתמש הרשום באתר יוכל למלא את שמו וכתובת מייל לחזרה.

יש להקים Drop Down שיכיל את נושא הפניה ממנו יוכל לבחור המשתמש.

מתחתיו יוכל היוזר להזין טקסט חופשי ב Text Box  בשם "הזן את פנייתך", ולהעלות קובץ בפורמט PDF.

מתחת ל Text Box יש להוסיף כפתור שליחה והודעת אישור כאשר הקובץ וההודעה ישלחו למערכות החברה."

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

●        מה יוצג למשתמש שאיננו רשום באתר בלחיצה על הטאב החדש?

●        מהו פורמט השדות?

●        האם כדאי לממש ולידציה שתבדוק את תקינות פורמט המייל?

●        מהם הערכים שיכיל ה Drop Down?

●        האם לכל משתמש (לכל הרשאה) יוצגו אותם הערכים? אם לא - מהיא השליפה שיש להציג לכל הרשאה או שילוב הרשאות?

●        האם כל השדות זמינים תמיד? אם לא- מהו הטריגר לנעילתם?

●        האם יש הגבלת תווים על השדה טקסט? (אם כן מהי ההגבלה?)

●        מה אמור לקרות כאשר המשתמש ינסה להעלות קובץ בפורמט שונה מ PDF?

●        האם מאופיינות הודעות שגיאה? (כולל מלל וטריגר להקפצת ההודעה)

●        האם כדאי להגדיר הגבלה על גודל הקובץ?

●        כיצד ניתן להסיר\למחוק את הקובץ במקרב שהמשתמש התחרט?

●        האם יש לאפשר טעינה של יותר מקובץ אחד?

●        האם כפתור שליחה זמין תמיד? אם לא- מהו הטריגר להפיכתו לזמין?

●        האם יתבצע איפוס\ניקוי לשדות לאחר השליחה?

●        לאיזה מסך יחזור המשתמש לאחר השליחה?

●        מה יקרה אם השליחה נכשלה?

●        האם ישנם שדות חובה למילוי? אם כן מהם ומה אמור לקרות כאשר נלחץ על שליחה מבלי שהם מולאו? (הדגשת שדות? הודעות קופצות?)

●        אם צורף צילום מסך - האם הוא נראה לנו "נכון" לביצוע?

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

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

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

טיפים ודגשים נוספים לסקירות אפיון: 

●        האם הוא כתוב כך שאם מי שיפתח לא מכיר את הפרויקט יוכל לבצע את המשימה?

●        האם יש תיאור של מצב קיים לעומת מצב נדרש?

●        שינויים תשתיתיים שישפיעו על פיתוחים אחרים.

●        האם יש התייחסות להרשאות?

●        האם יש flow ברור עבור כל "שחקן" שאמור להשתמש במערכת?

●        האם כל השדות מאופיינים? (שמות, הגבלת תווים, פורמט, גודל מקסימלי)

●        אם קיימים נתונים להצגה לפי שליפה מ DB – האם השליפה זהה לכולם? מהי השליפה עבור כל הרשאה?

●        האם יש התייחסות לתגובות המערכת במקרה של סטייה מה Flow התקין? (בפורמט אפיון מונחה קל יותר לראות את החוסרים הנ"ל).

●        האם ברור מהו הטריגר שאמור לגרור פעולה עוקבת?

●        שדות חובה.

●        התייחסות לזמינות שדות Enabled & Disabled והטריגר לנעילתם\פתיחתם.

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

●        אם יש צילומי מסך – האם הם תואמים את המאופיין\הקיים?

●        האם מאופיינות הודעות שגיאה? (כולל מלל וטריגר להקפצת ההודעה)

●        לא להתבייש להתעקש - התעקשות על דקויות (כגון דרישה להגבלה מסוימת על שדה "מחיר" כשבמסך קיימים גם "מחיר לפני הנחה" וגם "מחיר אחרי הנחה") יכולה לחסוך דיונים מיותרים ובבזבוז זמן בהמשך.

אני מקווה שהמאמר יעזור מעט לאלו מכם שיצטרכו לסקור אפיונים, ואוסיף על כל מה שנאמר שחשוב מאוד שהתקשורת בינינו הבודקים לבין סביבת העבודה שלנו בין אם זה הפיתוח או צוות הפרויקטים, תהיה אדיבה ומתחשבת. בסופו של דבר כולנו שותפים לאותה מטרה וקצת התחשבות והבנה של הצד השני Can go a long way