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

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

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

he icon   en icon

בודק - הבן את המודל והאתגרים העיסקיים

נכתב על ידי 
ראשון, 30 נובמבר 2014 20:28
דרגו כתבה זו
(4 הצבעות)

בודק - הבן את המודל והאתגרים העיסקיים

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

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

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

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

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

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

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

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

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

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

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

http://www.mkltesthead.com/2013/07/99-ways-workshop-13-understand-business.html

 

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

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

99 Things Testers Can Do To Become Better Testers

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

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

שונה לאחרונה ב ראשון, 31 מאי 2015 05:19

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

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

  • I am not a robot

    I am not a robot ...

    21.10.2018 | 1:35 קרא עוד...
  • The dragons of the unknown; part 5 – accident investigations and treating people fairly

    The dragons of the unknown; part 5 – accident investigations and treating people fairly Introduction This is the fifth post in a series about problems that fascinate me, that I think are important and interesting. The series draws on important work from the fields of safety critical systems and from the study of complexity, specifically complex socio-technical systems. This will be the theme of my keynote at EuroSTAR in The Hague (November 12th-15th 2018). The first post was a reflection, based on personal experience, on the corporate preference for building bureaucracy rather than dealing with complex reality, “Facing the dragons part 1 – corporate bureaucracies”. The second post was about the nature of complex systems, “part 2 – crucial features of complex systems”. The third followed on from part 2, and talked about the impossibility of knowing exactly how complex socio-technical systems will behave with the result that it is impossible to specify them precisely, “part 3 – I don’t know what’s going on”. The fourth post “part 4 – a brief history of accident models” looks at accident models, i.e. the way that safety experts mentally frame accidents when they try to work out what caused them. This post looks at weaknesses of of the way that we have traditionally investigated accidents and failures, assuming neat linearity with clear cause and effect. In particular, our use of root cause analysis, and willingness to blame people for accidents is hard to justify. The limitations of root cause analysis Once you accept that complex systems can’t have clear and neat links between causes and effects[…]

    21.10.2018 | 12:38 קרא עוד...
  • Implementing RestSharp in REST API automated tests

    I have written before a few times about implementing automated tests for REST APIs using C# (here and here). In those posts, I’ve used a utility method to handle the actual sending of the HTTP request, and another one to read the response. These methods help to illustrate what our automated tests are actually doing. However, I don’t think I need to be bothered with all of that all the time. Generally, in an automated test suite, you don’t want to be building everything yourself from the ground up. Actually, that goes for most things we’re building – that’s why libraries exist! So I looked into a NuGet package that would do what I wanted, and found RestSharp. Using RestSharp really cleaned up my code! For one, it got rid of those utility methods. And let’s be honest, I’m not the most amazing C# developer, and I’m sure there were issues with those methods. And it combines the request to the API and the deserialization of whatever came back all in one line of code, so my tests have fewer lines of code as well. I just needed to add the RestSharp NuGet package to my test project, and add the reference. Let’s take a look at the before and after! Before [Test] public void VerifyGetTodoItem1ReturnsCorrectName() { //Arrange var expectedName = "Walk the dog"; //we know this is what it should be from the Controller constructor var url = _baseUrl + "1"; //so our URL looks like https://localhost:44350/api/Todo/1 //Act var response =[…]

    21.10.2018 | 11:22 קרא עוד...

טיפים

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