מי אחראי לאיכות?

היי הבר!

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

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

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

- נסטיה שלום. בבקשה ספר לנו לגביך.

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

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

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

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

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

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

ברוב המקרים, הם מוגבלים רק לבדיקות פונקציונליות: הם בודקים שמה שהמפתחים קודדו תואם את המפרט וזהו.

- אנא ספר לנו אילו עוד תחומי אבטחת איכות יש? מה עוד, מלבד בדיקות, זה כולל?

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

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

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

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

— מסתבר שהאיכות מצטלבת עם כמעט כל הדיסציפלינות שמסביב, וכופה מסגרת על כל מה שמסביב?

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

זה המקום שבו סוג זה של בדיקות נכנס לתמונה: UAT (בדיקות קבלת משתמש). למרבה הצער, זה מתורגל רק לעתים רחוקות ברוסיה, אבל לפעמים נוכח בצוותי SCRUM כהדגמה ללקוח הקצה. זהו סוג בדיקה נפוץ למדי בחברות זרות. לפני פתיחת הפונקציונליות לכל הלקוחות, אנחנו קודם כל עושים UAT, כלומר, אנחנו מזמינים את משתמש הקצה שבודק ומיד נותן משוב - האם המוצר באמת עומד בציפיות ופותר את הכאב. רק לאחר מכן מתרחשת קנה מידה לכל שאר הלקוחות.

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

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

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

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

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

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

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

זה מעלה את השאלה - אולי הצוות צריך להשתמש בתשתית כקוד.

אני מאמין שתשתיות משפיעות ישירות על איכות המוצר.

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

- מה לגבי ניתוח ותיעוד?

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

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

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

מפתחים אינם מזיקים ואינם כותבים קוד עם שגיאות בכוונה.

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

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

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

- מה לגבי בדיקות שמישות, שמישות מוצר, עיצוב?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

- האם אתה מתכנן לגעת ישירות בנושאים על בדיקות וכלים?

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

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

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

— מי יעניין במה אתה מדבר, במי אתה רואה כאורחי הכנס?

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

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

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

- האם אתה חושב שהתעשייה כולה בשלה לדבר לא רק על בדיקות, אלא על תרבות של איכות?

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

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

- מוסכם! ננחיל תרבות ונשנה תודעה.

כנס לפיתוח איכותי של מוצרי IT QualityConf מתרחש במוסקבה ב-7 ביוני. אתה יודע אילו שלבים מרכיבים מוצר באיכות גבוהה, יש לנו מקרים של מאבק בהצלחה בבאגים בייצור, בדקנו שיטות פופולריות בפרקטיקה שלנו - אנחנו צריכים את הניסיון שלך. לִשְׁלוֹחַ שלהם בקשות לפני 1 במאי, וועדת התכנית תסייע במיקוד הנושא לשלמות הכללית של הכנס.

להתחבר ל לְשׂוֹחֵחַ, שבו אנו דנים בנושאי איכות והכנס, מנוי ערוץ טלגרםכדי להישאר מעודכן בחדשות התוכנית.

מקור: www.habr.com