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

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

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

he icon   en icon

שגיאה
  • JLIB_FILESYSTEM_ERROR_PATH_IS_NOT_A_FOLDER_FOLDER
  • JLIB_FILESYSTEM_ERROR_PATH_IS_NOT_A_FOLDER_FILES

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

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

נכתב על ידי 
חמישי, 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

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

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

  • Test data and masking

    For large enterprises with many interconnected applications, generating test data can be a challenge. Even more so for big data projects, which is where masking comes in.. Take a copy of production DB from different products around the same timeline and mask the data for GDPR compliance. Surely easier said than done, but can be very effective. IMHO three main requirements to build this: 1. A quick guideline to identify what data will be classified as ‘sensitive’ and ensure it’s GDPR compliant. 2. A masking platform which masks value the same way across, helping with consistent data 3. Creation and usage of test environments is efficient and fit for purpose #RedefiningSoftwareQuality #TestData #Automation The post Test data and masking appeared first on Quality Spectrum.

    18.01.2020 | 9:34 קרא עוד...
  • Your Future Self Will Thank You

    Your Future Self Will Thank You Recently I learned a lesson about the importance of keeping good records.  I've always kept records of what tests I ran and whether they passed, but I have now learned that there's something else I should be recording.  Read the story below to find out what it is!I have mentioned in previous posts that I've been testing a file system.  The metadata used to access the files are stored in a non-relational database.  As I described in this post, non-relational databases store their data in document form rather than in the table form found in SQL databases.Several months ago, my team made a change to the metadata for our files. After deploying the change, we discovered that older files weren't able to be downloaded.  It turned out that the change to the metadata had resulted in older files not being recognized, because their metadata was different.  The bug was fixed, so now the change was backwards-compatible with the older files.I added a new test to our smoke test suite that would request a file with the old metadata. Now, I thought, if a change was ever made that would affect that area, the test would fail and the problem would be detected.A few weeks ago, my team made another change to the metadata.  The code was deployed to the test environment, and shortly afterwards, someone discovered that there were files that couldn't be downloaded anymore.I was perplexed!  Didn't we already have a test for this?  When I met with the[…]

    18.01.2020 | 9:11 קרא עוד...
  • Accessibility Book Review: Inclusive Components by Heydon Pickering

    Accessibility Book Review: Inclusive Components by Heydon Pickering This book’s subtitle of, ‘Accessible web interfaces, piece by piece’ is almost the perfect descriptor as it really does do what it says on the tin.  Want to build an accessible tooltip?  This has step by step instructions with code examples and design renderings to not only show you what to do but show what it ‘should’ look like. There is plenty covered throughout the book and it is very easy to digest, even for someone who only reads code rather than writes it.  I’ve put some of the chapters included in the book below to give you a flavour of what to expect.  There’s even more under some of the headings with checkboxes and radio buttons included under Toggle Buttons as an example. Chapters include; Toggle Buttons Menus and Menu Buttons Collapsible Sections A Content Slider Data Tables Each chapter has a Conclusion summarising the content and a Checklist for those that have read and want a quick check or refresher.  These were particularly useful for me to help confirm my thoughts and I see no reason they wouldn’t do the same for someone with a more in-depth coding background.  In summary, this is a great book for anyone associated with web development or indeed design.  Like anything to do with software the examples given is not the only way to achieve accessible components and updates like HTML5 may render some of the recommendations redundant but that doesn’t stop me recommending it.  While the book was provided free to[…]

    18.01.2020 | 7:35 קרא עוד...

טיפים

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