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

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

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

  • 10 Amazing Reasons to Attend TestBash Brighton

    by Rosie Sherry Want to go to TestBash Brighton , but struggling to put good reasoning together for yourself or your boss ?   There’s no doubt that the world of conferences, software testing and TestBash has changed in the past few years.  In the case of TestBash(es) we’ve evolved and grown in many different ways, I thought it would be helpful to point out some key points and ideas we are working on. Belonging ‘I feel like I belong.  I now understand what TestBash is all about.’  This is one of the most frequent comments we get.  I've heard it many times over the years. For some it can be an almost instant feeling. For others it  can take years for people to get around to coming along to a TestBash.  And sometimes it even takes a few TestBashes for them to get into the flow of it . When we talk about community we mean it.  When you come to a TestBash - you are welcome and you belong.   Sometimes these things take practice and effort. You may look around and feel that people connect with others more easily, whilst you are struggling.  This is a natural way to feel and to be clear, what you see is not always the truth. People at TestBash are always practicing, seeking and exploring ways to connect better.  The more you put in, the more you will get out.  We work hard to encourage everyone to help each other out.  Just[…]

    13.01.2019 | 6:00 קרא עוד...
  • TestBash Manchester: TestBash Of The North

    The North remembers what an absolute belter TestBash Manchester 2018 was, so we are coming back, Manchester! For a fourth time! And, we can’t flipping wait! It going to be a spectacular action-packed week-long extravaganza at The Lowry , filled with opportunities to learn, network, have fun, and of course, space to reflect on all that’s going on. Here’s the itinerary for the week: Automation In Testing (Monday 30th September - Wednesday 2nd October) - a fantastic three-day training course taught by Richard Bradshaw and Mark Winteringham. You’ll learn all about the current state of automation, how to design and implement reliable, targeted automated checks, and create new automation tools to test products at your company. TestBash Workshops (Wednesday 2nd October) are a series of ½ day workshops, some of which focus on technical testing and some on the softer skills a tester needs. A workshop ticket gives you the chance to choose two workshops that appeal to you on a first come, first served basis. TestBash (Thursday 3rd October) is our original software testing conference. It’s a single track event, meaning every talk is a keynote and all attendees have lots to talk about during the breaks and socials. Expect a balance of talks that cover the important aspects of testing, quality and working in software development. It’s fun-filled, jam-packed day! Test.bash(); (Friday 4th October) is our technical testing and automation focussed conference. It’s a single track event, with fun and unique elements sprinkled throughout. Expect talks that include[…]

    12.01.2019 | 6:00 קרא עוד...
  • December RoundUp of All Things MoT

    December was a great month, a nice end to 2018.  We're all ready for 2019 and no doubt full of resolutions.  Is one of them to  speak at a TestBash ?  Or maybe to focus on your professional growth with a  pro member account ?       The Club A few selected discussions from  The Club  that we thought you might find interesting. How to test a mobile game?  posted by nitin1387. When you're new to mobile games testing, it can be difficult to know where to start or what skills are transferable. Do you have  beef  with the idea that anyone can test software?  posted by rosie. How do you respond to the arguments that anyone can test software, so professional software testers are not needed, in a meaningful way? How Would You Test An ATM?  posted by heather_reid. What behaviour would you expect, and not expect, from the ATMs you use? Test Team Structure  posted by inkyfreak. What way are teams in your organisation structured and what have you found to be the most effective structure for test teams? Your Most Used or Favourite Swag Item  posted by heather_reid. We're mindful of the environment and keeping waste levels low at MoT, so we're wondering what swag items you use every day no matter where you got them from.   The Club Ninja Each month we select one of our Club users to be our  Ninja of the Month .  Our Club Ninja this month is Tuan Tran!  […]

    9.01.2019 | 6:00 קרא עוד...

טיפים

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