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

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

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

  • Book Review: Agile Testing Condensed

    Book Review: Agile Testing Condensed I read a ton of books, and I've found that reading books about testing is my favorite way to learn new technical skills and testing strategies.  James Clear, an author and expert on creating good habits, says: "Reading is like a software update for your brain. Whenever you learn a new concept or idea, the 'software' improves. You download new features and fix old bugs." As a software tester, I love this sentiment!I thought it would be fun this year to review one testing-related book a month in my blog, and what better book to start with than Agile Testing Condensed by Janet Gregory and Lisa Crispin?  They literally "wrote the book" on agile testing a decade ago, then followed it up with a sequel called More Agile Testing in 2014.  Now they have a condensed version of their ideas, and it's a great read!This book should be required reading for anyone involved in creating or testing software.  It would be especially helpful for those in management, who might not have much time to read but want to understand the key components of creating and releasing software with high quality.  The book took only a couple of hours for me to read, and I learned a lot of new concepts in the process.  One of my favorite things about the electronic version of the book is that it comes with a ton of hyperlinks.  So if the authors mention a concept that you aren't familiar with, such as example mapping, it comes with[…]

    25.01.2020 | 11:08 קרא עוד...
  • Five for Friday – January 24, 2019

    This is the special time travel edition of FfF (I lost a day – mentally – while traveling). I have read, and re-read this article on Work is Work. It’s a fantastic analysis of organizational design. I plan on reading it yet again after I post this.It’s no secret that I like Radical Candor, and in order to care personally, you need to get to know your team. Mike Cohn posted 25 Questions that Will Help You Know Your Teammates Better this weekSpeaking of feedback, Negative Feedback Rarely Leads to ImprovementTwo github links to close things out – the first is The Book of Secret KnowledgeThe second github link is a curated list of Chaos Engineering topics. This one is staying in my favorites. (potentially) related posts: Five for Friday – January 19, 2018 Five for Friday – October 4, 2019 Five for Friday – January 4, 2019

    25.01.2020 | 3:22 קרא עוד...
  • How to Stamp Out Intermittent Testing Issues With Periodic Automation

    How to Stamp Out Intermittent Testing Issues With Periodic Automation Originally published by TechBeacon.com. In the pop culture of the United States, Sasquatch (a.k.a. Bigfoot) is a legendary and elusive ape-like creature infrequently seen in the Pacific Northwest. In the software realm, we have our own version of Sasquatch: those irritating, sometimes catastrophic, issues that are hard to reproduce. So, as a test engineer, how do you track down your own elusive Sasquatch? I use an approach I call “periodic automation,” and it works quite well. Traditionally, you run your automated tests on event boundaries such as when you’ve had a successful deployment. Why? When a deployment succeeds, it was initiated because some code changed in your application. To be effective with your time, you look for problems when you think they may have been introduced. Logically, points of change are where you expect to see issues injected, so you tend to only look for issues then. Unfortunately, this approach limits your opportunities to reproduce the previously mentioned intermittent issues: hard-to-reproduce issues that don’t occur on a predictable schedule or set of events. If, however, you also run your automation periodically, in addition to your event boundaries, you’ll have additional opportunities to reproduce these types of issues. Here’s how periodic automation works. Highly connected software is prone to intermittent issues Today’s software is highly connected, both to components in your production network and to servers and components outside of it. Analytics, payment, and social media services, for example, are often external to your application’s network. Reliance on these services makes your environment harder to test. Just enumerating all[…]

    25.01.2020 | 1:00 קרא עוד...

טיפים

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