הבעיה הבסיסית של בדיקות

מבוא

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

• GOST 7400-81. קומקומים חשמליים ביתיים וסמוברים חשמליים. מפרטים (עם תיקונים מס' 1-8)
• GOST IEC 60335-1-2015 מכשירי חשמל ביתיים ודומיהם. בְּטִיחוּת. חלק 1. דרישות כלליות
  קשה לחשוב על תוכנית בדיקה טובה יותר עם רשימת בדיקה מלאה.

אבל החלק השני התברר כשאלה: "האם יש בעיות משותפות לכל הבודקים שמונעות מהם לעבוד בצורה יעילה יותר?"

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

להגדיר

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

• בעיה
• בּוֹחֵן
• עבודת בוחן
• יעילות בודק

בואו נפנה לויקיפדיה ולשכל הישר:
בְּעָיָה (יוונית עתיקה πρόβλημα) במובן הרחב - סוגיה תיאורטית או מעשית מורכבת הדורשת עיון ופתרון; במדע - מצב סותר המופיע בצורה של עמדות מנוגדות בהסבר של כל תופעה, אובייקט, תהליכים ודורש תיאוריה מספקת כדי לפתור אותה; בחיים, הבעיה מנוסחת בצורה מובנת לאנשים: "אני יודע מה, אני לא יודע איך", כלומר, ידוע מה צריך להשיג, אבל לא ידוע איך לעשות את זה . מגיע מאיחור. La T. בעיה, מיוונית. πρόβλημα "נזרק קדימה, מונח לפנים"; מ-προβάλλω "זרוק קדימה, שים לפניך; אשמה".

זה לא הגיוני, למעשה, "בעיה" = "כל דבר שצריך לטפל בו."
בּוֹחֵן - מומחה (לא נחלק לסוגים, מכיוון שאנו מעוניינים בכל הבודקים) שלוקח חלק בבדיקת רכיב או מערכת, שתוצאתם היא:
עבודת הבוחן - מערך פעילויות הקשורות לבדיקות.
יְעִילוּת (lat. effectivus) - הקשר בין התוצאה שהושגה למשאבים המשמשים (ISO 9000: 2015).
תוֹצָאָה - תוצאה של שרשרת (סדרה) של פעולות (תוצאה) או אירועים, המתבטאים בצורה איכותית או כמותית. התוצאות האפשריות כוללות יתרון, חיסרון, רווח, הפסד, ערך וניצחון.
כמו ב"בעיה", אין משמעות קטנה: משהו שיצא כתוצאה מהעבודה.
משאב - האפשרות הניתנת למדידה כמותית לבצע כל פעילות של אדם או אנשים; תנאים המאפשרים שימוש בטרנספורמציות מסוימות כדי להשיג את התוצאה הרצויה. הבוחן הוא אדם, ובהתאם לתיאוריית המשאבים החיוניים, כל אדם הוא הבעלים של ארבעה נכסים כלכליים:
מזומן (הכנסה) הוא משאב מתחדש;
אנרגיה (כוח חיים) היא משאב מתחדש חלקית;
זמן הוא משאב קבוע ואינו מתחדש ביסודו;
ידע (מידע) הוא משאב מתחדש, הוא חלק מההון האנושי שיכול לגדול ולהיהרס[1].

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

החלטה

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

1. עבודה עם דרישות
2. גיבוש מפרט טכני
3. פיתוח
4. בדיקה
5. שחרור לייצור
6. תמיכה (עבור לפריט 1)

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

איך להתמודד עם זה?

המסקנות ברורות למדי והיו בשימוש על ידי רבים במשך זמן רב:

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

מקור: www.habr.com