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

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

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

he icon   en icon

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

מי מאתר תקלות טוב יותר - צוות בודקים פנימי בחברה או משתמשי בטה?

נכתב על ידי 
חמישי, 26 יוני 2014 11:34
דרגו כתבה זו
(1 הצבעה)

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

המאמר קיבל לא מעט תשומת לב, ואחד הקוראים העלה שאלת המשך מעניינת: "לאחר בחירת המתודולוגיה 'הכי טובה', עולה השאלה איך כדאי ליישם אותה. האם בדיקות ע"י צוות מקומי/פנימי לחברה או שמא בעזרת פתיחת התהליך לבדיקות הקהל הרחב (בטה פתוח)?"

זו שאלה נהדרת, מאחר ויש סיבות משכנעות לשימוש בכל אחת מהגישות הללו.

הבה ונבחן זאת.

בעד בדיקות תוכנה על ידי צוות בודקים

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

הנה מה שאנחנו אוהבים בבדיקות תוכנה הנעשות "בבית":

· אתה יכול למנף את העוצמה של בודקים מומחים היודעים בדיוק מה לחפש.

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

· צוות מסור זה מכיר את הקוד, את הפונקציונליות של המוצר, ומה "צריך" להיות. הצוות מבין איך המוצר אמור להתנהג ומה לצפות ממנו.

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

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

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

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

בעד בדיקות תוכנה על ידי קהל הלקוחות

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

או טובות בכלל?

בואו נבדוק זאת:

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

· משתמשים (הפועלים כבודקים עכשיו) יבחנו ויבדקו את המוצר מכל זווית אפשרית. הם יגיעו למקומות ומצבים, שצוות הבדיקות לא יעלה על הדעת לבדוק אותם.

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

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

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

· למרות שאין למשתמשים בהכרח הכשרה בבדיקות, הם "באים" בגדלי צוות גמישים ומציעים כיסוי של 24/7 לבדיקות גלובליות, לעומת משמרות מקומיות של 8 שעות.

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

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

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

איזה סוג בדיקות כדאי לבחור?In House או Beta?

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

אבל היא לא.

אנחנו מאוד ממליצים על שימוש בשני סוגי הבדיקות. והנה הסיבות.

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

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

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

OneVsMany

שונה לאחרונה ב שני, 30 יוני 2014 18:59

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

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

  • Humidifier For Home Heater

    Humidifier For Home Heater humidifier for home heater humidifier for sq ft. . . . . . . . . . . . . . .

    25.05.2019 | 11:08 קרא עוד...
  • ATA Meetup #22 - Bangalore - Amazing experience

    ATA Meetup #22 - Bangalore - Amazing experience Reached super earlyThe session was supposed to start at 9 AM and I reached by 7.45 AM. I did not want to be late. Due to weekend's minimalistic traffic and super driver, I surprised myself and I thought I can just enter and wait in the hall. The security asked me the contact person name and I told him that there is a meetup by Agile Testing Alliance - did not help. I called up Aditya Garg and somehow the security got convinced that I can at least pass the main barricade and sit on the makeshift park seats.It was nice to experience fresh air, have fruits and dive into an interesting book called "The Practicing Mind" by Thomas M. Sterner. The Practicing Mind I remembered the discussions with Shrini Kulkarni about consciousness, mind, awareness as I read the book. Around 8.40 AM, Thrivikram and Venkata P from HCL welcomed and escorted me to the induction hall where we had the meetup. The conversation between them and the security folks was an interesting one making me think of the process adherence vs value addition. Learning for me: Know the contact person in advance and keep them informed about surprises in plan. HCL ServicesThe first session was by HCL management represented by Prashantha M who highlighted the various services offered by HCL, the case studies and the learning. There were few really good questions by the audience who wanted to know more details about the insights shared to them.My tip: Knowing[…]

    25.05.2019 | 11:55 קרא עוד...
  • Performance testing (benchmarking) Java code with JMH

    Performance testing (benchmarking) Java code with JMH Contents:1) Introduction2) Is it easy?3) Common pitfalls4) Setup5) How to configure JMH?6) Configuration options7) Configuration - predefining state8) Demo9) Results10) Further reading1. IntroductionAs test engineers when we approach performance testing we usually only think about final end-to-end application verification with tools such as JMeter, Locust or Gatling. We know that such tests should run on a separate environment with conditions resembling production as close as possible. Unfortunately in some cases (especially with monolithic architecture) dedicated performance testing environment is hard to get. What to do in such cases? Should we test on common test environment? Or should we test on production? Or maybe we should change our approach to performance testing?  Each option has advantages and disadvantages.Today I'd like to describe low-level performance testing (often called benchmarking) of Java code. It does not require a separate environment. It can be executed directly from your IDE (although that's not recommended) or from the command line. Measuring the performance of critical pieces of code is essential for everyone who creates applications, frameworks, and tools. Testers are co-creators so it's also our responsibility. 2) Is it easy?Benchmarking correctly is hard. There are multiple optimizations implemented on the JVM/OS/hardware side which make it challenging. In order to measure right, you need to understand how to avoid those optimizations because they may not happen in the real production system. Thankfully, there is a tool which helps you mitigate those issues called JMH (Java Microbenchmark Harness). It was created for building, running, and analyzing nano/micro/milli/macro benchmarks written in Java[…]

    25.05.2019 | 8:10 קרא עוד...

טיפים

  • בדוק מוקדם ככול הניתן
    בדוק מוקדם ככול הניתן "בדוק מוקדם ככול הניתן" – אחת המטרות של הבדיקות הינה לספק כמה שיותר משוב ומידע לגבי איכות המערכת מנקודות מבט שונות (פונקציונליות ולא פונקציונליות כמו עמידה בעומסים ושאר יכולות). לעיתים בודקים נוטים בטעות לחשוב כי הדרך…
    קרא עוד...
  • בודק - השאר ממוקד מטרה
    בודק - השאר ממוקד מטרה בודק - "השאר ממוקד מטרה / Keep Your Eye on the Ball - The End Goal " – כבודקים בעלי יכולת מיקוד וירידה לפרטים, לעיתים אנו מאבדים את התמונה הכוללת וצוללים יתר על המידה בבדיקת נושאים…
    קרא עוד...
לרשימה המלאה >>