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

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

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

  • Parkinson’s law in software testing

    Coffee was brewing for the third time. It was dead silent in the dorms. Only a dim screen lit the room and steady tap of the keyboard took flight. It was 3am and the deadline was approaching fast.That was the story of my life. When I studied back at the University of Oulu in Finland I got myself into trouble on a regular basis. I procrastinated on starting with my project reports and essays for days. My small apartment was super tidy, I had taken care of calling both grand moms twice during the week and even dragged my ass to the gym every day.Have you experienced similar situations? Basically everything except the important paper was taken care of. My ways of postponing the inevitable were clever and creative. But the last evening before the deadline always came. Usually around 5pm I brewed my first coffee and got to work.I did the same drill every semester with every report paper and every project. And never failed once. The work got magically done, no matter how big it was. In the morning I stormed in to the course assistants room and delivered my results. It’s uncanny how naturally everything worked out when the deadline came. It’s always the final hours before the deadline that are the most productive hours for me.Last year I started a new project, because I wanted to write a book about software testing. Once again I found myself filling the days up with pointless meetings, email and social media combined[…]

    18.02.2019 | 8:08 קרא עוד...
  • European Testing Conference SpeedMeet - How To?

    European Testing Conference SpeedMeet - How To? Picture a conference you went to, alone. You don't know anyone, not sure if they want to talk about exploratory testing (your favorite) or test automation (not your favorite) and not feeling like you have the energy to go and push yourself on random strangers. You show up, sit in a table, watching people around you discuss and listen until it is again time to head to a session.As a socially anxious extrovert, I have had huge problems with conferences. I want to talk to people,  but the need of taking the first step and finding out if they want to talk to me drains me. My usual recipe is to be a speaker, and have people approach me. But the same issue drove me to figure out other designs for my conference, and SpeedMeet was born.SpeedMeet puts together three insights: Pairing people up with a rule to introduce is an effective way of building relationships. The rule helped people at Scan Agile meet, and we wanted to do more of sessions where social interaction wasn't emergent but facilitated. The meeting needs an artifact that introduced pull over push in introductions. This piece we found in Jurgen Appelo's talk in Agile Serbia, and combining it my personal aversion to talking about beer (push information often provided in the tester community), the connection to the right dynamic was evident.  The high-volume high-interaction event needs an escape route and permission. This piece became evident with experimenting with large crowds listening to feedback. […]

    18.02.2019 | 8:01 קרא עוד...
  • Inspecting Elements for writing XPath, CSS Selector in Chrome

    The most important part in any kind of automation is, identifying various elements over which we want to perform an action and when it comes to web application or android application automation using Selenium WebDriver or Appium, we fall for Chrome, Firefox or Internet Explorer to find the right set of XPath or CSS selector. For the same, all mostThe post Inspecting Elements for writing XPath, CSS Selector in Chrome appeared first on Abode QA.

    18.02.2019 | 5:23 קרא עוד...

טיפים

  • טיפ - עבודת בודקים בצמד עם המפתח
    טיפ - עבודת בודקים בצמד עם המפתח  עבודת בודקים בצמד עם המפתח "עבודה בצמד עם המפתח" – לעבודה בצמדים יתרונות רבים אך לעיתים היא נזנחת בשל "העלות הכפולה". בשנים האחרונות עם עליית שיטות אג'יליות ו- Extreme Programming צורת עבודה זו יותר נפוצה. כששני…
    קרא עוד...
  • בודק - למד לשאול – Learn to Question
    בודק - למד לשאול – Learn to Question  בודק - למד לשאול – Learn to Question - Tony Bruce – חלק ניכר מעבודת הבודק כרוכה באיסוף מידע לגבי המערכת, התכונה או הנושא הנבדק.במהלך איסוף המידע נתקל במידע רב המגיע מגורמים שונים, וכולל הנחות אותן…
    קרא עוד...
לרשימה המלאה >>