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

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

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

he icon   en icon

בחן את עצמך - כיסוי מחלקות שקילות בטבלת ההחלטות - טל פאר (גיליון #3)

נכתב על ידי 
שישי, 20 מאי 2016 13:15
דרגו כתבה זו
(1 הצבעה)

בחן את עצמך - כיסוי מחלקות שקילות בטבלת ההחלטות - טל פאר (גיליון #3)

את/ה בודק/ת מערכת מסחר אלקטרוני. המערכת מקבלת 4 סוגים שונים של כרטיסי אשראי; לכל כרטיס יש חוקים משלו לגבי חוקיות של מספרים.
לפניך חלק מטבלת ההחלטות של ניהול ההזמנות:  (ראה בתמונה)
אתה רוצה לבצע בדיקה שמכסה את כל השילובים של מחלקות שקילות ( equivalence partitioning ) עבור סוגי כרטיסי האשראי השונים, בהתאם לחוקים המופיעים
בטבלת ההחלטות למעלה.
כמה מקרי בדיקה ( test cases ) אתה צריך?

שאלה זו הופיעה בגיליון #3 של מגזין עולם הבדיקות - לצפייה בפורמט המלא כולל קישורים וכד' ובשאר מאמרי גיליון זה:
http://goo.gl/4LRshN

 

TW3 ExamQ TalPeer 1

...

   ...

      ...

TW3 ExamQ TalPeer 2

 

 

 

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

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

  • What’s big deal with testers? Hit that punching bag !!!!

     Once in every 1 or 2 years - testing team or function comes under "question". I have seen this consistently for last 20 years. For business leaders, Heads of Business verticals - testing has been a punching bag. Whenever leadership changes or sales go low or profits fall - suddenly discussion on "efficiency" and throughput per person becomes an important metric. Why do we need such a big testing team? why cannot developers do all the testing required? Why not end users do the testing required? why cannot be automate this stuff and get testing head count out of equation? Why cannot we do crowd sourcing? - are the questions that business leaders ask. Testing leads and managers - start running from pillar to post to justify why they exist -- come up with all sorts weird metrics and process maps to show why testing required. But business leaders are hell bent on cutting that "extra" fat in the system. There go "testing team " out of the company.What is big deal about testing or testers ? They ask. First of all let us ask what is/ required to do testing? Knowledge of the system or business domain or technology that used to build it?  Let us explore...Business analysts know the product inside out as they have "defined" it (by writing down BRD - business requirements document). They should be the ones best suited to do all or required testing. No?Developers too claim that they know system inside out  -[…]

    23.11.2020 | 12:45 קרא עוד...
  • Stop paying users, start paying testers

    At work when I find a bug, I'm lucky. I follow through during my work hours, help with fixing it, address side effects, all the works. That's work.When I'm off work, I use software. I guess it is hard not to these days. And a lot of the software recently makes my life miserable in the sense that I'm already busy doing interesting things in life, and yet it has the audacity of blocking me from my good intentions of minding my business.Last Friday, I was enjoying the afterglow of of winning a major award, bringing people to my profile and my book, only to learn that my books had vanished from LeanPub. One the very day I was more likely to reach new audiences, LeanPub had taken them down! After a full excruciating day of thinking what was it that I did wrong to have my account suspended for authorship, LeanPub in Canada woke up to tell me that I had, unfortunately, run into a "rare bug". Next day I had my books back, and a more detailed explanation of the conditions of the bug. If I felt like wasting more of my time, I guess I could go about trying to make a case for financial losses.It took time of my busy day to figure out how to report the bug (not making it easy...) It caused significant emotional distress with the history of one book taken down in a dispute the claimant was not willing to take to courtIt most[…]

    23.11.2020 | 12:02 קרא עוד...
  • Asking Your Users Perception

    A colleague was working on a new type of application, one that did not exist before. The team scratched together a pretty but quick prototype, a true MVP (minimum viable product) and started testing that on real users. Every user they gave the app to, gave the same feedback on a detail they did not like after first experience of use. Fixing the thing would take a while, but since the feedback was so unanimous, the team got to work. A week later, they delivered a new version. Every user that had the app before, hated that there was a change, they had grown to like the way it was. Every user they added for first time experience, hated how it was different from the usual way things are done. For the first day, until they learn.I shared this story to my team at work this morning, as my team was wondering if we should immediately put back the "in review" state to our work board in Jira. The developers were so used to calling "in review" their done, but also refusing to call it their done and moving it to the done column. They used to leave tickets to this in review column, and no one other than themselves was finding any value on it. We agreed to give the change two weeks before going back to reflect on it with the idea that we might want to put it back. Users of things will feel differently when they are still adjusting to change, and[…]

    23.11.2020 | 3:43 קרא עוד...

טיפים

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