אתה משתמש בדפדפן מיושן. יתכן והאתר הנוכחי יוצג באופן שגוי, כמו כן אתרים אחרים ברשת.
אנא שדרג את הדפדפן או השתמש בדפדפן חילופי.
אנא שדרג את הדפדפן או השתמש בדפדפן חילופי.
Manual Testing Covrage
- פותח הנושא yd38
- פורסם בתאריך
כיסוי ביחס למה?
משהו שמייקל בולטון חוזר עליו שוב ושוב (בצדק) הוא ש"כיסוי" זה מונח שלא עומד בפני עצמו - זה תמיד כיסוי של משהו - של שורות קוד, של דרישות, של סיכונים, של פיצ'רים, של דברים שתכננו לבדוק.
כל אחד מאלה דורש היערכות שונה. כיסוי קוד כנראה ידרוש גרסה מיוחדת של האפליקציה (למשל, כזה: https://blogs.msdn.microsoft.com/marcalt/2006/07/02/using-code-coverage-with-manual-testing/ ), כיסוי דרישות יצריך דרישות כתובות ומפורטות מספיק, עם קישור של תסריטי בדיקות (לפחות ברמת הכותרת), ואז כלי ניהול הבדיקות השונים באמת זורחים (אני אפילו יכול לומר שQC הידוע לשמצה עושה עבודה נהדרת בתצורה כזו).
אם אנחנו רוצים למדוד כיסוי סיכונים, אז כדאי שתהיה לנו רשימת סיכונים שיש לידה מקום בו אנחנו יכולים לסמן הערכה של כמה מהסיכון הזה כיסינו (אפשר לכסות סיכון באופן חלקי), ואם אנחנו רוצים לראות כיסוי מהתכנון - כדאי שיהיה לנו תכנון, ואז יש מגוון רחב של כלים שיודעים לתת לנו burndown.
 
כמובן, קישור למה שמייקל בולטון אומר: http://www.developsense.com/blog/2016/04/100-coverage-is-possible/
 
עכשיו, לשאלה החשובה באמת - למה אתם רוצים למדוד כיסוי בדיקות? אני לא אומר שזה רעיון רע, אבל המטרה שלכם תשפיע על סוג הכיסוי שאתם רוצים למדוד ועל מידת המאמץ שאתם רוצים להשקיע במדידה של זה.
משהו שמייקל בולטון חוזר עליו שוב ושוב (בצדק) הוא ש"כיסוי" זה מונח שלא עומד בפני עצמו - זה תמיד כיסוי של משהו - של שורות קוד, של דרישות, של סיכונים, של פיצ'רים, של דברים שתכננו לבדוק.
כל אחד מאלה דורש היערכות שונה. כיסוי קוד כנראה ידרוש גרסה מיוחדת של האפליקציה (למשל, כזה: https://blogs.msdn.microsoft.com/marcalt/2006/07/02/using-code-coverage-with-manual-testing/ ), כיסוי דרישות יצריך דרישות כתובות ומפורטות מספיק, עם קישור של תסריטי בדיקות (לפחות ברמת הכותרת), ואז כלי ניהול הבדיקות השונים באמת זורחים (אני אפילו יכול לומר שQC הידוע לשמצה עושה עבודה נהדרת בתצורה כזו).
אם אנחנו רוצים למדוד כיסוי סיכונים, אז כדאי שתהיה לנו רשימת סיכונים שיש לידה מקום בו אנחנו יכולים לסמן הערכה של כמה מהסיכון הזה כיסינו (אפשר לכסות סיכון באופן חלקי), ואם אנחנו רוצים לראות כיסוי מהתכנון - כדאי שיהיה לנו תכנון, ואז יש מגוון רחב של כלים שיודעים לתת לנו burndown.
 
כמובן, קישור למה שמייקל בולטון אומר: http://www.developsense.com/blog/2016/04/100-coverage-is-possible/
 
עכשיו, לשאלה החשובה באמת - למה אתם רוצים למדוד כיסוי בדיקות? אני לא אומר שזה רעיון רע, אבל המטרה שלכם תשפיע על סוג הכיסוי שאתם רוצים למדוד ועל מידת המאמץ שאתם רוצים להשקיע במדידה של זה.
כיסוי בדיקות
היי עמית,
המטרה שלנו היא לכתוב מסמכי בדיקות ידניים ולקבוע להם עדיפות מה הולך להיכתב באוטומציה ומה יבדק רק ידנית ולנסות לתת סוג של הערכה כמה מתוך כל הטסטים שנכתבו רצו ועברו וכמה נפלו.
מבחינת האיכות הכוללת אנחנו מנסים להבין ולהעריך את איכות הבדיקות בצוות ולנסות ולבדוק פרמטרים נוספים למדידת איכות
היי עמית,
המטרה שלנו היא לכתוב מסמכי בדיקות ידניים ולקבוע להם עדיפות מה הולך להיכתב באוטומציה ומה יבדק רק ידנית ולנסות לתת סוג של הערכה כמה מתוך כל הטסטים שנכתבו רצו ועברו וכמה נפלו.
מבחינת האיכות הכוללת אנחנו מנסים להבין ולהעריך את איכות הבדיקות בצוות ולנסות ולבדוק פרמטרים נוספים למדידת איכות
אוטומציה לתהליכים
לדעתי במקום לעבור על כל הבדיקות הידניות שנבדקו ובכך לתעדף מה לבצע אוטומציה עבורם. תעברו על המערכת עצמה, על מסמכי האפיון והצורך של לקוחות הקצה.
אצלנו בחברה אנחנו נבצעים אוטומציה לתהליכים גדולים של כלל המערכת וגם תהליכים קטנים יותר של המערכת (למשל: כניסה לאתר, חיפוש מוצר, הוספה לעגלה, ביצוע צ'קאאוט, ביצוע רכישה = תהליך אחד).
 
ולגבי הערכה של טסטים ואיכות הבדיקות, זה נכלל בתוך ה-STR - Software test result, כלומר: תוצאות של סך הבדיקות לאותה איטרציה/תקופה שהגדתרם. ניתן לבצע סיכום בצורה של טבלאות של סך הבדיקות עבור פרמטרים הבאים: כמות בדיקות שבוצעו לעומת כמה בדיקות נכשלו או עברו. וכל מיני כאלה.
 
לדעתי במקום לעבור על כל הבדיקות הידניות שנבדקו ובכך לתעדף מה לבצע אוטומציה עבורם. תעברו על המערכת עצמה, על מסמכי האפיון והצורך של לקוחות הקצה.
אצלנו בחברה אנחנו נבצעים אוטומציה לתהליכים גדולים של כלל המערכת וגם תהליכים קטנים יותר של המערכת (למשל: כניסה לאתר, חיפוש מוצר, הוספה לעגלה, ביצוע צ'קאאוט, ביצוע רכישה = תהליך אחד).
 
ולגבי הערכה של טסטים ואיכות הבדיקות, זה נכלל בתוך ה-STR - Software test result, כלומר: תוצאות של סך הבדיקות לאותה איטרציה/תקופה שהגדתרם. ניתן לבצע סיכום בצורה של טבלאות של סך הבדיקות עבור פרמטרים הבאים: כמות בדיקות שבוצעו לעומת כמה בדיקות נכשלו או עברו. וכל מיני כאלה.
 
אז נראה אם הבנתי...
1. אתם רוצים להגדיר מה ייבדק באופן אוטומטי, ומה באופן אינטראקטיבי.
2. לשם כך, אתם רוצים לסקור את תסריטי הבדיקה שכתובים אצלכם ולהחליט "מה עובר לאוטומציה ומה לא".
3. בלי קשר לכל זה, אתם מנסים לשפר את מאמץ הבדיקות הכולל שלכם.
 
האם הבנתי נכון?
 
אם כן, אני לא בטוח ש"כיסוי" הוא המדד הכי אפקטיבי לסעיפים 1+2. נראה לי קל (ויעיל) יותר לעבור על הרשימה שיש לכם ולשאול על כל תסריט שתי שאלות: "כמה קשה לכתוב תסריט אוטומטי שייתן ערך דומה?" "כמה חשוב לי להריץ את הבדיקה הזו שוב ושוב ושוב?", בעזרת שני המספרים האלה אפשר להגיע לתשובה מהירה יחסית של "למה הולכים לכתוב אוטומציה קודם" (בגדול, ככל שחשוב לנו יותר להריץ את הבדיקה שוב ושוב ישתלם יותר לכתוב תסריט אוטומטי, ככל שקל יותר לכתוב תסריט אוטומטי, כך יש פחות מה להתלבט אם לכתוב אחד כזה או לא).
הערה קטנה לסדר - אני בכוונה לא אומר "נמיר לאוטומטי" כי מבדק אוטומטי שמשחזר פעולות משתמש אנושי זה בדרך כלל לא הרעיון הכי טוב שיש - חלק גדול מהדאגות אפשר לפתור ברמת בדיקות היחידה, וגם מבדקי מערכת עדיין עדיף לכתוב קצת אחרת כי מכונות ואנשים פועלים בצורה שונה. בגדול, אם החלטנו שמשהו מצדיק כתיבה מחדש באופן אוטומטי, הצעד הראשון יהיה לחלץ "מה בעצם אנחנו בודקים כאן" (או מה חשוב לנו לבדוק כאן) ואז למצוא דרך נורמלית לעשות את זה בעזרת קוד.
 
לגבי הנקודה השלישית - למה אכפת לכם מאיכות הבדיקות? האם יש בעיה עם המוצר שלדעתכם נגרמת כתוצאה מבדיקות לא טובות מספיק? אם כן, יש לכם כנראה רמז לא רע בכלל למה בבדיקות צריך לשפר (כי אחרת, איך אתם יודעים שהבעיה במוצר נגרמת כתוצאה מבעיה בתהליך הבדיקות?). אם לא: עדיף להשקיע את המאמץ במדידת דברים שמשנים למוצר: כמה זמן עובר בין הגדרת פיצ'ר עד שהוא מגיע ללקוח? כמה זמן מושקע בתמיכה בבאגים מלקוחות? כמה קל לנו לשחרר תוכן חדש? האם התוכן שאנחנו משחררים מפיק ערך עסקי לחברה? איך אפשר לשפר חלק מהפרמטרים האלה? שיפור של הפרמטרים האלה יכול להיות שיפור גם בחלק של הבדיקות, אבל כך זה משהו שכל הצוות עושה ולא רע בעיה של הבודקים (למשל - כדי לשחרר תוכן מהר יותר, אנחנו יכולים לרצות בדיקה אוטומטית שרצה מהר ונותנת לנו מידת ביטחון מסויימת במהירות, כדי להימנע מהפתעות ביצועים של המוצר, אנחנו רוצים אולי להתחיל להכניס בדיקות ביצועים לתהליך שלנו, וכו'). כשהמטרה היא מטרה עסקית של המוצר, קל יותר לרתום אליה את כל הצוות, וקל יותר לקבל תקציב מההנהלה כדי לטפל במה שצריך.
1. אתם רוצים להגדיר מה ייבדק באופן אוטומטי, ומה באופן אינטראקטיבי.
2. לשם כך, אתם רוצים לסקור את תסריטי הבדיקה שכתובים אצלכם ולהחליט "מה עובר לאוטומציה ומה לא".
3. בלי קשר לכל זה, אתם מנסים לשפר את מאמץ הבדיקות הכולל שלכם.
 
האם הבנתי נכון?
 
אם כן, אני לא בטוח ש"כיסוי" הוא המדד הכי אפקטיבי לסעיפים 1+2. נראה לי קל (ויעיל) יותר לעבור על הרשימה שיש לכם ולשאול על כל תסריט שתי שאלות: "כמה קשה לכתוב תסריט אוטומטי שייתן ערך דומה?" "כמה חשוב לי להריץ את הבדיקה הזו שוב ושוב ושוב?", בעזרת שני המספרים האלה אפשר להגיע לתשובה מהירה יחסית של "למה הולכים לכתוב אוטומציה קודם" (בגדול, ככל שחשוב לנו יותר להריץ את הבדיקה שוב ושוב ישתלם יותר לכתוב תסריט אוטומטי, ככל שקל יותר לכתוב תסריט אוטומטי, כך יש פחות מה להתלבט אם לכתוב אחד כזה או לא).
הערה קטנה לסדר - אני בכוונה לא אומר "נמיר לאוטומטי" כי מבדק אוטומטי שמשחזר פעולות משתמש אנושי זה בדרך כלל לא הרעיון הכי טוב שיש - חלק גדול מהדאגות אפשר לפתור ברמת בדיקות היחידה, וגם מבדקי מערכת עדיין עדיף לכתוב קצת אחרת כי מכונות ואנשים פועלים בצורה שונה. בגדול, אם החלטנו שמשהו מצדיק כתיבה מחדש באופן אוטומטי, הצעד הראשון יהיה לחלץ "מה בעצם אנחנו בודקים כאן" (או מה חשוב לנו לבדוק כאן) ואז למצוא דרך נורמלית לעשות את זה בעזרת קוד.
 
לגבי הנקודה השלישית - למה אכפת לכם מאיכות הבדיקות? האם יש בעיה עם המוצר שלדעתכם נגרמת כתוצאה מבדיקות לא טובות מספיק? אם כן, יש לכם כנראה רמז לא רע בכלל למה בבדיקות צריך לשפר (כי אחרת, איך אתם יודעים שהבעיה במוצר נגרמת כתוצאה מבעיה בתהליך הבדיקות?). אם לא: עדיף להשקיע את המאמץ במדידת דברים שמשנים למוצר: כמה זמן עובר בין הגדרת פיצ'ר עד שהוא מגיע ללקוח? כמה זמן מושקע בתמיכה בבאגים מלקוחות? כמה קל לנו לשחרר תוכן חדש? האם התוכן שאנחנו משחררים מפיק ערך עסקי לחברה? איך אפשר לשפר חלק מהפרמטרים האלה? שיפור של הפרמטרים האלה יכול להיות שיפור גם בחלק של הבדיקות, אבל כך זה משהו שכל הצוות עושה ולא רע בעיה של הבודקים (למשל - כדי לשחרר תוכן מהר יותר, אנחנו יכולים לרצות בדיקה אוטומטית שרצה מהר ונותנת לנו מידת ביטחון מסויימת במהירות, כדי להימנע מהפתעות ביצועים של המוצר, אנחנו רוצים אולי להתחיל להכניס בדיקות ביצועים לתהליך שלנו, וכו'). כשהמטרה היא מטרה עסקית של המוצר, קל יותר לרתום אליה את כל הצוות, וקל יותר לקבל תקציב מההנהלה כדי לטפל במה שצריך.
Copyright©1996-2021,Tapuz Media Ltd. Forum software by XenForo® © 2010-2020 XenForo Ltd.