行話：同業間的專用語。如：「行家說行話」。亦稱為「同行語」、「行業語」。
有時看電視上，藝人們在聊天，講到像是「我們為了這演出，之前 Re (讀: 蕊)了好幾次」，什麼叫做「Re」？而且還發成蕊的音！他其實是「rehearsal」的簡稱，也許國外演藝人員習慣簡稱他「Re」，這我不清楚，就是說，也許因為 Rehearsal 太長，經常會簡單講它，這就會變成一種行話。只是，當你聽到大家都講蕊蕊蕊，你知道那是什麼意思嗎？「我們再來蕊一次吧」!?
老師說，不懂，就要問！（丟粉筆）
記得以前有部電影，描述要測試保全系統，於是請來過去曾有偷竊經驗的人來檢驗其保全夠不夠縝密。
想想看，如果你自己做了一把菜刀，你要怎麼測試他？
首先，假定這把是切菜的刀，拿在手上試試重量以及重心、比例；接著，找來看是高麗菜、大白菜等青菜切切看；再來，找來一把蔥，切看看，看這把刀快不快........喔我掰不下去了，因為我不會做菜。實際上切蔥是不是用更輕巧的快刀呢？
是了，你要測試一個產品，你首先必須熟悉這個產品或是熟悉對應的需求（做菜、切菜）。
以我來看，熟悉產品，比較偏向於設計面，比較會是設計者的角度，或是專家角度；實際需求則是偏向消費者、使用者。
如果你設計了一把菜刀，你除了自己測試完畢以外，最好找來專家與一班使用者，來幫你進行測試。
換個例子，如果你設計了一個高科技產品，例如你開發了一款高規格的行車紀錄器，你除了在你的實驗室測試所有功能以外，你應該要做路測。而且，最好不是你或你的同事測，因為也許你們是該產品的專家，但你們可能不是開車的專家，也可能不了解路上跑的車有什麼樣的狀況。
結果，當你沒有作好路測時，產品在上市後，才發現機體過熱導致異常。當你百思不解，想說你在實驗室已做過壓力測試 - 連續錄影 24 小時都正常，為什麼爆出那麼多過熱異常的狀況！這就是你不了解原來上路後，太陽晒下來，車子會有多熱；原來開進雪隧，隧道內那麼熱；原來很多消費者，下車後不會把機子拔下來放陰涼處，所以就放在車子裡晒太陽，而原來車子裡的溫度會高到 50~70 度，遠高於機器正常工作溫度！
但是如果你還是沒辦法找來使用者幫你測試，你怎麼辦？
我會建議，測試時，你要假想你是一個找碴的人，你就是一心一意要證明該產品不能正常運作，所以你就得要試著在各種邊界點去驗證他。邊界點就好比機器工作溫度，他就是一個邊界點，雖然你說這機器正常工作溫度是 0~50 度，但實際上，在路上就是會遇上溫度高過 50 度，那怎麼辦？
找碴並試圖證明產品不能運作的模擬方式，是一個比較快速協助開發人員自己檢驗產品完整性的方式之一。
每個地區經常都有一些各自的特殊慣用語，在生活習慣上也都有一些小差異。城鄉之間的差異也會造成生活習慣的不同。例如都會區裡的小餐館，常見要客人點完菜先付款，但城郊的小餐館通常你吃完要走再結帳，不急！
本來嘛，一群人在一個區域裡共同生活，本來就會逐漸發展出特有的互動方式，語言文字也是這樣逐漸產生。這個鄉可能大家在廟會時很熱情，隔壁鄉可能是在普渡時擴大慶祝。習慣也是會改變的，雖然現今法規規定車輛應等禮讓行人先行通行過斑馬線，在都會區裡，你行人可以比較放心的走，到了鄉下，你可得更加小心有無車輛。
至於語彙呢？想像我今天一早出門，遇上鄰居，「嘿，早安！」到了早餐店：「老闆，包子一個，米漿一杯，帶走。」到了公司，看見警衛：「早！」中午時，到了麥當勞：「我要一號餐，外帶。」 下午到了 7-Eleven 買咖啡：「中熱拿，不要糖！」傍晚口渴，到飲料店：「綠茶一杯，無糖，去冰。」這裡出現類似的語彙有「早安 / 早」、「帶走 / 外帶」、「不要糖 / 無糖」等等。這些用語都是當地慣用 / 通用的，所以不管你怎麼說，大家都很容易的可以懂。
如果你在路上遇見個路人，問你「請問，要到 101 ，打車過去快還是搭公車？」我告訴你，這路人八成是個大陸人，因為「打車」不是說去敲打車子，是叫一部計程車。在台灣也會用「打」字，例如「打電話」、「打卡」，為什麼你就不會懷疑這是在講要把電話打壞，要把卡片打壞？因為我們習慣那麼講。但我們不講「打車」！
「大口吃遍台灣」的主持人阿松，他在點小吃時，常常會錯用量詞，例如「老闆，那個湯，我要一個，裡面用。」雖然量詞本來就不好學，一個、一碗、一份、一杯、一瓶、一張、一箱、一桶........有時確實講「一個」最快，即使聽起來很奇怪。這就好像用英語你要說 one cup, one meal, one beer, one cloth....基本上大家都懂，你不太需要去執著什麼 one piece of xxxx 之類的。
語彙差異在網路遊戲上也造成一些小困擾，例如最近很熱門的星海爭霸，台灣伺服器上有很多來自中國大陸的玩家，於是就有台灣玩家指出兩邊語彙跟講法的不一樣，例如：
| 中國大陸用語 | 台灣用語 |
|---|---|
| 造房子 | 建房子 |
| 出2隊機槍兵 | 生2隊機槍兵 |
| 來2隊小狗 | 來2隊小蟲 |
以前在維護網站的時代，採用 UNIX 系統，就特別針對效能瓶頸多加注意。當時遇上龐大的網站瀏覽需求以及網站服務使用需求，使得網站回應相當慢。老闆當然要求要盡快解決，也問過我是不是要換更好的機器，他再去找經費。
但是錢要花在刀口上，因為我們沒有無限的經費。當時的例子，效能瓶頸可能出現在下面幾個點：
最近聽到某個專案團隊詢問一個問題，問到說我們的問題追蹤系統能不能有個快速提交問題的表單，好讓外面的協力廠商或自由工作者可以比較簡單的在測試階段提交問題；或者說，能不能有匯入功能，例如透過 Excel 表單匯入問題到系統。
我覺得以工程師的角度去思考問題，大概會覺得這些都是功能面的問題，既有的提交問題程序對工程師來講不會很困難也不會很複雜，能不能有快速提交方式，要看系統擴充性，要不就要重新設計該專案的欄位；至於能不能透過 Excel 匯入，也是看系統本身支援與否，要不就要自己寫一個中介程式來加以處理。
雖說系統易用性對於工程師與其他非工程師來講，會有很大的落差。而若是提到產品開發，很多開發團隊對於產品的易用性往往不擅長，不過這已經是另外一個主題，在此不多做著墨。
是不是可以有快速提交表單，這可以藉由定義哪些欄位屬於必填欄位，哪些屬於選填欄位，然後看系統是否支援在建立新的問題記錄時，可以有機會選擇簡單表單或是完整表單，來看是否可行。
透過 Excel 匯入，我覺得我在解答可行或是不可行之前，我倒想提出個疑問。該專案決定使用這套系統作為問題追蹤系統的用意是什麼？一個專案可以選用任何的問題追蹤方式，不管是口頭回報、一個筆記本記錄、一個共用或非共用的 Excel 表單、SharePoint 表單、或是專門的問題追蹤系統，只要適用於多數專案成員，他就會是個不錯的方式或系統。
如果目前專案的狀況是專案團隊龐大、成員散布在多個國家地區以及不同時區、專案交付物龐雜等等，要求所有成員使用集中式的問題追蹤系統，好處除了狀態追蹤容易以外，還包含他可以是即時的，例如當一個問題產生，回報問題後，被指派的問題解決者會立即收到電子郵件通知。系統還可以快速的依照不同需求來篩選問題。
使用 Excel 表單來匯入問題，意味著提交問題的測試人員將會使用 Excel 來記錄問題？而開發人員依舊使用系統來追蹤問題！那麼接踵而來的問題，將會是後續的問題追蹤。試想，當開發人員與測試人員使用兩套不一樣的系統來記錄/追蹤問題，這兩個團隊以及這兩個系統之間如何溝通/同步？
Excel 表單匯入系統確實解決了從測試團隊回報的問題可以在系統內轉發給個別的開發人員，但是緊接著當問題逐一解決後，勢必要將這些更新的進度在匯出轉成 Excel 然後發給測試人員。然而，狀況不單這麼單純，在過程中還會發生許多往返，例如某問題描述不清，開發人員得要轉回給測試人員詢問更多細節，或是測試人員驗證問題時發現問題仍舊存在等等。這之間將會有很多的溝通會變得相當複雜。
所以，跳出來想一下，當初這專案並沒有使用 Excel 表單來作問題的追蹤，而採用問題追蹤系統，是為什麼？是希望藉由系統來輔助可能的龐雜溝通與追蹤問題？還是其實本來就是個很小的案子，要殺雞卻用了牛刀？
