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

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

טיפים

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