LOGIN
התחברות או הרשמה
Avatar
להמשך הרשמה ידנית – לחץ על כפתור ההרשמה, להרשמה/כניסה מהירה בעזרת חשבון רשת חברתית – לחץ על הלוגו בכותרת

אפס סיסמה - שכחתי את שם המשתמש

שם משתמש
סיסמה
זכור אותי

he icon   en icon

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

בדיקות חוקרות ותסריטי בדיקה – משני צדדיו של המטבע

נכתב על ידי 
חמישי, 13 אוקטובר 2016 15:50
דרגו כתבה זו
(8 הצבעות)

בדיקות חוקרות ותסריטי בדיקה – משני צדדיו של המטבע

אתחיל את המאמר הבא מתגובה שרשמתי בפורום בדיקות תוכנה בדיון על חשיבותם של Exploratory Testing בנוסף ל – Scripted:

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

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

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

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

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

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

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

יתרונות בולטים לשיטת ה- Exploratory Testing:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ולסיכום:

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

 

yazitura

 

שונה לאחרונה ב שישי, 14 אוקטובר 2016 11:51

חובה להיות משתמש רשום במערכת בכדי להגיב - ההרשמה/כניסה בכותרת האתר

חדשות מעולם הבדיקות

  • The challenge of prioritizing bugs

    The challenge of prioritizing bugs ...

    20.10.2019 | 11:07 קרא עוד...
  • 92: 9 Steps to Crater Quality & Destroy Customer Satisfaction - Cristian Medina

    Cristian Medina wrote an article recently called "Test Engineering Anti-Patterns: Destroy Your Customer Satisfaction and Crater Your Quality By Using These 9 Easy Organizational Practices" Of course, it's sarcastic, and aims to highlight many problems with organizational practices that reduce software quality. The article doesn't go out of character, and only promotes the anti-patterns. However, in this interview, we discuss each point, and the corollary of what you really should do. At least, our perspectives. Here's the list of all the points discussed in the article and in this episode: Make the Test teams solely responsible for quality Require all tests to be automated before releasing Require 100% code coverage Isolate the Test organization from Development Measure the success of the process, not the product. Metrics, if rewarded, will always be gamed. Require granular projections from engineers Reward quick patching instead of solving Plan for today instead of tomorrow Special Guest: Cristian Medina.Sponsored By: Azure Pipelines: Automate your builds and deployments with pipelines so you spend less time with the nuts and bolts and more time being creative. Many organizations and open source projects are using Azure Pipelines already. Get started for free at azure.com/pipelines Support Test & CodeLinks: Test Engineering Anti-Patterns: Destroy Your Customer Satisfaction and Crater Your Quality By Using These 9 Easy Organizational Practices — The article we discuss in the show. tryexceptpass — Cris's blog

    20.10.2019 | 2:00 קרא עוד...
  • What is a Customer?

    What Is A Customer? In the world of Agile, and the world of business too, we hear a lot about “customer value”. Folks seem to have some kind of handle on “value” (although not everyone can agree on that one – see my post “What Is Value” for my take, based on Goldratt and his Theory of Constraints). And for the record, we might also choose to frame the question of value within the Antimatter Principle frame, and vocabulary: Value: The degree to which folks’ needs, in aggregate, are being (or have been) met. But what about “customer”? So simple and straightforward. Do we even need to define it? I thought not, until a recent conversation on Twitter gave me pause for reconsidering. Specifically, the idea that maybe folks are talking at major cross-purposes, with significantly differing assumptions and definitions for the term. If we can’t agree on a basic term like “customer”, what chance alignment of a whole host of fundamental questions about software, products and business generally? Here’s my definition, again using the Antimatter Principle as a frame: Customer: Someone (could be either a person, or a collection of people) whose needs we’re attending to. I’m pretty sure you’ll have a different definition of customer. I’d love to hear your take. Before I close this post, here’s a different definition, informed by Crosby and his Zero-Defects (ZeeDee) approach to quality: Customer: Anyone who receives or anticipates receiving something (e.g. a good or a service) from someone else. This[…]

    19.10.2019 | 5:51 קרא עוד...

טיפים

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