你，適合當軟體測試/軟體品質工程師嗎？Are you suitable for a role as a software engineer in test (SET) /software quality assurance (SQA) /software development engineer in test (SDET)?

「軟體測試絕不只有手動驗證」

Medium｜Instagram｜Facebook

📢 如果此文章有幫助到你，請 按此追蹤 在台灣 IG 最多追蹤者關注的軟體測試的官方帳號 ⏤ 一日測試 IG (oneday.software) ，與我們保持高度互動，以獲取最新的軟體資訊與技術方案！

If this article has been helpful to you, please click here to follow the official account of the software testing with the most followers on Instagram in Taiwan ⏤ OnedaySoftware (IG: oneday.software). Stay highly engaged with us to get the latest software information and technical solutions!

「一日測試」希望這篇文章能快速的幫助到正在抉擇「測試」(Quality Assaurance, QA / Software Developement Engineer in Test, SDET) 與其他職位的職場新手讀者，至少，能以一個相對完整的全貌來認識刻板印象中的軟體測試開發！

“OnedaySoftware” hopes that this article can quickly assist career newcomers who are deciding between “testing” (Quality Assurance, QA / Software Development Engineer in Test, SDET) and other positions, at the very least, to gain a relatively comprehensive understanding of the often stereotyped field of software testing development!

▲ Source: https://www.vectorstock.com/

很常在社群中看到幾個很經典的問題：

1. 我要當測試嗎？
2. 當了測試是不是就只能一日測試、終身測試？
3. RD 才有開創性，QA 是不是很無聊，門檻也低，沒什麼技術？

通常也能看到好像很有道理的回答：

1. 測試在台灣的天花板就在那，你還往那走，我也幫不了你
2. 有 RD 做 RD，不要想不開
3. 可以寫程式何必當 QA ?

I often see several classic questions in the community:

1. Should I become a tester?
2. Does being a tester mean I’ll be stuck in testing forever?
3. Is being an RD (developer) the only way to be innovative, and is QA boring with low barriers and little technical value?

Typically, I also come across seemingly reasonable answers:

1. The ceiling for testing in Taiwan is there, if you keep heading in that direction, I can’t help you.
2. Let RDs be RDs, don’t overthink it.
3. If you can code, why choose QA?

▲ Source: PTT

當然單就 “測試” 這個職缺來探討，面向太廣，有可能是 IC 產業的測試專員，也有可能是 Field Trial 的測試工程師，更有可能是 App 手動的測試工程師……但無論是哪種測試工程師，一定都有其專業壁壘，而小弟的過往工作經驗著重在軟體測試工程，今天就來談談：你，適合當軟體測試開發嗎?

Of course, when discussing the role of “tester,” it covers a wide range, including IC industry test specialists, field trial test engineers, and manual app test engineers. But regardless of the type of test engineer, there are certainly professional barriers, and my past work experience has focused on software test engineering. Today, let’s talk about whether you are suitable to become a software test developer.

選擇第一份工作，身為鄉民的我，其實在當時也問過一樣的問題，選擇軟體測試開發當時的考量是：公司有名、老闆願意讓我還沒畢業前以實習的形式全薪雇用我、薪水在當時拿到的 offer 中是最高的 (即便只多台幣 1,000)。大家有沒有發現，我選擇了軟體測試當作是第一份工作的原因，沒有一個是跟專業領域有關的，所以能進入到軟體測試領域根本就是誤打誤撞進來的！🤦🏻‍♂️

When choosing my first job, I actually asked the same question at that time. My considerations for choosing software test development were: the company had a good reputation, the boss was willing to hire me full-time as an intern even before I graduated, and the salary offered was the highest among the offers I received at that time (even if it was just an extra 1,000 Taiwanese dollars, around USD 30). Did anyone notice that none of the reasons I chose software testing as my first job had anything to do with the professional field? So, entering the software testing field was entirely unexpected for me! 🤦🏻‍♂️

依稀記得當時面試官是這麼問的，「無聊且重覆的工作你喜歡嗎？」『我不排斥！(誰會喜歡？)』，其實，在當時我一直覺得軟體測試就是一個需要花勞力的工作，但沒關係，反正勤能捕拙，單一的重覆性工作會有多困難？所以看到上方似乎很有道理的回答，我不意外，但讓我驚訝的是原來刻板印象是會傳承的，因為十年前我聽到的也是這樣，所以，這篇文章就出現了！:)

I vaguely remember that the interviewer asked me, “Do you like boring and repetitive work?” and I replied, “I don’t mind it! (Who would like it?)” Actually, at the time, I always thought that software testing was a labor-intensive job. But it’s okay, I thought to myself, hard work pays off, how difficult could a single repetitive job be? So, when I see the seemingly reasonable answer above, I’m not surprised, but what astonishes me is that stereotypes can persist. Because what I heard ten years ago was similar. That’s why this article came to be! :)

先理解你要應徵的是哪種測試？

First, understand what type of testing position you are applying for.

眼尖的讀者或是對於軟體測試有些經驗的前輩一定會發現，我用的詞是「軟體測試開發」，而不是軟體測試。因為「測試」這個職位在台灣就業環境的解讀中已經多了一些既定的印象，而多了一個開發的詞，主要也是要強調這個職位是需要會寫程式的。其實有很多人問過我 Tester, QA, QC, QE, SDET…… 之間的差異在哪，但對很多人而言測試就是人力，不同的名稱與職位，只要跟「測試」扯上邊，就是給我測就對了！

Keen readers or those with some experience in software testing will undoubtedly notice that I used the term “software test development” rather than just “software testing.” This is because the term “testing” carries certain established connotations in the employment environment in Taiwan, and by adding “development,” I aim to emphasize that this position requires programming skills. Many people have asked me about the differences between Tester, QA, QC, QE, SDET… but for many, testing is seen as manual labor. Regardless of the various names and positions, as long as it’s related to “testing,” it’s all about testing for them!

在這裡想澄清一下，「測試」絕對不是只有大家可能會想到基本的手動驗證，BUT，反倒是基本的手動驗證最能奠定了一個產品的好壞，沒有碰觸到業務需求的測試會沒有發展的方向，日復一日，就真的會成為一個容易被取代的人力了，母湯。而在軟體測試這個領域之中，包含了需求的分析、測試計劃的產出、測試用例的發想、自動化腳本覆蓋、產品功能手動驗證、風險預警與揭露、系統服務業務監控、輿情分析，更多的測試角色可能斜槓了測試資料的產出、壓力測試方案的撰寫、測試環境的控制、CI/CD的建置 甚至是 測試平台的無中生有 或 以測試為出發點的產品生命周期統整方案的推動。所以，測試絕不僅僅只是手動的驗證，更多的是要靠平時的能力積累，在每個專案與任務中展現測試多元且核心的價值。

I’d like to clarify here that “testing” is by no means limited to the basic manual verification that people might think of. On the contrary, basic manual verification is often what determines the quality of a product. Without testing that touches upon business requirements, there’s no direction for development. Day in and day out, you’ll become easily replaceable labor. In the field of software testing, it encompasses requirement analysis, test plan creation, test case ideation, automated script coverage, manual product function verification, risk identification and disclosure, system service and business monitoring, sentiment analysis, and more. Many testing roles may involve generating test data, devising stress test plans, controlling testing environments, setting up CI/CD, or even creating testing platforms from scratch. It’s about integrating testing into the entire product lifecycle. So, testing is not just about manual verification; it’s about accumulating skills and showcasing the diverse and core value of testing in each project and task.

再確定你想要當的是哪種測試？

Make sure you determine the type of tester you want to pursue.

想當哪種測試，其實跟你怎麼理解「測試」這個角色有很大的關聯，如果這是一份工作，那就一定有其專業的領域。我們要做的是怎麼在這樣的角色下做到獨一無二或是很難被取代。臺灣比較著重硬體工程領域，尤其護國神山臺積電在全世界的表現舉足輕重，在軟體工程領域的表現相對較少，這也是為什麼在好幾年前，甚至是現在的系統，只要瞬間湧入大量流量，伺服器就會完全撐不住吐 Server Error。以前的我會想，系統撐不住為什麼不多開幾台？Auto-scaling 很難嗎？不過這又是另一個故事了……。

What type of testing you want to pursue is closely related to how you understand the role of “tester.” If this is a job, then it certainly has its own professional domain. Our goal is to figure out how to be unique and difficult to replace within this role. Taiwan tends to emphasize the hardware engineering field, especially with industry giants like TSMC playing a pivotal role worldwide. However, the performance in the software engineering field has been relatively limited. That’s why even several years ago and possibly today, systems experience complete server failures when hit with a sudden surge in traffic. I used to wonder, why not scale out the servers? Is auto-scaling difficult? But that’s another story…

在敏捷開發尚未成熟前，即便是時至今日大家都聽過敏捷開發，瀑布式開發的舊有印象一直讓人覺得「測試」就應該是產品釋出收尾的最後一關。沒東西出來就不能測，東西出來後又沒時間測，管他的先上了，上了有問題再修。週而復始的負向循環會讓本來不太重視軟體開發的環境更不重視產品生命周期的後面的階段，所以高品質、高穩定性、高可用性很自然而然就會被忽略了。

Before agile development matured, even to this day, the traditional perception of waterfall development has led people to think of “testing” as the final stage at the tail end of product release. No testing without anything to test, and no time for testing after something is released — just put it out there, and if there are issues, fix them later. This negative cycle that repeats itself often makes the environment, which didn’t initially prioritize software development, pay even less attention to the later stages of the product lifecycle. Hence, high quality, stability, and availability are naturally overlooked.

▲ Source: https://www.vectorstock.com/

以下列出比較適合「測試」這個職位的重要特質：完美主義者、具有抽離的能力、當機立斷的決心、隨時保持好奇心與熱情。

Here are important qualities that are well-suited for the “tester” position: perfectionism, the ability to detach, decisive determination, and a perpetual sense of curiosity and enthusiasm.

• 完美主義者：對於每一個需求的來源、所寫的每一行代碼都必須清楚，甚至於對產品到吹毛求疵的地步都不為過，細心發現問題且為用戶的體驗堅持，產品才會有好的品質。而單就產品最後一個測試環節的要求是不夠的，應該要從產品的初期一步一步的建立起「只要有心，人人都是測試」的想法，盡可能的挑戰需求方與點出風險的所在，讓產品設計與開發能在一個可控風險的情況下進行實作，也唯有這樣的想法才會對於開發寫出來的程式或架構設計給予不同思路的檢核。
• Perfectionist: For every source of requirements and every line of code written, clarity is essential. Even to the extent of scrutinizing the product for every tiny flaw is not excessive. Carefully identifying issues and maintaining a commitment to the user experience is what ensures product quality. However, just demanding quality in the final testing phase is insufficient. It should start from the early stages of product development, gradually establishing the idea that “anyone can be a tester if they have the mindset.” Challenge the requirements and pinpoint the areas of risk as much as possible, allowing product design and development to be implemented in a controlled risk environment. Only with this mindset can you provide different perspectives for reviewing the code and architectural design produced by the development team.
• 具有抽離的能力：知道自己要幹嘛，這裡提到的「知道自己要幹嘛」不是指你的興趣或是愛好，而是知道這個專案、這個任務要達到什麼樣的成果與目標，無論今天是看 Function的實作、Class的定義、模組的耦合、程式的規劃、系統之間的架構、功能的迭代、需求的初衷、產品的走向……逐一的抽離，身為測試才能理解到有些功能或執著其實可以抓大放小，這樣對於整個產品才會有全局觀。
• Ability to detach: Knowing what you’re supposed to do. Here, “knowing what you’re supposed to do” doesn’t refer to your interests or hobbies, but understanding what kind of results and goals the project or task should achieve. Whether it’s examining the implementation of functions, defining classes, analyzing module coupling, planning code, structuring system architecture, iterating on features, understanding the initial intent of requirements, or charting the product’s direction, being able to detach from each aspect is crucial. As a tester, you can comprehend that certain functions or details can be streamlined to maintain a holistic perspective of the entire product.
• 當機立斷的決心：一旦具有了抽離的能力或是鳥瞰的視角，對於產品的邊界與系統能力的取捨就會有優先級的排序，一旦遇到風險，可以在當下立即判斷是否繼續或放棄，選擇對當下最有利的決策讓產品的穩定性拉到最高。
• Decisive determination: Once you have the ability to detach or take a bird’s-eye view, prioritizing decisions regarding product boundaries and system capabilities becomes essential. When facing risks, you can swiftly assess whether to proceed or abandon, making the choice that is most advantageous at the moment to maximize product stability.
• 隨時保持好奇心與熱情：最重要的一點，對於所處環境的知識領域或產業走向是否仍具有好奇心，並有熱情與動力為了改善這個產品而讓自己的能力不斷的往上提升，無論是測試的方法論也好或是基本的 coding 能力，豐富的閱讀與文章的輸出也會是測試能力的培養與沉澱。
• Maintaining curiosity and enthusiasm at all times: Most importantly, whether you still possess curiosity about the knowledge domain of your environment or industry trends, and whether you have the passion and drive to continuously enhance your abilities for the sake of improving the product. Whether it’s testing methodologies or basic coding skills, enriching your reading and content creation will also be instrumental in nurturing and refining your testing capabilities.

面試者的經驗傳承

Interviewer’s Experience Inheritance

先後當過 阿里巴巴 1688.com 台灣校招的窗口、街口支付測試團隊負責人、阿福管家測試團隊負責人，面試了不下 200 人，其實有時候會覺得很可惜的是，蠻多軟體測試開發工程師的面試者對於自己的 Career Path 並沒有一個明確的目標，有時甚至換工作的原因或是找尋新的機會都不知道為什麼。

I’ve held positions as the contact person for Alibaba 1688.com Taiwan campus recruitment, head of the JKOPay QA/SDET team, and head of the AlfredCamera quality team. I’ve interviewed no less than 200 people. In some cases, it’s quite unfortunate that many software test developers lack a clear career path and don’t even know why they want to change jobs or seek new opportunities.

▲ Source: https://www.vectorstock.com/

如果今天是新鮮人，那我會盡我所能的引導並給予開放式的問題，讓面試者對於軟體測試開發充滿有可能的想像，在此基礎之上，進行專業領域的談話，看其是不是有潛能與天份。舉個例子，某天你使用支付軟體要進行交易的狀況下，而 App 無法使用，你覺得有可能的原因是什麼？遇過面試者就直接回：「應該就是網路壞了吧？」然後，停了10秒，再問，還有什麼可能？「支付軟體系統在維修？」，還有呢？「使用者輸錯了金額？」，僅僅這三個回答就可以衍生出許多能測試的面向，如下：

If I were interviewing a fresh graduate today, I would do my best to guide and pose open-ended questions to spark their imagination about the possibilities of software test development. Based on this foundation, we would delve into discussions within the professional field to assess their potential and aptitude. For example, one day, while trying to make a payment transaction using a payment app, the app isn’t working. What do you think could be the possible reasons? If an interviewee responds with, “It’s probably a network issue,” I would pause for about 10 seconds and then ask, “What else could it be?” They might say, “The payment app system is under maintenance,” and then I’d continue with, “What else?” They might answer, “The user entered the wrong amount.” Just these three answers could lead to various testing aspects, such as:

- Network-related testing
- System maintenance testing
- Input validation testing

And so on. This approach helps explore their problem-solving skills and testing mindset.

• 「那應該就是網路壞了吧？」：那什麼情形網路會壞呢？使用者是連線到了錯誤不可用的 wifi？機器本身網卡有問題？或是使用者沒繳電話費？或是收訊不佳？網路不是 4G 所以相對不穩？是消費者的手機網路壞掉還是POS 機本身網路有誤？防火牆的關係？機房硬體毀壞？實體線路有誤？
• “It’s probably a network issue.” Well, what scenarios can cause network issues? Is the user connected to an incorrect or unavailable Wi-Fi? Does the machine itself have a faulty network card? Is it because the user hasn’t paid their phone bill or there’s poor reception? Perhaps the network is not 4G, making it relatively unstable. Is it the consumer’s phone network or a problem with the POS machine’s network? Could it be due to firewall configurations? Are there hardware issues in the data center, or are there physical line problems?
• 「支付軟體系統正在維修嗎？」：什麼系統在維修？支付的系統錯誤？那有可能發生什麼錯誤？還是會員無法登入？讓整個服務完全不可用？系統跟系統之間可能發生斷線了？或是目前是高峰期所以請求無法即時消耗正在等待處理？或是資料庫處理不及？資料庫鎖表了？某一台機器的服務沒正確啟動？網頁空白？
• “Is the payment software system under maintenance?” What system is under maintenance? Is there an issue with the payment system? What kind of errors could occur? Is it that members can’t log in, rendering the entire service completely unavailable? Could there be a disconnection between systems? Is it a peak usage period, causing requests to queue for processing? Is it a database processing bottleneck or a table lock? Is a service on one machine not starting correctly? Or is the webpage just blank?
• 「該使用者輸錯了金額吧？」：使用者輸了什麼金額？金額有可能的值為何？該欄位的可能性與輸入的值是否可用？使用者真的有輸入嗎？還是什麼都沒輸就送出？會不會送了emoji？會不會是資料庫不吃這個欄位？欄位的大小不正確？欄位的型別有誤？
• “The user may have entered the wrong amount, right?” What amount did the user enter? What are the possible values for the amount? Are the possibilities and the input values for this field valid? Did the user actually input anything, or did they submit without entering any value? Could they have used emojis? Is it possible that the database doesn’t accept this field? Is the field size incorrect, or is there a data type issue?

其實林林總總的小問題，都可以分辨出該位面試者的細心程度，在提出疑問的同時，每個問題都是測試用例的建立與產出，一旦全部回答完，基本對於線上問題的分析就有一整套完整的 mindmap 可提供給開發變成解決問題的思路。如果這時候再補上一句：「情境上說的是 App 沒法使用，那你使用的是什麼平台？」那又會是另一番更廣的討論，對吧？每個職位都有其專業，如果你到了該領域的天花板那可能是你到了自己的天花板，別人的天花板可能還遠著，共勉。

In reality, a wide array of small questions can help discern the attentiveness of the interviewee. While posing questions, each question serves as a basis for creating and producing test cases. Once all questions are answered, you essentially have a comprehensive mind map for analyzing online issues, providing developers with a structured approach to problem-solving. If you add a line like, “In this scenario where the app isn’t working, what platform are you using?” it can lead to another, broader discussion, right? Every position has its expertise, and if you’ve reached the ceiling in that field, it might be your personal ceiling, but someone else’s ceiling could still be far off. Best of luck!

另外，眼尖的你，發現上方段落逐項解釋的三個問題都多出了一些贅字嗎？如果你發現了，麻煩肯定的告訴自己，你很適合當「軟體測試開發」！

Howard Chiang（一日測試創辦人/Founder of OnedaySoftware）
2023.11.2