Re: [心得] 我在科技業遇到的鬼故事之一

看板Soft_Job作者 (竹科管理處網軍研發人員)時間9月前 (2023/07/28 09:03), 9月前編輯推噓18(18推 0噓 28→)
留言46則, 21人參與, 9月前最新討論串14/17 (看更多)
單純經驗交流一下 我遇到正常的軟體UT與品質驗證流程吧： 1.開發者寫完程式碼與UT。 2.在自己電腦上跑UT。 在自己電腦上跑UT，是部門不認的UT。 沒人知道你自己電腦的環境與有沒有動手腳。 3. Commit and push 到 repository 開發分支。 4. 啟動 CI ，CI有個stage會去跑開發者的UT。 由於UT已經不在開發者的電腦或環境跑了。 所以有許多優點： a. 環境是獨立的，而且通常設計成接近 release後的環境。比較容易提早發現問題。 b. 開發者有沒有做好UT，Pass UT，是有自動記錄，而且自己沒有權限修改的。避免了前 5. 所有CI流程都過了，UT過了，開發者以外的工程師或主管，才開始審核程式碼 code review。(正常情況，至少兩人) 這時審核的人，系統都會自動紀錄。 比較大的公司也會有規定，或慣例該review哪些重點。 6. Code review 過了，系統才會自動 merge到 "開發"分支。(因為還沒給QA測過，沒辦法release) 7. QA 測試前，先再次跑CI流程，包含UT，確認開發部門有按照基本品質要求走。(避免被Dev部門黑)。拉取程式與自己的測試程式，在接近生產環境的設備上測試。 8. QA測試出報告，有問題，提issue修改。沒問題，上系統或出Mail說驗證通過。(為品質背書) 9. 程式碼品質Ok了，要將 dev merge到release分支。開發者根本沒這權限。只有技術的owner或 Tech lead 有merge權限。有merge權限的人，要對這程式碼品質負責。 以上的流程，已經簡化蠻多細節了，而且變化很多，同家公司不同部門細節也不同，但大原則沒變。 看似複雜冗長，其實大多機器自動化去做，大多寫程式就能完成自動化，習慣了就好。兩個星期跑release 一個線上版本很正常。 線上系統出問題，誰有責任： 開發者，owner，開發者主管，測試QA工程師，QA工程師主管，PM都可能會有責任。 大家不是靠嘴去爭的，拿出Log與證據來討論吧。 自己開發電腦上有沒有Bug或 Log根本沒人看。 Bug是否產生，所有Log，都在第三方電腦(或雲端)，而且是接近Release環境的。 以上的流程與技術其實也不難，open source都搭建得起來，流程摸久也就習慣了。 簡單成本就能大幅提高軟體品質與工作效率。最大差異在於，你有沒有待過這樣的工作環境，學習到這種工作觀念而已。 (可以思考一下，以上有哪些點，怎麼改善自己工作流程，不用硬套別人公司做法) -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 42.72.104.143 (臺灣) ※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1690506190.A.622.html
推
07/28 09:23, 9月前 , 1F
推這篇
07/28 09:23, 1F
推
07/28 09:24, 9月前 , 2F
依照他遇到的 case 正常 CI 跑應該是採不太到問題
07/28 09:24, 2F
→
07/28 09:25, 9月前 , 3F
可能需要用 integration test 或者是 behavior test 架設
07/28 09:25, 3F
→
07/28 09:25, 9月前 , 4F
特定環境 不過從他的文章看不出來有沒有這種東西 :)
07/28 09:25, 4F
※ 編輯: DrTech (42.72.71.209 臺灣), 07/28/2023 09:27:01
→
07/28 09:31, 9月前 , 5F
Integration通常有另外的repository，跑其他整合測試才對
07/28 09:31, 5F
→
07/28 09:31, 9月前 , 6F
，或是在QA做真實上線環境下的整合測試，變化還蠻多的。但
07/28 09:31, 6F
→
07/28 09:31, 9月前 , 7F
原則就是大家都要看得到別人的UT 怎麼做。真的別用嘴巴討
07/28 09:31, 7F
→
07/28 09:31, 9月前 , 8F
論到Dev有沒有做UT，太不科學了。
07/28 09:31, 8F
→
07/28 09:34, 9月前 , 9F
沒有在自己電腦以外，公認的測試環境，跑的UT/IT，一律都
07/28 09:34, 9F
→
07/28 09:34, 9月前 , 10F
不能算有做，基本原則。
07/28 09:34, 10F
推
07/28 09:51, 9月前 , 11F
上面那個完全同意 沒上 CI /QA 畫押的測試怎麼會是測試
07/28 09:51, 11F
推
07/28 10:11, 9月前 , 12F
人能炸爛線上環境的不檢討制度也是很有趣
07/28 10:11, 12F
推
07/28 10:20, 9月前 , 13F
因為環境很難改變，大家都愛檢討人啊XD
07/28 10:20, 13F
推
07/28 10:22, 9月前 , 14F
推分享
07/28 10:22, 14F
推
07/28 10:25, 9月前 , 15F
我以為Push後在Jenkins上面會自動跑完git fetch抓分支，
07/28 10:25, 15F
→
07/28 10:25, 9月前 , 16F
build code，跑Gtest，自動化測項，Review完後給QA人工
07/28 10:25, 16F
→
07/28 10:25, 9月前 , 17F
測完才merge是基本常識，看來很多公司沒這麼做
07/28 10:25, 17F
推
07/28 10:41, 9月前 , 18F
看原PO描述，他們公司的UT環境是隨需求在隨時改，而且
07/28 10:41, 18F
→
07/28 10:42, 9月前 , 19F
沒有側錄機制。(這也好像是常態，除非非常重視SDLC而
07/28 10:42, 19F
→
07/28 10:43, 9月前 , 20F
且真的實作的公司)，所以出事只能靠嘴巴追責任而不是靠
07/28 10:43, 20F
→
07/28 10:43, 9月前 , 21F
log追蹤開發流程。
07/28 10:43, 21F
→
07/28 10:44, 9月前 , 22F
而上篇說，B有責任UT自己交出去的東西，他自承沒作（無
07/28 10:44, 22F
→
07/28 10:44, 9月前 , 23F
論是不是說謊），這樣就一定有責任。差在真的沒作是輕
07/28 10:44, 23F
→
07/28 10:45, 9月前 , 24F
責，作了故意放過是重責。
07/28 10:45, 24F
推
07/28 10:59, 9月前 , 25F
你的1&2是開發者自己測pass不能算有效,但自己測都失敗是根本
07/28 10:59, 25F
→
07/28 11:00, 9月前 , 26F
不該commit叫QA幫你試.. 除非有人想看preview
07/28 11:00, 26F
→
07/28 11:07, 9月前 , 27F
自己pass不算有效那自己fail也不算無效吧 commit後是自動QA
07/28 11:07, 27F
→
07/28 11:07, 9月前 , 28F
有過就過了 這問題主要是環境 自己電腦環境不一定對 所以才要
07/28 11:07, 28F
→
07/28 11:08, 9月前 , 29F
CI/QA看結果
07/28 11:08, 29F
→
07/28 11:26, 9月前 , 30F
自己fail還 commit是有事嗎？
07/28 11:26, 30F
推
07/28 11:47, 9月前 , 31F
推推
07/28 11:47, 31F
推
07/28 12:00, 9月前 , 32F
推推，整串讀完正需要這個
07/28 12:00, 32F
推
07/28 12:08, 9月前 , 33F
笑爛 那跑Test幹嘛
07/28 12:08, 33F
推
07/28 12:14, 9月前 , 34F
推這篇，這才是正常的軟體開發流程
07/28 12:14, 34F
推
07/28 12:32, 9月前 , 35F
笑爛，同推這篇，拜託用制度解決問題而不是一直在解
07/28 12:32, 35F
→
07/28 12:32, 9月前 , 36F
決人好不好
07/28 12:32, 36F
推
07/28 13:18, 9月前 , 37F
推分享 這樣的流程好好導入原原po就無從把自己team的鍋
07/28 13:18, 37F
→
07/28 13:18, 9月前 , 38F
推給B囉
07/28 13:18, 38F
推
07/28 13:33, 9月前 , 39F
原po公司重點在於沒有根據客戶環境做測試，尤其看起來像
07/28 13:33, 39F
→
07/28 13:33, 9月前 , 40F
是做專案的廠商，沒有這個環節QA還敢放行真的奇怪
07/28 13:33, 40F
→
07/28 15:23, 9月前 , 41F
比起建立制度，解決人比較輕鬆（X）
07/28 15:23, 41F
推
07/28 16:39, 9月前 , 42F
感謝大大無私分享
07/28 16:39, 42F
→
07/28 20:05, 9月前 , 43F
原PO是事後越想越不對勁 而且也保了B 所以不是解決提
07/28 20:05, 43F
→
07/28 20:06, 9月前 , 44F
出問題的人 而是後知後覺發現被坑了上來找人評評理
07/28 20:06, 44F
→
07/28 20:07, 9月前 , 45F
況且B是提出問題的人與B犯錯不能互相抵銷認為B沒錯
07/28 20:07, 45F
推
07/28 20:23, 9月前 , 46F
推分享
07/28 20:23, 46F
‣ 更多 DrTech 的文章
文章代碼(AID): #1amnFEOY (Soft_Job)
討論串 (同標題文章)
完整討論串 (本文為第 14 之 17 篇)：
排序： 最舊先 | 最新先 | 留言數
在新視窗開啟完整討論串 (共17篇)
‣ 更多 DrTech 的文章
文章代碼(AID): #1amnFEOY (Soft_Job)