Shadowing Practice: How to Write Test Cases for Manual Testing? - Learn English Speaking with Video
בחר מצב תרגול
כל מצב פותח חדר תרגול במסך מלא.
119 משפטים
אם המשפטים קצרים או ארוכים מדי, לחץ על ערוך כדי להתאים אותם.
1
QA Madness.
2
How to write test cases for manual testing.
3
QA specialists have to deal with different kinds of documentation.
4
In today's video, I will tell you about one of such artifacts, a test case, what it is, and how to create one.
5
A test case is a set of actions you execute to verify a particular software feature or functionality.
6
Using test cases, we can make sure that a certain feature works as expected, or discover that it does not work properly.
7
There are three types of test cases.
8
Positive, negative, and destructive.
9
Positive test cases use valid inputs to verify that software does what it is supposed to do.
10
For example, when a user enters valid credentials, they can sign into the system.
11
Negative test cases use invalid inputs.
12
Their mission is to verify that the software does not do what it is not supposed to do.
13
For example, if a user enters an incorrect login or password, they cannot sign in.
14
Destructive test cases are created to learn what the system can handle until it breaks or destructs.
15
For this, a software tester can fast click on the sign in button to see what happens in this case.
16
Another example is a significant increase in web page load, it aims to check how many users a system can handle.
17
Like every document, a test case has a specific format.
18
It consists of eight elements, 1.
19
ID, 2.
20
Summary, 3.
21
Preconditions, 4.
22
Steps, 5.
23
Postconditions, 6.
24
Expected Results, 7.
25
Actual Results, 8.
26
Status.
27
Let's take a closer look at each of them.
28
Number 1.
29
ID.
30
As you can guess, it is the name of a test case.
31
An ID is a unique combination of letters and numbers.
32
As a rule, it is related to the project name, and indicates the number of a test case in the sequence.
33
For example, if we test a website called BuyOnline, you can name the first test case Bow1.
34
The second one will be Bow2, and so on.
35
Number 2.
36
Summary.
37
A summary is the main idea of a test case, a brief description of its contents.
38
For example, check adding a product to a wishlist.
39
Number 3.
40
Preconditions.
41
Preconditions are a list of actions a user needs to perform before executing a test case.
42
For example, a user should be logged in.
43
In this situation, you should include the credentials so a person working with this test case can reproduce it.
44
Preconditions are not mandatory, so you do not need to include this clause in every test case.
45
Number 4.
46
Steps.
47
Steps are the description of the actions required for verification.
48
Steps in a test case can go like this.
49
1. Open a website.
50
2. Open a product page.
51
3. Add a product to the wishlist.
52
Number 5.
53
Post conditions.
54
These are one or several actions that return the system to its original state.
55
For example, remove an item from the wishlist.
56
Just like preconditions, post conditions are not mandatory.
57
Number 6.
58
result.
59
It is what we expect to see getter achieve after the successful test case execution.
60
Back to our example, we expect to see a message about an item being added to a wishlist.
61
We also expect to find a product on the list after opening the corresponding section.
62
Number 7.
63
Actual result.
64
If there is a bug in the system, the actual result will differ from the expected one.
65
So, The actual result is what we get after the test case execution.
66
For example, the success message isn't displayed or the item doesn't appear on the wishlist.
67
Number 8.
68
Status.
69
It is the conclusion in your test case.
70
In this clause, you summarize the outcome in one word.
71
The most common statuses are success, failed, and blocked.
72
It depends on whether there are bugs in the software or not.
73
Keep in mind that test cases come in many different formats.
74
For example, sometimes you can use brief test cases with only four elements.
75
Summary, Priority, Steps, and Expected Result.
76
The sections can also have different names.
77
You can see software testers using the word inputs instead of steps, and outputs instead of results.
78
Moreover, you can find an alternative definition of post conditions.
79
Some use this term to describe the state of the system after test execution.
80
In this case, you may find it a bit complicated to tell the difference between post conditions and expected results.
81
To choose the correct format for the test case, you can look into the existing documentation or address other team members to specify this information.
82
The preferred format can depend on both a company's practices and the complexity of a tested feature.
83
Every test case should be comprehensive.
84
It should not depend on other test cases.
85
The description of the steps and expected results should be accurate and clear.
86
Make sure to include the necessary information, avoid vague formulations and excessive details.
87
All team members should be able to understand and execute a test case, even if they interact with software for the first time.
88
It should be easy to match a test case with the requirements in the product documentation.
89
All test cases should be repeatable.
90
In other words, a user should be able to reproduce a test case over and over again.
91
Finally, aim to create reusable test cases.
92
will help you to spend less time creating test documentation in the future.
93
There are several common mistakes QA engineers tend to make during test case writing.
94
The first is writing two abstract summaries.
95
The summary should be concise but specific.
96
For example, instead of the generalized check the wishlist functionality you can write check adding a product to the wishlist.
97
Another common mistake is interesting unclickable links.
98
When you insert a link in the text, make it active so another team member can click and open the intended page.
99
It is much more convenient than copying the text and pasting it in another tab.
100
And always make sure the link leads to the right page.
101
Providing two detailed explanations is not a good idea either.
102
Be specific, but not too specific.
103
There is no need to state the obvious through a very detailed description.
104
For example, it is enough to right-click the wishlist button.
105
Specifying
106
that it is the round blue wishlist button on the right
107
to the buy now button below the product description is not necessary.
108
Finally, the lack of details can also be confusing.
109
It is okay to be more specific when you add some tech directions.
110
It will be helpful for newbies or those who are not familiar yet with the technology you mentioned.
111
The example is on the screen.
112
So these are the basics of test case writing.
113
Let me finish this guideline with a tip.
114
To check how good your test case is, show it to a person who does not know anything about the project you are working on.
115
The questions you are going to hear will highlight the weak points of your test case.
116
You can find more examples of test cases in the article on our blog.
117
The link is in the description.
118
Subscribe to our channel to learn more about test documentation in the future.
119
See you in the next video.
הורד אפליקציה
כל מה שאתה צריך כדי לדבר בשטף
הגיית AIציון לכל משפט
תרגול IPAשלוט בכל צליל
אוצר מיליםבנה את מאגר המילים שלך
משחק אוצר מיליםלמד תוך כדי משחק
FOR YOU
המלץ על סרטון
B230 משפטים
7 Phases of Penetration Testing Explained | Think your system is safe? #cybersecurity #pentesting
Daily ConversationWorking Adults
B22
24 משפטים
Reading Test 1 - Seccion 2 Good customer service in retail.
Daily ConversationWorking Adults
B21
227 משפטים
How to Use Google Gemini Al (Full Tutorial)
Daily ConversationWorking Adults
B21
53 משפטים
AQL Special Inspection Levels: How Do They Work?
Daily ConversationWorking Adults
B22
221 משפטים
Testing the Burger King website | Exploratory Testing | QA
Daily ConversationWorking Adults
C12
43 משפטים
SDLC Vs STLC: Software Development Life Cycle and Software Testing Life Cycle
Daily ConversationUniversity StudentsWorking Adults
B23
63 משפטים
How To Land Your First Junior Dev Role
Daily ConversationUniversity StudentsWorking Adults
B23
163 משפטים
The 2025 Step by Step Guide to PASSING your NEBOSH NG1/IG1 OBE Open Book Exam FIRST TIME!
Daily ConversationWorking Adults
B155
34 משפטים
PART 1 TEST 4 EST 2026
Daily ConversationWorking Adults
C12
65 משפטים
What Is REST API? Examples And How To Use It: Crash Course System Design #3
Daily ConversationUniversity StudentsWorking Adults
C12
236 משפטים
The 7 Quality Control (QC) Tools Explained with an Example!
Daily ConversationUniversity StudentsWorking Adults
C13
56 משפטים
What is SMT (Surface Mount Technology)? PCB Assembly (Part 3)
Daily ConversationWorking Adults
אוצר מילים והערות הגייה לשיעור הזה
שיעור הדיבור הזה ברמה B2 מבוסס על הסרטון “How to Write Test Cases for Manual Testing?”. המילים שחוזרות הכי הרבה: test, example, result, wishlist, steps. בסרטון הזה יש 119 משפטים ו-1194 מילים לתרגול Shadowing. הדיבור נמשך 7:35. הדובר מדבר בקצב טבעי של כ-157 מילים בדקה, קרוב לשיחה יומיומית. 84% מהמילים נמצאות בין 3,000 המילים הנפוצות ביותר באנגלית; כדאי ללמוד את השאר לפני שמתחילים.
אוצר מילים מרכזי בסרטון הזה
15 המילים המתקדמות ביותר בסרטון, עם ההגייה והמשמעות שלהן:
| מילה | הגייה | משמעות |
|---|---|---|
| verify פועל | /ˈvɛɹɪfaɪ/ | וידא |
| execute פועל | /ˈɛksɪˌkjuːt/ | להוציא להרוג |
| depend פועל | /dɪˈpɛnd/ | היה תלוי |
| reproduce פועל | /ˌɹi.pɹəˈdus/ | התרבה |
| destructive שם תואר | /dɪˈstɹʌktɪv/ | הרסני |
| clause שם עצם | /klɔːz/ | פסוקית |
| mandatory שם תואר | /ˈmæn.dəˌtɔɹ.i/ | הכרחי |
| concise שם תואר | /kənˈsaɪs/ | תַּמְצִיתִי |
| summarize פועל | /ˈsʌməˌɹaɪz/ | סיכם |
| correspond פועל | /ˌkoɹəˈspɑnd/ | הִתְכַּתֵּב |
| confuse פועל | /kənˈfjuːz/ | בלבל |
| verification שם עצם | /ˌvɛ.ɹə.fɪˈkeɪ.ʃən/ | וידוא |
| vague שם תואר | /veɪɡ/ | עמום, מעורפל |
| insert פועל | /ɪnˈsɝt/ | לְהַכְנִיס |
| subscribe פועל | /səbˈskɹaɪb/ | נִמְנָה |
דקדוק בסרטון הזה
המבנים שהדובר משתמש בהם הכי הרבה, עם המילים המדויקות מהסרטון:
| מבנה | בסרטון |
|---|---|
| סביל (Passive voice) be + past participle — הדגש הוא על מה שקורה, לא על מי שעושה את הפעולה | are created · should be logged · being added |
| משפטי זיקה (Relative clauses) who / which + clause — מידע נוסף על אדם או דבר | those who are · person who does |
הגייה ששווה לשים לב אליה
- הצלילים של “sh” ו-“zh”: precondition /ˈpɹiːkənˌdɪʃən/, documentation /ˌdɑkjəmɛnˈteɪʃən/, credential /kɹɪˈdɛnʃəl/, verification /ˌvɛ.ɹə.fɪˈkeɪ.ʃən/
- מילים ארוכות — שימו לב להטעמה: precondition /ˈpɹiːkənˌdɪʃən/, documentation /ˌdɑkjəmɛnˈteɪʃən/, mandatory /ˈmæn.dəˌtɔɹ.i/, generalize /ˈd͡ʒɛn.(ə.)ɹə.laɪz/, repeatable /ɹɪˈpiːtəbəl/
צלילים שדוברי עברית מתקשים בהם:
- /æ/ — פתוח יותר מה-“אֶ” העברית, לא כמו “a” ב-“cup”: mandatory /ˈmæn.dəˌtɔɹ.i/, artifact /ˈɑɹtɪfækt/, interact /ɪn.təˈɹækt/, password /ˈpæs.wɜɹd/, abstract /ˈæbˌstɹækt/
- /r/ — הלשון לא נוגעת בשום מקום, לא ה-“ר” הגרונית: precondition /ˈpɹiːkənˌdɪʃən/, verify /ˈvɛɹɪfaɪ/, credential /kɹɪˈdɛnʃəl/, tester /ˈtɛstəɹ/, reproduce /ˌɹi.pɹəˈdus/
- עיצור קולי בסוף מילה — /b/, /d/, /g/, /z/, /v/ בלי להפוך אותם לאטומים: depend /dɪˈpɛnd/, destructive /dɪˈstɹʌktɪv/, clause /klɔːz/, generalize /ˈd͡ʒɛn.(ə.)ɹə.laɪz/, summarize /ˈsʌməˌɹaɪz/
איך לתרגל עם הסרטון הזה
- הקשיבו לכל הסרטון פעם אחת בלי לדבר, ורשמו את המילים שאתם לא מכירים.
- התחילו במהירות 0.75×, תרגלו Shadowing משפט אחר משפט, וחזרו למהירות רגילה כשזה מרגיש קל.
- הקליטו את עצמכם והשוו למקור, תוך תשומת לב למילים כמו verify, execute, depend.
מהי טכניקת השאדואינג?
שאדואינג היא טכניקת למידת שפה מבוססת מדע שפותחה במקור להכשרת מתורגמנים מקצועיים ופופולרית על ידי הפוליגלוט ד"ר אלכסנדר ארגואלס. השיטה פשוטה אך עוצמתית: אתה מקשיב לאודיו באנגלית ילידית וחוזר עליו בקול רם מיד — כמו צל העוקב אחרי הדובר עם עיכוב של 1–2 שניות בלבד. בניגוד להאזנה פסיבית או תרגילי דקדוק, שאדואינג מכריח את המוח והשרירים בפה לעבד ולשחזר דפוסי דיבור אמיתיים בו זמנית. מחקרים מראים שזה משפר משמעותית את דיוק ההגייה, האינטונציה, הקצב, הדיבור המחובר, הבנת השמיעה ושטף הדיבור — מה שהופך אותו לאחת השיטות היעילות ביותר להכנה לIELTS Speaking ולתקשורת באנגלית בעולם האמיתי.