קיו איי כמנגנון בקרה על הדיזיין

[אוגיטוס]

קיו איי כמנגנון בקרה על הדיזיין

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

 

[עמית ו]

יש לך את זה בעברית?

לא בטוח שהבנתי מה הנושא - האם מדובר על העיצוב הגרפי? על החלטות של עיצוב תוכנה (שלפעמים שמורות לארכיטקטים ולפעמים למפתחים עצמם)?
אני גם לא בטוח שהבנתי את הבעיה? מה זאת אומרת "לחלק את האחריות"?

 

[halperin]

האיכות - באחריות כולם... אחרת מבזבזים אנרגייה

 

[אוגיטוס]

אני אחדד

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

 

[Issi Hazan]

יש מנעד רחב של אפשרויות

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

 

[אוגיטוס]

תודה

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

 

[halperin]

הבסיס מאחורי המונח V&V ...

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

 

[halperin]

ואגב - מתי הכי נפוץ להחזיר משוב לדרישות?

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

 

[עמית ו]

מה הציפייה שלך?

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

 

[אוגיטוס]

מובן ומקובל

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

 

[smadji]

מה קורה אצלנו...

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

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

 

[אוגיטוס]

תודה. בהחלט ממחיש לי.