쉐도잉 연습: How to Write Test Cases for Manual Testing? - 영상으로 영어 말하기 배우기
레슨 만드는 중...
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.
✨ 추천 영상
C11
245 문장
QA Automation Interview Questions and Answers
Business EnglishInterview EnglishUniversity Students
C13
47 문장
Seven Testing Principles: Software Testing
Business EnglishUniversity StudentsWorking Adults
C12
249 문장
How to Present a Patient Case: The Signpost Method
Business EnglishUniversity StudentsWorking Adults
C11
227 문장
How to Use Google Gemini Al (Full Tutorial)
Business EnglishUniversity StudentsWorking Adults
B21
55 문장
How to Write a Cover Letter That Actually Gets Read | Indeed
Business EnglishInterview EnglishUniversity Students
C177 문장
Unit 1.1: Introduction to Business Management - IB Business Management
Cambridge Exam PrepBusiness EnglishUniversity Students
C12
65 문장
What Is REST API? Examples And How To Use It: Crash Course System Design #3
Business EnglishUniversity StudentsWorking Adults
C11
85 문장
AI Can Write Code. And That’s the Problem.
Business EnglishUniversity StudentsWorking Adults
C12
78 문장
Why 95% of Android Developers Get Use Cases Wrong
Business EnglishUniversity StudentsWorking Adults
C141 문장
🚨 Most organizations don't fail ISO/IEC 27001 because they don't understand the standard...
Business EnglishUniversity StudentsWorking Adults
C12
32 문장
How to Formulate Research Questions: From Ideas to Actionable Data
Business EnglishUniversity StudentsWorking Adults
C16
190 문장
🔥Launching Analog VLSI Mastery : Cohort (0-100) || A Complete Placement Guide || Himanshu Agarwal
Business EnglishInterview EnglishUniversity Students
영어 회화 연습에 유용한 테스트 케이스 작성 강의, 어떻게 활용할까?
이 비디오는 QA 전문가가 테스트 케이스를 작성하는 방법을 설명하는 내용인데, 영어 학습자에게도 흥미로운 점이 많습니다. 전문 용어가 포함된 대화는 영어 실력 향상에 좋은 기회로, 특히 shadowspeak 연습에 적합합니다. 전문 분야의 대화를 따라하는 건 어휘와 발음, 리듬을 동시에 연습할 수 있는 좋은 방법이죠.
일상 회화에 쓸 수 있는 핵심 표현 5가지
- "verify a particular software feature" - 특정 소프트웨어 기능을 검증하다. 비슷한 표현으로 "check a specific function"도 사용할 수 있습니다.
- "use valid inputs" - 유효한 입력값을 사용하다. "valid" 대신 "correct"를 써도 되지만, 전문 용어에서는 "valid"가 더 자주 쓰입니다.
- "reproduce it" - (문제를) 재현하다. 기술적인 대화에서 자주 나오는 표현으로, "recreate"와 비슷한 뜻입니다.
- "a brief description" - 간단한 설명. "summary"와 같은 의미로 사용되며, 일상에서도 "short explanation"으로 바꿔쓸 수 있습니다.
- "as expected" - 예상대로. "as planned"나 "as intended"와 비슷하며, 결과를 설명할 때 자주 사용됩니다.
이 비디오로 shadow speak 연습하는 방법
이 비디오는 속도가 조금 빠르고 전문 용어가 많아 처음에는 어렵게 느껴질 수 있습니다. shadowspeaks 연습을 할 때는 다음 단계를 따라보세요. 먼저 비디오를 2-3번 듣고 전체 내용을 이해합니다. 그다음 문장을 짧게 나눠서 따라합니다. 예를 들어 "A test case is a set of actions you execute to verify a particular software feature or functionality."라는 문장은 "A test case is a set of actions" → "you execute to verify" → "a particular software feature or functionality"로 나눠서 연습합니다. 발음이 어려운 단어는 "functionality"처럼 철자대로 말하는 게 아니라, "펑크셔널리티"가 아니라 "펑크셔널리티" (실제 발음은 /ˌfʌŋkʃəˈnæləti/)로 발음하며, 영어 발음 교정에 집중합니다. 마지막으로 전체 문장을 빠르게 따라하며 리듬을 익힙니다. 이렇게 연습하면 전문 용어도 익히고, 영어 회화 실력도 향상시킬 수 있습니다.
이 영상의 문법
화자가 가장 많이 쓰는 문형을 영상 속 실제 표현과 함께 정리했습니다.
| 문형 | 영상 속 표현 |
|---|---|
| 수동태 be + 과거분사 — 누가 하는지보다 무슨 일이 일어나는지에 초점 | are created · is related · should be logged |
| 관계절 who / which + 절 — 사람이나 사물에 대한 추가 정보 | those who are · person who does |
쉐도잉이란? 영어 실력을 빠르게 키우는 과학적 방법
쉐도잉(Shadowing)은 원래 전문 통역사 훈련을 위해 개발된 언어 학습 기법으로, 다언어 학자인 Dr. Alexander Arguelles에 의해 대중화된 방법입니다. 핵심 원리는 간단하지만 매우 강력합니다: 원어민의 영어를 들으면서 1~2초의 짧은 지연으로 즉시 소리 내어 따라 말하는 것——마치 '그림자(shadow)'처럼 화자를 따라가는 것입니다. 문법 공부나 수동적인 청취와 달리, 쉐도잉은 뇌와 입 근육이 동시에 실시간으로 영어를 처리하고 재현하도록 훈련합니다. 연구에 따르면 이 방법은 발음 정확도, 억양, 리듬, 연음, 청취력, 말하기 유창성을 크게 향상시킵니다. IELTS 스피킹 준비와 자연스러운 영어 소통을 원하는 분들에게 특히 효과적입니다.