Testing Day 2017
＃2017/6/2 天氣：台灣下了第一場超級雨炸彈
從去年開始，測試這個領域忽然在台灣火熱了起來，除了Test Corner 固定舉辦的聚會外，連 iThome也辦起了測試研討會。6/2 的這場 Testing Day 主要是從開發人員的角度出發，來分享如何開始「測試」這件事。整場研討會，R&D 的聽者佔大宗，真正專職的測試人員大約佔了四分之一左右。另外從第一場聽眾所提出的問題來判斷，這個場子的聽者應該大多都還處於測試起步的階段（例如：有聽眾問到，如何開出好的 Test Case ? ) 。比較可惜的是，後面幾位講者因為時間不夠的關係，Q&A的部分是留給聽者私下和講者進行會後交流，因此就無法得知後續的發問狀況及問題方向。
開始進入正題，活動網頁 ：http://testing.ithome.com.tw/index.html#speaker
第一位分享者
趨勢科技/柯仁傑（ David)
分享趨勢科技實施自動化的歷程 ; 從全手工自己打造，到專人專職負責，最後變成全民皆兵的旅程。主要從團隊的組成和管理的角度，來看所採用的測試自動化策略。（節錄自活動網頁)
簡報連結：
https://www.slideshare.net/ssusere62027/testing-automation-journey-in-trend-micro?from_m_app=ios
1. 自動化演進三步驟：獨立團隊（4年）、擁兵自重（6年）、全民皆兵（5年)。
2. 師法微軟，從小就養成好習慣。
3. 要自動化之前，請先完成基礎建設。
4. 自動化測試 ＝軟體開發。
5. 大約只有四五成的 Bug 是從 Test Case 發現的。
6. RD 重深度；QA 懂廣度。 ／別讓自動化流於炫技。／開始嘗試重於追求完美。
＊適合聽眾： 已有自動化導入經驗者
這個分享很適合已經有自動化導入經驗的聽眾，至少我自己是很進入狀況（笑）。David的分享不會因為時間短就過於皮毛，對我而言就是在聆聽一位老前輩，分享這一路上的辛酸險惡（人家可是整整走了15年），並且對照自身經驗，了解「趨勢科技」遭遇相同問題時的處理之道。
自動化測試真的非常需要 R&D 和 QA 的共同合作、外加老闆的重視。一開始先求有再求好，千萬別想一步登天。畢竟分享已經提到，大約只有四五成的 BUG 是從 Test Case 發現，其他部分真的是在測試過程中邊測邊撿到啊！
第二位分享者 ：StreeVoice / 曾明賢
從2011開始引入自動化測試，當中覺得最重要的其實是克服初期團隊中抗拒寫測試的同事們。只要讓大家體會到自動化測試的好處後，大家就會開始擁抱測試，反而覺得沒有測試怪怪的。（節錄自活動網頁)
簡報連結：https://speakerdeck.com/tzangms/ke-fu-ren-xin-de-zhang-ai-kua-yue-zi-dong-hua-ce-shi-de-men-jian
1. 開發人員修改程式時最怕遇到的惡夢。
2. 自動化的過程中，如何生成及維護測試資料也是需要考慮的一環。
3. 鎖定好系統最不希望出錯的地方先下手。
4. 自動化部署的功能讓開發人員大大省去上版時不停複製貼上的煩惱。
＊適合聽眾： 開發人員，公司沒有專屬的QA
講者以會員系統的「註冊」功能當例子，藉以引導聽者在測試過程中會遇到的問題：ex : 填寫了一堆資料發現帳戶名稱重覆、密碼被擋、收不到認證信......等，後續也說明的模擬測試資料的困境，以及自動部署的好處。
聽完之後我的第一個念頭是，真的是好工程師的分享啊！（笑）
另外也在心中冒出了以下幾點疑問：
- 這個開發團隊的組成份子有哪些人？是只有PM和工程師？有無獨立的企劃、SA、QA?
- 以這個範例來說，程式完成後的第一個測試者是誰？根據分享內容推測應該就是開發此功能的工程師大大。
- 如果是工程師自己測，那麼一開始動手開發前，沒有先針對註冊欄位的檢查加以定義嗎？例如：密碼欄位一定要輸入八位數，還要中英文混用。自己寫的 Code 有沒有寫這段，為何會不清楚？
- 假設不是工程師親自測試，而且又沒有明確的規格，那麼接手測試的人員直接透過Test Case 和工程師先行討論後，其實就可以發現不少問題，甚至連測都不用測，馬上就知道哪段 Code要調整了。
- 生測試資料這件事，如果對於table的定義是清楚的，其實可以先使用人工方式先行模擬驗證。如果是長期要使用的，可以將資料產生的邏輯整理好，後續寫個小批次或透過工具加以協助解決。因此不是很明白為什麼會因為測試資料而卡關？
當然以上的疑問，還是要實際找講者了解才能解開，或是我自己有所誤解？
但單就開發人員針對自己寫的 Code 先行測試這點，已經要舉起大拇指稱讚了。這至少可以確保一般性的功能不會出大問題，後續的測試也可將心力花在介面操作以及例外狀況的探索。
第三位分享者
創科資訊／劉艾霖
本議程介紹如何選用一個測試框架，它又帶來什麼好處，實際撰寫一個可運作的測試程式，帶大家快速的入門，並分享一些測試開發實務上的小技巧。（節錄自活動網頁)
第四位分享者
創科資訊／謝宗穎
CI/CD（持續整合/持續部署）的自動化程序中，建置與部署的自動化是相對容易進行的，唯有自動化測試中的測試案例需要長時間累積。而在開發過程中，測試卻是容易被忽略的工作，人們往往看到的是多出來的工作，而不是他所帶來的邊際效益。（節錄自活動網頁)
1. 以黃金圈理論說明：為什麼需要測試
補充：https://www.youtube.com/watch?v=TlgLhYDRx6s
2. Agile 及 TDD
3. Team without tests vs Team with tests
4. 導入工具加以輔助
＊適合聽眾： 開發人員、手動轉自動化QA
兩位講者來自於同一間公司。前一位主要帶領聽者了解前端測試實務開發技巧，並直接帶 Demo說明；後一位講者帶到近期軟體開發圈常提到的 Agile、TDD，在後半段也以Demo方式展示CI\CD 實務流程。由於工具是我相對較弱的一環，因此就是以多吸收的方式認真聽講，並記下關鍵字待找時間實際操作及研究。
但是比較好奇的是，Scrum 及 Agile 是近一兩年來才在台灣流行起來，如果自動化測試無法一起配合，實務上的狀況會發生什麼樣衝突？難道這些東西都全面建立了，測試人員就沒有存在的必要嗎？
由於參與過不少測試相關的課程和活動，發現大部分的參與者都是R&D為主，反而專職的 QA很少出現。其實 R&D和 QA的思維蠻不同的，畢竟一個盡情的在建設，另一個則用力的在搞破壞（笑）。在這樣的場子裡，更可以好好交流，彼此更加相互瞭解才是。另外也期待日後類似活動，可以針對以下幾種角色的狀況來制定分享的題目，我想應該也可照顧到更多族群才是（小小許願池）。
- 純手動測試人員；
- 想從純手動跨入自動者；
- 開發人員，公司沒有測試人員；
- 開發人員，公司配有手動測試人員；
- 開發人員，公司配有手動＋自動人員
PS. 補充之後和講者謝宗穎交流時的小小結論：如果開發的 checking 能做到位，QA 才能更有效率地去發現潛在的問題。
