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

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

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

  • Once upon a time, le PO Testeur

    Once upon a time, le PO Testeur Aujourd’hui, la notion de qualité dans les applications délivrées prend de plus en plus d’ampleur dans le monde numérique. Cependant, si les hiérarchies arrivent à bien identifier les coûts pour mettre en place une certaine qualité, elles n’arrivent pas forcément à faire de même pour les gains que cela va apporter. Les dirigeants vont donc mesurer les coûts et les contrôler le plus possible. Le plus souvent, ces restrictions vont empêcher de mettre en place un service qualité pleinement efficace, et donc empêcher le but final qu’est le produit de qualité.Une de ces restrictions, que j’ai pu constater plusieurs fois par moi-même, est celle de la double casquette PO et chargé des tests fonctionnels. Ces deux rôles sont selon moi incompatibles sur un même projet. D’une part, leurs charges de travail individuelles sont trop importantes pour assumer un deuxième rôle. Sur un projet, les missions de ces 2 profils s’effectuent correctement si on s’y consacre à temps plein. De plus, les missions demandées, les profils, et les points de vue sont complémentaires et se challengent l’un l’autre.Dans cet article, on pourra également assimiler le rôle du PO du cadre Scrum au rôle de Business Analyst dans d’autres méthodes.1) Deux rôles qui vont se challengerEn effet, les missions de ces deux acteurs sont fondamentalement différentes, mais surtout complémentaires l’une de l’autre. Le PO va porter la vision du produit et alimenter le backlog, la liste des fonctionnalités qu’on envisage d’intégrer dans le produit. Il va toujours chercher à ajouter de la valeur au[…]

    24.02.2020 | 3:54 קרא עוד...
  • Customers Don’t Want To Use Your Software

    Customers Don’t Want To Use Your Software I often use a pithy phrase I picked up from Michael Bolton many moons ago (which he himself picked up from David Platt author of Why Software Sucks) to help people understand the relationship between software quality & it’s users / customers I’ve been using it a lot recently, so thought I’d share it here Banksy artwork shredded during auction Here’s the phrase as I remember it: “People don’t want to use your software, they want to have used it” (Source – David Platt) This is how I interpret & use the message: as much as we think our customers will just love navigating our website or product, that isn’t their goal. Our software is merely a means to achieving their actual goal (like buying a birthday present, checking their  bank balance or paying a bill). A Picture Hanging Analogy Michael brings this idea to life with the analogy of hanging a picture – in order to get to the outcome of visual beauty on your wall, you (by & large) need to drill a hole. Most of us don’t want to use a drill, we choose to use it in order to get a picture on the wall in a timely manner. Sidenote – the use of a drill is a fantastic analogy of tools / automation helping humans, but that’s another story… This message is powerful itself as it helps build empathy with your customer & makes you realise just where you as a software development team sit in[…]

    24.02.2020 | 3:45 קרא עוד...
  • Meme of the day: When you ask a question in stackoverflow

    Source : Reddit The post Meme of the day: When you ask a question in stackoverflow appeared first on The Life Of One Man.

    24.02.2020 | 2:06 קרא עוד...

טיפים

לרשימה המלאה >>