※ 本文轉寄自 ptt.cc, 文章原始頁面
看板Soft_Job
標題

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

時間
最新2023-07-28 20:23:00
留言46則留言,21人參與討論
推噓18 ( 18028 )
單純經驗交流一下 我遇到正常的軟體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

46 則留言

blackrays, 1F
推這篇

CMJ0121, 2F
依照他遇到的 case 正常 CI 跑應該是採不太到問題

CMJ0121, 3F
可能需要用 integration test 或者是 behavior test 架設

CMJ0121, 4F
特定環境 不過從他的文章看不出來有沒有這種東西 :)
※ 編輯: DrTech (42.72.71.209 臺灣), 07/28/2023 09:27:01

DrTech, 5F
Integration通常有另外的repository,跑其他整合測試才對

DrTech, 6F
,或是在QA做真實上線環境下的整合測試,變化還蠻多的。但

DrTech, 7F
原則就是大家都要看得到別人的UT 怎麼做。真的別用嘴巴討

DrTech, 8F
論到Dev有沒有做UT,太不科學了。

DrTech, 9F
沒有在自己電腦以外,公認的測試環境,跑的UT/IT,一律都

DrTech, 10F
不能算有做,基本原則。

CMJ0121, 11F
上面那個完全同意 沒上 CI /QA 畫押的測試怎麼會是測試

rayway30419, 12F
人能炸爛線上環境的不檢討制度也是很有趣

wmtsung, 13F
因為環境很難改變,大家都愛檢討人啊XD

shibin, 14F
推分享

yamakazi, 15F
我以為Push後在Jenkins上面會自動跑完git fetch抓分支,

yamakazi, 16F
build code,跑Gtest,自動化測項,Review完後給QA人工

yamakazi, 17F
測完才merge是基本常識,看來很多公司沒這麼做

luciferii, 18F
看原PO描述,他們公司的UT環境是隨需求在隨時改,而且

luciferii, 19F
沒有側錄機制。(這也好像是常態,除非非常重視SDLC而

luciferii, 20F
且真的實作的公司),所以出事只能靠嘴巴追責任而不是靠

luciferii, 21F
log追蹤開發流程。

luciferii, 22F
而上篇說,B有責任UT自己交出去的東西,他自承沒作(無

luciferii, 23F
論是不是說謊),這樣就一定有責任。差在真的沒作是輕

luciferii, 24F
責,作了故意放過是重責。

xam, 25F
你的1&2是開發者自己測pass不能算有效,但自己測都失敗是根本

xam, 26F
不該commit叫QA幫你試.. 除非有人想看preview

wtl, 27F
自己pass不算有效那自己fail也不算無效吧 commit後是自動QA

wtl, 28F
有過就過了 這問題主要是環境 自己電腦環境不一定對 所以才要

wtl, 29F
CI/QA看結果

luciferii, 30F
自己fail還 commit是有事嗎?

Vick753, 31F
推推

Burwei, 32F
推推,整串讀完正需要這個

sniper2824, 33F
笑爛 那跑Test幹嘛

f496328mm, 34F
推這篇,這才是正常的軟體開發流程

puring0815, 35F
笑爛,同推這篇,拜託用制度解決問題而不是一直在解

puring0815, 36F
決人好不好

sirlers, 37F
推分享 這樣的流程好好導入原原po就無從把自己team的鍋

sirlers, 38F
推給B囉

Litfal, 39F
原po公司重點在於沒有根據客戶環境做測試,尤其看起來像

Litfal, 40F
是做專案的廠商,沒有這個環節QA還敢放行真的奇怪

newhandfun, 41F
比起建立制度,解決人比較輕鬆(X)

safe, 42F
感謝大大無私分享

superpandal, 43F
原PO是事後越想越不對勁 而且也保了B 所以不是解決提

superpandal, 44F
出問題的人 而是後知後覺發現被坑了上來找人評評理

superpandal, 45F
況且B是提出問題的人與B犯錯不能互相抵銷認為B沒錯

viper9709, 46F
推分享

DrTech 作者的近期文章

Re: [討論] 拿到很不開心的offer還會去嗎?
※ 引述《flyingIdea (飛翔的想法)》之銘言: : 最近面試了一些公司 : 其中有一間offer 做的和我比較相關 : 但拿到後整個都開心不起來 : 面試結果有過 並且我不是唯一面試者 : 但面試完說我 : 1.他們說待業空窗期快
Re: [新聞]剖析中研院大型語言模型事件的衝擊
先說結論: 發展本土化,繁體中文LLM模型,然後期待這個模型能讓大家使用,根本是錯誤方向。不知道這些專家學者,是在騙經費,還是還沒想清楚產業到底缺什麼。- 如果今天你使用Google搜尋,搜到"台灣是中國的",或任何有政
Re: [請益] 雲端技術是Java工程師的必備技能嗎
連續幾篇,XX技術,是必備的嗎? 首先,我覺得許多人的盲點就是, 搞不清楚,"學技術"與"學工具"的差別。 同樣是用鍋鏟與刀具, 有些廚師可以,到星級飯店當主廚,領高薪。 有些人只能在小餐廳辛苦低薪。
更多 DrTech 作者的文章...