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

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

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

he icon   en icon

הכירו את לקוחותיכם

נכתב על ידי 
ראשון, 29 יוני 2014 10:21
דרגו כתבה זו
(1 הצבעה)

הכירו את לקוחותיכם

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

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

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

נושא זה והנושא המקביל לו "עבדו כתמיכת לקוחות לזמן מה" שהועלו ע"י Chris George – הינם 2 הנושאים הראשונים ב-eBook ולא בכדי,

כשאנו באים לתכנן בדיקות למוצר – עלינו לעצור ולחשוב:

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

אז – איך נוכל להכיר את הלקוח/ה שלנו?

ישנם מוצרים להם קהל ממוקד – ואז ניתן לתאם פגישה ייעודית.
לעיתים ניתן להשתמש בפעילויות של סקרים, כנסים, התקנה או תמיכת לקוחות בכדי לפגוש הלקוחות
רצוי שכל הבודקים ייחשפו לכך – לפחות פעם בשנה.
רצוי לבנות קשרים חמים עם אנשי התמיכה, לשלב אותם בפעילויות הבדיקה ולהיפך (אין כמו שיחה עם לקוח המדווח על תקלה - בכדי להבין את השפעות המוצר עליו), וגם לעודד אותם לאסוף מידע תוך כדי הפעילויות שלהם, לתעד וליידע אותנו על צרכים בהם הם נתקלים וכיצד הלקוח תופס את המוצר.מוצרים אחרים הם גנריים – וכל שנוכל לעשות הוא לנסות לצפות במשתמשים במקומות שונים.אם יש פורום תמיכה – ניתן ללמוד ממנו המון (וכך גם מפורומים גנריים הקשורים לנושא).חיפוש ע"פ מילות מפתח יוביל לתגובות משתמשים בטוויטר, פייסבוק וכד'.
גם מידע הנכתב לגבי כלים דומים יכול לספק מידע רב לגבי צרכי הלקוח.למוצרי Web כנראה שנוכל להעזר בכלים המספקים משוב על דרך השימוש באתר כמו Google-Analytics.תוכנות רבות שומרות לוגים לא רק לגבי בעיות אפשריות אלא גם לגבי הפעולות שבוצעו ומי היה המשתמש שביצע אותן – השגת מידע זה וניתוחו ייתן לנו ידע רב.

לאחר שניתחנו את סוגי וצרכי הלקוחות שלנו – נוכל להגדיר פרופילים ובעזרתם לבנות תאור של מקרי שימוש – אשר ישמשו אותנו כבסיס לבדיקות וכמשוב לדרישות/הגדרות המערכת.

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

 

חומר קריאה נוסף:

http://www.mkltesthead.com/2013/07/99-ways-workshop-1-get-to-know-your.html 

http://www.mkltesthead.com/2013/07/99-ways-workshop-2-work-first-line.html 

http://blog.ruberto.com/2013/06/engage-customers-directly-to-build-high-quality-software

 

נשמח לשמוע רעיונות הערות והארות מכם הקוראים – בחלונית התגובה מטה, ו/או בפורום.

סדרת טיפים זו "כיצד להפוך לבודקים טובים יותר" מתבססת על דיון ב: Software Testing Club

99 Things Testers Can Do To Become Better Testers

ה-eBook החינמי שנוצר בעקבות דיון זה: 99ThingsEbook.pdf

וסדרת פוסטים מאת Michael Larsen בשם: Ways Workshop 99 - בה מיכאל מרחיב על כל אייטם וגם מספק הנחיות כיצד לתרגל הנושא.

 

 KnowYourCustomers

 

שונה לאחרונה ב ראשון, 29 יוני 2014 10:38

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

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

  • Mistakes – Like Riding a Bike…

    There comes a point in your progression of learning to code where you start to feel comfortable, almost complacent. While you acknowledge you’re far from the best coder and there’s plenty you don’t know yet, you feel comfortable enough in your ability and what you do know that you might feel tempted to stop learning in your spare time or stop coding as much as you did when you were trying to understand. This is especially true if you’re simply writing test scripts in your role, which may not always demand the most technical of code to be written. That’s not to take away from the accomplishment of coming from no programming experience to writing test scripts, however. The trouble with getting caught in this mindset is that it’s all too easy to quickly waste all that hard work you put into getting to that point in the first place. Programming, no matter how experienced you are, is something you absolutely must do regularly. Whether you’ve been a software developer for thirty years or a hobbyist for thirty days, a lengthy spell away from your favourite IDE will see you quickly hit a mental block when it comes to writing your next piece of code. You might think “it’s like riding a bike”, and that may be true to an extent. While you’ll never forget the problem-solving skills you learn and the logical approach required for programming, it’s the syntax required to write the code to solve those problems that[…]

    17.06.2019 | 5:40 קרא עוד...
  • What I Read Last Week (16th July 2019)

    It is a little last minute, but I am so excited to be given the opportunity to attend the London Tester Gathering Workshops. I will be attending the ‘Automate Scenarios with SpecFlow’ workshop on the 26th July, run by Gáspár Nagy. Specflow is a framework that uses Behaviour Driven Development. We’ve been looking into trying out new test automation frameworks at work and this is one that we’re hoping to use more extensively. Response to ‘How do you solve a problem like Selenium?’ Last week, I wrote a little more about the AB Testing podcasts thoughts on the industry obsession with UI testing and Selenium. João Farias, who runs the thatsabug.com blog, shared a couple of interesting articles on the subject. What do you mean by UI tests? by Mark Winteringham, Automation in TestingAre we testing the UI or testing through the UI? In this post, Mark discusses the definition of UI tests a little more. Not everything needs to be tested through the UI, but ultimately it is about risk. The risk defines the approach, not the tool. Testing Ember Applications: First Steps by João Farias, That’s a bugJoão talks about his previous experience testing using Ember which tests the front end code, rather than the UI (which Selenium does). Link to the comments can be found here. Thanks for sharing João, much appreciated! Webinars Ask Me Anything – Shift Left, Shift Right – Marcus MerrellA brilliant AMA, hosted by the MInistry of Testing. Many brilliant questions were asked about[…]

    17.06.2019 | 2:59 קרא עוד...
  • Do you need Test leadership?

    I’m uncertain as to why sometimes it’s so hard to explain the importance of ‘test leadership’. People can have a lead architect, a lead product owner, a lead developer and even a ‘lead of leads’, but having a test lead would somehow kill autonomy… The argument is in agile world the team does the job, so they should be self-reliant, and no one needed to ‘manage’ them. What they fail to understand is testing with technical competence is not something abundantly available in the industry. Most companies have to manage with the few senior resources they’ve got and use them to train rest of the teams. IMHO the root cause is this deep-rooted ignorance that testing is just a matter of doing some ‘monkey testing’ and that’s about it. I’d argue testing and specifically automation take as much resources as developing the service, whoever plays that role requires critical thinking, strong technical skill and exposure. One would assume after decades of blunders and evolution we would have realized why strong testing is important, no wonder restating your PC when software is not working seems to be ‘perfectly normal’.

    17.06.2019 | 11:06 קרא עוד...

טיפים

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