‫מרצים‪ :‬דני אלמוג‪ ,‬הדס חסידים‬

‫תשע"ח‬
‫באר שבע יום ב ‪10:00 – 13:00‬‬
‫‪17:00 - 14:00‬‬
‫אשדוד יום ג ‪11:00 – 14:00‬‬

‫שעות קבלה‪ :‬בתאום מראש‬

‫דואל‪hadasch@ac.sce.ac.il almog.dani@gmail.com :‬‬
‫‪1‬‬
 ‫מקורות‬ ‫שבוע נושא‬
‫רלוונטיים‬
‫‪1‬‬ ‫מבוא‪ ,‬מהי איכות תוכנה‪ ,‬איכות תוכנה במחזור חיי תוכנה‬ ‫‪1‬‬

‫‪1,2‬‬ ‫מדדי איכות של תוכנה‪ ,‬מה לומדים מהקוד‬ ‫‪2‬‬

‫‪7,9‬‬ ‫האורקל של הבדיקות‪ ,‬בדיקות בתהליך הקידוד (‪,)unit test‬פיתוח בדיקות )מסיפור משתמש למקרה הבדיקה)‬ ‫‪3‬‬

‫‪1,2,3‬‬ ‫סוגי בדיקות שונים‪ -‬פונקציונאליות‬ ‫‪4‬‬

‫‪4‬‬ ‫אזורי בדיקה טכניקות ומיפוי‪-‬שקילות‪ ,‬גבולות‬ ‫‪5‬‬
‫‪4‬‬ ‫המשך טכניקות בדיקה‪ -‬ודרישות ומונחה סיכונים‬ ‫‪6‬‬
‫‪13‬‬ ‫שיטות לבחירת מקרי ותכולת הבדיקות‪Model Driven Testing ,‬‬ ‫‪7‬‬
‫עקיבות‪ ,‬דרגות הבדיקה‪ ,‬ניהול שגויים‬ ‫‪8‬‬
‫פיתוח וניהול תוכנית איכות ובדיקות‬ ‫‪9‬‬
‫סביבות בדיקה (בסיסי נתונים‪ ,‬מכונות וירטואליות‪ ,‬כלי בדיקה)‬ ‫‪10‬‬

‫‪11,12,14‬‬ ‫שיטות פיתוח ובדיקות בסביבות מתקדמות‪IoT ,Mobile DevOps -‬‬ ‫‪11‬‬

‫‪4‬‬ ‫הצד האנושי היבטים רכים –תפקידים‪ ,‬תקשורת‪ ,‬יכולות‬ ‫‪12‬‬

‫שעור חזרה והכנה לבחינה‬ ‫‪13 2‬‬
 ‫מה יהיה בשיעור זה‬
‫מה היה בשיעור‬
 Reminder – domain testing ‫הקודם‬
 From users story to a testing story
 Requirements engineering & specification  Development of
testing test cases
15.1 Requirement/Specification based testing  Testing
15.2 What makes a bad requirement ? techniques- cont’.
15.3 How to produce a good requirement?
 Cognitive
15.4 Requirement tree and hierarchy
 Risk Based testing
aspects in
16.1 Risk and risk management testing
16.2 Risk based task planning  Domain testing
16.3 Organizational risk driven process: pros and cons techniques
3
 ‫הבנת תהליך בדיקות מחלקה‬
‫ב ‪ Domain Testing‬אנו‪:‬‬
‫מקרה מייצג ‪1‬‬ ‫‪ ‬מחלקים את מרחב הבדיקות‬
‫לאזורי בדיקה‬
‫מקרה מייצג ‪2‬‬
‫‪ ‬מחלקים כל אזור למחלקות‬
‫מקבילות – ‪Equivalent‬‬
‫‪Classes‬‬

‫מקרה מייצג ‪3‬‬

‫‪ ‬בודקים כל מחלקה בנפרד‬
‫תוך שימוש בערכים המוכלים‬
‫בה‬
‫‪ ‬בודקים את נקודות המפגש‬
‫מקרה מייצג ‪4‬‬ ‫בין המחלקות ‪Boundary‬‬
‫‪Testing‬‬
‫‪4‬‬
Equivalent Class represent a group of values of a parameter which will
be identically processed by the program, therefore we may be indifferent
in the selection of specific item within the group included it the test
case.

5
Characterize the variables
a. Identify the potentially interesting variables
b. Identify the variable(s) you can analyze now, this is the variable
(s) of interest
c. Determine the primary dimensions of the variable of interest
d. Determine the type and scale of variable’s primary dimension
and what values it can take
e. Determine whether you can order variable’s values (from the
smallest to the largest)
f. Determine whether this is an input variable or result
g. Determine how the program uses this variable
h. Determine whether other variables are related to this one
Analyze the variable and create tests
a. Partition the variable (its primary dimension)
- if the dimension is ordered, determine its sub-ranges and
transition points
- if the dimension is not ordered, base the partitioning on
similarity
b. Lay out the analysis in classical boundary/equivalent table.
Identify best representatives
a. Create test for the consequences of the data entered, not just
input filter
b. Identify secondary dimensions. Analyze them in classical way
c. Summarize your analysis with a risk/equivalence table
Generalize to multidimensional variables
a. Analyze independent variables that should be tested together
b. Analyze variables the hold results
c. Analyze non-independent variables. Deal with relationships
and constrains
d. Prepare for additional testing
e. Identify and list unanalyzed variables. Gather information for
late analysis
f. Imagine and document risks that don’t necessarily map to an
obvious dimension
‫ראה ספר מצורף באתר הקורס‬
6
 ‫דוגמא נוספות בטכניקת ה ‪domain‬‬
‫איכון ירי ארטילרי – איך לבדוק את דיוק פגיעת פגז‬
‫גודל המטרה הוא ‪10 X 10‬‬
‫הבעיה אמתית לחלוטין יש לקבוע כמה פגזים יבטיחו דיוק‬

‫‪Graphical visualization of example‬‬

‫‪#10‬‬ ‫‪X2‬‬

‫‪2‬‬ ‫‪2‬‬
‫‪X1 + X2 > 100‬‬
‫‪2‬‬ ‫‪2‬‬
‫‪X1 + X2 < 100‬‬
‫‪X1‬‬
‫‪R = √100‬‬
‫‪2‬‬ ‫‪2‬‬
‫‪X1 + X2 = 100‬‬

‫‪7‬‬
 ‫לסיכום ‪DOMAIN TESTING‬‬
‫‪ ‬האנליזה ל ‪ Domain‬היא אסטרטגית דגימה שמאפשרת להסתדר עם כמות מרובה מדי של‬
‫בדיקות‬
‫‪ ‬הדרך המסורתית לניתוח מתייחסת לקלט ופלט של ערכים נומריים‬
‫‪ ‬ניתוח הגבולות הוא האופטימאלי לחשיפת סוגי טעויות שונים כמו קודדו קצוות לא מתאים או‬
‫דו משמעותי של הגדרות ערכים חוקיים ולא‪ .‬למרות זאת ישנם תחומי טעות אחרים‬
‫שהשיטה אינה חושפת‬
‫‪ ‬לעיתים קרובות הניתוח נראה מכני ורוטיני (נתינת שדה נומרי והגדרת ערכי הקצה שלו) אנו‬
‫עושים מה שאנחנו יודעים אולם כאשר מתחשבים בסיכון הוספנו שיטת ניתוח קצת יותר‬
‫מורכבת‬
‫‪ ‬במקום לחשוב אנו יכולים לדרוש מראש שכל הבדיקות (לאחר בחינת הסיכונים) יתבצעו‪,‬‬
‫עלינו לאמן את הבודקים בזהויי המחלקות הזהות ובבדיקות מונחות סיכונים באופן כללי‪.‬‬
‫כאשר יתגלו סיכונים חדשים המשויכים לשדה או למשהו אחר ‪ ,‬תוך כדי בדיקה ביכולתם‬
‫לנתח מחדש על מנת להגיע למידה אופטימאלית של בדיקות‬
‫‪8‬‬
 :‫ שאלה מספר‬.A .B
Graphical visualization of example #10 Valid values of correct
__________________________ X2 equivalence class for X1, x2
__________________________ X12+ X22 > 100
might be:
__________________________ X12+ X22 < 100 9,0
__________________________ X1 -9,0
R = √100
__________________________ 2 2
X1 + X2 = 100

.C .D .E
Invalid values of correct Invalid values of correct Valid values of correct
equivalence class for X1, x2 might equivalence class for X1, x2 might equivalence class for X1, x2
be: be: might be:
11 , 1 12 ,11 8,0
0,-10 -6.5,0 -6.5,0

9
User Story and Testing

10
‫מושגי ייסוד לבדיקות‬
‫דרישות הבדיקה – ‪Test Requirements‬‬

‫‪Test Cases‬‬ ‫מקרי הבדיקה –‬

‫משתנים בבדיקה – נכנסים‪ ,‬בתהליך‪ ,‬תוצרים ‪(Variables) -‬‬

‫גבולות הבדיקה – ‪Test Boundary‬‬

‫מקרים מייצגים – ‪Representative Cases‬‬

‫‪Test coverage‬‬ ‫כיסוי הבדיקה –‬

‫סביבת הבדיקה – ‪Test Environment‬‬

‫‪Test Execution‬‬ ‫הרצת בדיקות ‪-‬‬

‫תוצרי ההרצה – ‪Test output‬‬

‫תוצאות הבדיקה ‪Test results (outcome) -‬‬

‫‪11‬‬
12
  Test with Visa, MasterCard, and
The story American Express (pass)
As a:  Test with Diner's Club (fail)
Customer  Test with good, bad, and missing
I can card ID numbers
Pay for a purchase with a  Test with expired cards
credit card  Test with different purchase
So the purchase will be in real amounts (including one over the
time (from home) card’s limit)

13
 ‫דרישות הלקוח‬ ‫מקרי בדיקה‬ ‫תסריטי‬
(Customer Requirements)
‫דרישות לבדיקה‬ ) TEST CASES ( ‫בדיקות‬
CR a (Test Requirements) TB 1 (Test Scripts)
CR a.1 TS 1:
TR 1 TC 1.1 TC 1.1
CR a.2 TR 1.1 TC 1.1.2 TC 1.2
CR b TR1.2 TC 1.1.3 TC 2
CR b.1 TR1.3 TC 1.3
TC 1.1.4
CR c M:N TR 2 N:M TC 1.2
TS 2:
TC 3
CR d TR2.1
TC 1.3 TC 1.1
CR e TR2.2 TC 2.2
TR 2.3 TB 2
CR e.1 TC 3
TR 2.4 TC 2.0 TC 1.1
CR e.1.1 TR 3 TC 2.1 TC 2.2
CR e.2 …. TC 2.2 TS 3:
RC f ….. …….
TB 3 ,,,,,,,,
RC g TC…….

1
4
At least two out of the five statements, but possibly
more than two share equivalents of the meaning:
 Mark the only statements that share equivalent
meaning
 Explain briefly the reason you have selected these
items
A[] B[]
A user story expresses one specific need that
a user has. It’s usually written out as a
couple of sentences. Most of the user stories
are written in the language of the users, so
any user should be able to read a user story
and immediately understand what it means.

C[] D[] E[]

A user story follows the template: A user story follows the template: A user story is a short description of
As a <role > As a <role > something that a customer will do at your
I can < goal> I can < goal> website or use your application/software,
So that <benefit> So that <benefit> focused on the value or result they gain
A Test case may cover more than one user A User story may cover more than one Test from doing this thing
story Case

15
15.1 Requirement/Specification based testing
15.2 What makes a bad requirement ?
15.3 How to produce a good requirement?
15.4 Requirement tree and hierarchy

16
 ‫תרגיל תיאור תמונה‬

‫‪17‬‬
 ‫סיפורי משתמש‬
‫‪User stories‬‬
‫התמחרות וניתוח דרישות‬
‫בדיקת היתכנות‬

‫מפרט דרישות‬

‫אימות דרישות‬

‫דו"ח היתכנות‬

‫מודל מערכת‬
‫תיעוד דרישות‬
‫דרישות משתמש‬
‫ומערכת‬
‫‪19‬‬
Business strategy (goals) – use the term SHOULD
1. High level requirements (process level-use cases) -> WHAT instead of HOW
1.1 Requirements for development (more specific) – use the word SHALL
…..

Goal:The airport should provide efficient, reliable service to travelers

1. High level: The pre-boarding system shall identify a passenger

automatically when arrives at the check-in desk.

For development:
1.1 If a passenger arrives at an airport, within a radius of 300 meters, his e-
ticket will be identified in the system.
1.2 The system will update the status of the passenger to “arrive” when e-
ticket is identified. 20
 A formal crucial document that contains the following:
1. Purpose of the software to be specified
The goal of this project is to provide a mobile application for Restaurant Clients
and a web-portal for Restaurant Owners and Company’s administrators.
2. Product/service description
3. Architecture
4. Users characteristics
5. Assumptions
6. Business high level requirements
7. Requirements for development
8. Priority, estimation
9. Limitations
10. Functional/Non functional requirements 21
 Correct
 Unambiguous (all statements have exactly one interpretation)
 Complete (where TBDs are absolutely necessary, document why the
information is unknown, who is responsible for resolution, and the deadline)
 Consistent
 Ranked for importance and/or stability
 Verifiable (avoid soft descriptions like “works well”) -testable
 Modifiable (evolve the Requirements Specification only via a formal change
process, preserving a complete audit trail of changes)
 Does not specify any particular design
 Traceable (cross-reference with source documents and spawned documents). 22
23
1. Write a user story that describe the way of
synchronization between sound and pictures
motion in movies

2. Extract the corresponding goals, requirements

3. Define pseudo code for testing this story

(optional)
24
 ‫?‪What is the specification‬‬
‫‪ ‬האם הספציפיקציה יציבה‬
‫‪ ‬תחת בקרת תצורה‬
‫‪ ‬האם היא צריכה להיות‬
‫‪ ‬מהם ההנחות הנוספות שהספציפיקציה מסתמכת עליהן‬
‫‪ ‬מספר אלמנטים של המוצר אינם מוגדרים ‪ -‬משום שהצוות מבין אותו או אולי‬
‫נמצא במסמך אחר (שלא הופץ)‬
‫‪ ‬הגדרה לא מפורשת‬
‫‪ ‬מספר מימדים של המוצר אינם מוגדרים משום שינו מנגנון שליטה או מדרג טכני‬
‫‪ ‬הפער יכול להיות מאוד משמעותי‬
‫‪ ‬במקום לבצע מהלך לא נתמך "זה רע" (או לקוח לא יאהב את זה)‪ ,‬אתה יכול‬
‫להצדיק אסרטיביות ויוזמה מצידך‪.‬‬ ‫‪25‬‬
 ‫מה באמת אומרת הדרישה ?‬
‫‪ ‬רוב מה שנכתב על ניתוח ספציפיקציות רלוונטי לפירוט של מה לעשות‬
‫בפירוט מקרה מסוים בדף אחד או שנים‬
‫‪ ‬זה דווקא מעשי ונחמד‬
‫‪ ‬אבל בדרך כלל נקבל אלפי דפים או יותר ואז‪:‬‬
‫‪ ‬זה מפוזר על פני מספר מסמכים‬
‫‪ ‬יכולה להיות הפניה הדדית ביניהם‬
‫‪ ‬יכול להיות שימוש לא נכון ואי אחידות לשונית בין החלקים‬

‫‪ ‬מי שקורא את המסמכים הללו בסובל בדרך כלל מכאב ראש של עודף מידע‬
‫‪ ‬יכולות קריאה ואסטרטגיה הינם הכרחיות לצורך ניתוח מסמכי דרישה‬

‫‪26‬‬
 ‫איך מה שנאמר נאמר‬
‫ ערפול‬
?‫ מה נכון‬,‫ ניתן להבנה במספר משמעויות‬
‫ התאמה‬
‫ לתיעוד של הבדיקות‬,‫ האם מספק מספיק מידע לתכנות‬
‫ שלמות‬
:‫ עד כמה זה מכסה את‬
‫אוסף התכונות‬ 
‫ מקרי מדגם‬USE CASES 
‫תסריטי משתמש‬ 
).‫ מצבי שגיאה ובו‬,‫אינפורמציה רלוונטית לבדיקות (גבולות‬ 

Writing requirements is hard! There is no simple, formulaic approach to software specification. High-quality
requirements begin with proper grammar, accurate spelling, well-constructed sentences, and a logical
organization
Adapted from Karl E. Wiegers, More about Software Requirements, Microsoft Press, 2006.
27
‫אם כך נשאל ‪ -‬מה זה אומר על המוצר ?‬
‫‪ ‬נכונות ‪Correctness‬‬
‫‪ ‬האם מתאר במדויק את התוכנה‬
‫‪ ‬מחלוקת ‪Controversy -‬‬
‫‪ ‬על איזה חלק ישנה מחלוקת מי הבעלים ‪ the stakeholders‬ועל מה אינם מסכימים‬
‫‪ ‬התאמה ‪Adequacy‬‬
‫‪ ‬האם זה מספק מספיק מידע לתכנות תעוד ובדיקות‬
‫‪ ‬שלמות – ‪Completeness‬‬
‫‪ ‬האם מכסה את כל התיפקודים‬
‫‪ ‬עיצוב –‬
‫‪ ‬האם ביכולתך לאמור שמפרט טעויות בעיצוב‬
‫‪ ‬האם מובן‪,‬שמיש‪,‬ניתן ללימוד‪,‬עכיב‪,‬מתאים לשוק‬
‫‪ ‬האם מגדיר את המיקום והתנאים לתוכנית‪/‬מתכנת בנושאי שגיאות‬

‫‪28‬‬
 ‫מה זה אומר על בדיקות ?‬
‫מוקדם בפרויקט ניתן לסקור את מסמכי הדרישות ולהפיק את המשמעויות עבור הבדיקות‪ ,‬ניתן אפילו להתכונן‬
‫ולשנותם לצורך העניין‪.‬‬
‫‪ ‬המשמעויות עבור עיצוב הבדיקות‪:‬‬
‫איזה טכניקת בדיקות תהיה המתאימה ביותר לפרויקט‬ ‫‪‬‬
‫האם דרושה הכשרה נוספת או כלים חדשים‬ ‫‪‬‬
‫האם יש דרש לפשט (או לשנות) את המוצר כך שיהיה יותר קל‪ ,‬פשוט או יותר זול או אולי מובנה יותר בפשטות‪.‬‬ ‫‪‬‬
‫כמה מחקר דורש הפרויקט‪.‬‬ ‫‪‬‬

‫‪ ‬האם לצוות שלך יש את הידע היכולת והקשרים?‬

‫‪ ‬לוח הזמנים והמשאבים לבדיקות‪:‬‬
‫מתי תקבל תוצרים מאחרים‬ ‫‪‬‬
‫מתי עליך למסור את העבודה‬ ‫‪‬‬
‫מה נחוץ לך על מנת להשלים את העבודה‬ ‫‪‬‬
‫האם איזו התחייבות בדרך אינה סבירה‬ ‫‪‬‬

‫‪Testability support ‬‬

‫‪29‬‬
 Definitive
Good Bad
As a User, I want to sign up via email and There has to be a way to authenticate.
password so that I can access my account.

Verifiable
Good Bad
As Administrator, I want to download a CSV file with all
I want to download the list of all users
users in a system via a web interface so that I can use it in
marketing. in CSV or Excel.
Scenario
Given User has admin permissions
When User navigates to administrative panel.
And User selects to download a CSV. https://anvileight.com/en/blog/2017/06/22/software-
Then CSV file with email, first name and last name gets requirements-specifications-good-and-bad-examples/
downloaded. 30
 ‫‪ .1‬שאלה מספר‪:‬‬ ‫‪.2‬‬
‫לקוח מסוג פרימיום יכול לבצע הזמנה‬
‫‪Bad‬‬ ‫באמצעות האפליקציה כך שאם עלות‬
‫__________________________‬
‫__________________________‬ ‫‪requirement‬‬ ‫הפריטים מעל ‪150‬ש"ח לא יחויב בדמי‬
‫משלוח‬
‫__________________________‬
‫__________________________‬ ‫‪Good‬‬
‫בעת כניסה למסך הורדת אפליקציה יוצג‬
‫__________________________‬ ‫‪requirement‬‬ ‫תפריט אבטחה הכולל את ההרשאות‬
‫הנדרשות מהמשתמש‬

‫‪.3‬‬ ‫‪.4‬‬ ‫‪.5‬‬

‫משתמש יוכל להגדיר ללקוח‬ ‫‪Good‬‬
‫משתמש יוכל להפיק דו"ח‬
‫קיים את תאריך החיוב‬
‫הכנסות לפי חודש‬ ‫‪requirement‬‬
‫במערכת‬
‫משתמש יוכל להגדיר ללקוח‬ ‫‪Bad‬‬
‫משתמש יוכל להפיק דו"ח‬
‫קיים את תאריך החיוב‬ ‫‪requirement‬‬
‫הכנסות לפי חודש‬
‫במערכת‬
‫‪31‬‬
32
 The Formula

Re(f)  P(f)*C(f)
 Re(f) - Risk Exposure of function f
 P(f) - Probability of a fault in function f
 C(f) - Cost related to a fault in function f

33
Problems with tradition
 Sequence of decisions
 Stages  responsibility  capability  objectives
 Guidance to developers and testers
 None, except generic, text book mantras
 “demonstrate software meets requirements”
 Input of stakeholders
 Only when system/acceptance tests reveal problems
 Far too late!
 Decision making
 Timescale driven in early stages
 Crisis driven towards the end
 Unsatisfactory all round.
35
Risk-based testing
assess define test test techniques,
Plan product risks objectives products to test

Schedule
Stakeholder responsibility
estimation
Involvement process

Decide Implement
focused test
assess risk-based
design and
product risks test reporting
execution
Slide 36 Slide
36
 Risk-based test planning
 If every test aims to address a risk, tests can be prioritized by risk
 It’s always going to take too long so…
 Some tests are going to be dropped
 Some risks are going to be taken
 Proposal:
 The tester is responsible for making the project aware of the risks being
taken
 Only if these risks are VISIBLE, will management ever reconsider.

37
 Risk response planning
 Do nothing!
 Pre-emptive risk reduction measures
 information buying
 process model
 risk influencing
 contractual transfer
 Reactive risk reduction measures
 contingency plans
 insurance
 The risk that’s left is the residual risk.
38
Why use risks to define test objectives?
If we focus on risks, we know that bugs relating to
the selected mode of failure are bound to be
important.
If we focus on particular bug types, we will probably
be more effective at finding those bugs
If testers provide evidence that certain failure modes
do not occur in a range of test scenarios, we will
become more confident that the system will work in
production.
39
Master Test Planning process
Risk • Consult business, technical staff
Tester Activity
Identification • Prepare a draft register of risks
• Discuss risks
Workshop Risk
Analysis • Assign probability and consequence scores
• Calculate exposure
• Formulate test objectives, select test technique
Tester Activity
Risk • Document dependencies, requirements, costs, timescales for
Response testing
• Assign Test Effectiveness score
• Nominate responsibilities
Test • Agree scope of risks to be addressed by testing
Review and Decision
Scoping
• Agree responsibilities and budgets

Tester Activity Test Process • Draft the test process from the Test Process Worksheet
Definition
• Complete test stage definitions 40
Risk and goal-based reporting
Project Phase
PI Drivers Ass. Obj. Reqs Design Build Integ Systest UAT Trial Prod.

Business goals

Coverage goals

Risks

Progress towards goals is

clearly seen. Outstanding
risks are highly visible.

Slide 41 Slide
41
 Risk-based reporting
Planned
start today
end

all risks
‘open’ at the
start

residual risks of
releasing TODAY

Slide 42 Progress through the test plan 42

 Test products through the lifecycle
master test
initial risk test planning test
assessment objectives stages

test process
star today
Plann definition
ed
t end test specification

test plan/
procedures

test execution
Progress through the test plan

test results analysis test log

release risk
assessment

43
Risk-based test approach: planning
 RBT approach helps stakeholders:
 They get more involved and buy-in to the approach
 They have better visibility of the test process
 RBT approach helps testers
 Approval to test against risks in scope
 Approval to not test against risks out of scope
 Clearer test objectives upon which to design tests
 RBT approach helps developers
 Specifies their responsibility for testing in detail
 “No hiding place”.

44
 :‫שאלה מספר‬ .a .b
Risk-based testing (RBT) is an ‫סיכון הוא הנזק האפשרי לארגון מעשייה‬
__________________________ organizational principle that helps to ‫ על מנת‬.‫(או עשייה) של נושא מסויים‬
__________________________ prioritize testing the features and ‫לנהל אותו יש להעריך מהו הסכוי שהנזק‬
__________________________ functions of a software according to ‫יתממש ולחשב על פיו את מדד הסיכונים‬
__________________________ the probable risks of failure, the need ‫ כך נייצר גודל אובייקטיבי להשוואה בין‬.
__________________________ of the function, ‫סיכונים שונים ונוכל לקבוע סדרי‬
‫עדיפויות לטיפול‬
c .d .e
If every test aims to address a risk,
tests can be prioritized by risk, It’s
always going to take too long so…
Some tests are going to be dropped
Some risks are going to be take

45
 ‫מה היה בשיעור זה‬
‫מה להתכונן‬
 Reminder – domain testing
‫לשיעור הבא‬
 From users story to a testing story o
 Requirements engineering & specification
testing
15.1 Requirement/Specification based
testing
15.2 What makes a bad requirement ?
15.3 How to produce a good
requirement?
15.4 Requirement tree and hierarchy
 Risk Based testing
16.1 Risk and risk management 46
16.2 Risk based task planning
‫להתראות בשבוע הבא‬

‫‪47‬‬