#6: התעקשו על כך שהמתכנתים יתקנו כל בעיה שאתם מוצאים

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

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

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

למה זה רעיון נפלא?

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

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

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

#7: שימרו את הטוב ביותר לסוף

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

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

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

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

למה מתכנתים שונאים את זה?

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

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

 

#8: תקחו תפקיד של שומר ראש

הנה מה שבודק תוכנה עושה בתפקיד שומר ראש:

"אם המתכנת לא מקבל 'אישור' ממך, הבילד לא משוחרר"

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

הנה דבר אחד שתוכלו לעשות:

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

מדוע מתכנתים שונאים את זה?

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

#9: תכתבו מלא באגים כפולים

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

איך תעשו את זה?

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

למה?

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

#10: תציקו להם בזמן שהם כותבים קוד

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

למה זה יכול לשגע מתכנתים?

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

לסיכום

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

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

לחלק הראשון של המאמר:  

בודקי תוכנה? 10 דרכים לגרום למתכנתים לשנוא אתכם יותר (חלק 1)

המדריך המלא לבודק התוכנה המתחיל

ב-QA Experts כתבנו את המדריך המקיף בארץ למעוניינים ללמוד בדיקות תוכנה
52 עמודים עם כל האינפורמציה שתצטרכו 
+בונוס!
מדריך מפורט אודות צבירת ניסיון ועבודה כבודק תוכנה עצמאי

רוצה לקבל את המדריך?

דילוג לתוכן