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

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

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

he icon   en icon

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

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

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

איך לא להגביל חשיבה חופשית של הבודק ועדיין לשמור על כיסוי איכותי, וידע קודם? 28 נוב 2013 08:50 #1032

  • halperinko
  • halperinko's Avatar
  • מנותקים
  • Administrator
  • פוסטים: 836
  • תודות שהתקבלו 35
  • קארמה: 3
שאלה שעלתה במוחי:
:woohoo: :evil: :S איך לא להגביל חשיבה חופשית של הבודק ועדיין לשמור על כיסוי איכותי, ידע קודם שעלה ב-Review או סבבים קודמים של בדיקות?


FreeThinking.jpg



והנושא הוא כזה - מצד אחד כבודקים - אנו רוצים לשמר חשיבה חופשית של הבודק, ומקום להעלאת רעיונות חדשים - אך שככול שאנו חושפים אותו ליותר ידע מוכן מראש, כך אנו גורמים לבודק לעקוב אחר נקודות אלו (לרוב גם ע"פ הסדר בו הן מוצגות) ומפסידים "ראש פתוח" - כלומר ייתכן מאוד שאנו גורמים לו ל-bias או תחושה שכיסה מספיק גם בלי להעלות רעיונות חדשים.
מאידך - כותב הבדיקה (בין אם אותו אדם בעבר או אחר) כבר חשב והעלה רעיונות, קיבל עליהם משוב ב-Review, הגדיר מס' נק' כדברים שחייבים לבצע בכל סבב וכן הלאה - ולא נרצה לאבד ידע זה, ולגרום לכיסוי חלקי בסבבים הבאים ע"י הסתרה מלאה שלו.

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

האם יש דרך נוחה לממש זאת כאשר עובדים עם מסמכי וורד / אקסל?
האם יש דרך לממש זאת כאשר עובדים עם כלי ניהול בדיקות שונים? ואולי עלינו להציע למפתחיהם להכניס שיפור זה - אשר יגביר את איכות ה-Exploratory Testing שלנו?

מה דעתכם בכלל על הנושא? איך אתם רואים זאת?

לדיון המקביל בתפוז:
www.tapuz.co.il/forums2008/ViewMsg.aspx?...&MessageId=172680642
עריכה אחרונה: 28 נוב 2013 08:58 ע"י halperinko.
יש להרשם בכדי לכתוב בפורום.

A story on failure by Anne-Marie Charrett 30 נוב 2013 20:35 #1034

  • halperinko
  • halperinko's Avatar
  • מנותקים
  • Administrator
  • פוסטים: 836
  • תודות שהתקבלו 35
  • קארמה: 3
A story on failure
by Anne-Marie Charrett

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

www.slideshare.net/amcharrett/a-case-onfailure#!
יש להרשם בכדי לכתוב בפורום.

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

  • Using Triforce to define Acceptance Criteria

    Using Triforce to define Acceptance Criteria Acceptance Criteria (ACs) are the basics for providing the “what” for any business ask. At their core they are a series of functionality statements telling us what behaviours we want from a feature and link the business ask back to engineering. As testers we use the Acceptance Criteria to help guide our testing and can even push our testing to the left (earlier) by helping to refine the ACs to think about errors and edge cases. How do we do that? Using Triforce! What is Triforce? Triforce are sessions used to refine and create User Stories to provide a shared and complete understanding of what is to be built. You might have seen these sessions named Three Amigos or Power of Three; I call them Triforce because 1) That’s an non-gendered name and 2) It sounds cool and fun to be a part of. They are a collaboration between project team members who each champion a perspective needed: Business, Engineering & Testing. Business – provide context on requirements and user needs (e.g. product owner / product designers).Software engineering – provide context on implementation details and what’s possible.Testing – seek to ensure tickets are testable and ready for development by ensuring all thoughts are covered. The Tri in Triforce does not refer to the number of people in a session, it refers to the number of perspectives (or hats) that should be represented in a session. Given that there may be people with different amounts of domain knowledge or front end[…]

    23.09.2021 | 8:43 קרא עוד...
  • Performance testing API’s with async/awaits

    Performance testing API’s with async/awaits I’ve got this serverless cloud function, you can read about how I built it here. Today’s blog is how I’d go about performance testing this API using async/awaits in Typescript. The API helper class Here is the GET API function: import request from 'supertest'; /** * Checks API is up. */ export async function checkMinSupportedVersionAPIReturns200( ) { const response = await request('https://australia-southeast1-buggybank.cloudfunctions.net/') .get(`min-app-version`) .expect(200); return response; } The performance test Here’s the performance test function, it spins up 10 concurrent instances to hit this API over 5 seconds. And it’ll wait 30 seconds before timing out. describe( 'performance test APIs', () => { it('should handle some load', async () => { await sendManyRequests(10, 5); }, 30000); Helper function – send single request There’s a send single request helper function, I really should have used another one with a shorter name but I’m a lazy dev. const sendSingleRequest = async (): Promise<void> => { await checkMinSupportedVersionAPIReturns200(); }; Helper function – send many requests Next thing to add is a function that calls many requests and builds up from that single request. Inflight is used to increase the await time. const sendManyRequests = async (maxInflightRequests:number, durationSeconds: number): Promise<void> => { let inFlight = 0; const startEpoch = Date.now(); const endEpoch = startEpoch + (durationSeconds * 1000); while (Date.now() < endEpoch) { while (inFlight < maxInflightRequests) { inFlight++; sendSingleRequest() .then(() => { inFlight--; }) .catch((err) => { inFlight--; console.error(`Request error: ${err}`); errorCount++; }); } await delay(10); } while (inFlight > 0) { await[…]

    23.09.2021 | 3:39 קרא עוד...
  • Podcast | API Testing Using Postman With Kristin Jackvony

    This API testing podcast definitely will help you out.In many ways, API testing is faster and far superior to automated UI Testing. Find out why In this episode. Kristin Jackvony, a software tester, blogger, and soon-to-be-published author, will share some key takeaways from her LinkedIn course on Postman Essential Training.For all your testers and developers that need to do API testing, you’re in for a treat. You’ll learn all about Postman, a popular (and free) solution, and how it can help you with all your API testing needs. Listen up! Check out our API Testing Articles The post Podcast | API Testing Using Postman With Kristin Jackvony appeared first on TestsVision.

    23.09.2021 | 2:48 קרא עוד...

טיפים

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