PTT評價

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

看板Soft_Job標題Re: [心得] 我在科技業遇到的鬼故事之一作者
DrTech
(竹科管理處網軍研發人員)
時間推噓18 推:18 噓:0 →:28

單純經驗交流一下
我遇到正常的軟體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 留言評論
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 42.72.104.143 (臺灣)
PTT 網址

blackrays07/28 09:23推這篇

CMJ012107/28 09:24依照他遇到的 case 正常 CI 跑應該是採不太到問題

CMJ012107/28 09:25可能需要用 integration test 或者是 behavior test 架設

CMJ012107/28 09:25特定環境 不過從他的文章看不出來有沒有這種東西 :)

※ 編輯: DrTech (42.72.71.209 臺灣), 07/28/2023 09:27:01

DrTech07/28 09:31Integration通常有另外的repository,跑其他整合測試才對

DrTech07/28 09:31,或是在QA做真實上線環境下的整合測試,變化還蠻多的。但

DrTech07/28 09:31原則就是大家都要看得到別人的UT 怎麼做。真的別用嘴巴討

DrTech07/28 09:31論到Dev有沒有做UT,太不科學了。

DrTech07/28 09:34沒有在自己電腦以外,公認的測試環境,跑的UT/IT,一律都

DrTech07/28 09:34不能算有做,基本原則。

CMJ012107/28 09:51上面那個完全同意 沒上 CI /QA 畫押的測試怎麼會是測試

rayway3041907/28 10:11人能炸爛線上環境的不檢討制度也是很有趣

wmtsung07/28 10:20因為環境很難改變,大家都愛檢討人啊XD

shibin07/28 10:22推分享

yamakazi07/28 10:25我以為Push後在Jenkins上面會自動跑完git fetch抓分支,

yamakazi07/28 10:25build code,跑Gtest,自動化測項,Review完後給QA人工

yamakazi07/28 10:25測完才merge是基本常識,看來很多公司沒這麼做

luciferii07/28 10:41看原PO描述,他們公司的UT環境是隨需求在隨時改,而且

luciferii07/28 10:42沒有側錄機制。(這也好像是常態,除非非常重視SDLC而

luciferii07/28 10:43且真的實作的公司),所以出事只能靠嘴巴追責任而不是靠

luciferii07/28 10:43log追蹤開發流程。

luciferii07/28 10:44而上篇說,B有責任UT自己交出去的東西,他自承沒作(無

luciferii07/28 10:44論是不是說謊),這樣就一定有責任。差在真的沒作是輕

luciferii07/28 10:45責,作了故意放過是重責。

xam07/28 10:59你的1&2是開發者自己測pass不能算有效,但自己測都失敗是根本

xam07/28 11:00不該commit叫QA幫你試.. 除非有人想看preview

wtl07/28 11:07自己pass不算有效那自己fail也不算無效吧 commit後是自動QA

wtl07/28 11:07有過就過了 這問題主要是環境 自己電腦環境不一定對 所以才要

wtl07/28 11:08CI/QA看結果

luciferii07/28 11:26自己fail還 commit是有事嗎?

Vick75307/28 11:47推推

Burwei07/28 12:00推推,整串讀完正需要這個

sniper282407/28 12:08笑爛 那跑Test幹嘛

f496328mm07/28 12:14推這篇,這才是正常的軟體開發流程

puring081507/28 12:32笑爛,同推這篇,拜託用制度解決問題而不是一直在解

puring081507/28 12:32決人好不好

sirlers07/28 13:18推分享 這樣的流程好好導入原原po就無從把自己team的鍋

sirlers07/28 13:18推給B囉

Litfal07/28 13:33原po公司重點在於沒有根據客戶環境做測試,尤其看起來像

Litfal07/28 13:33是做專案的廠商,沒有這個環節QA還敢放行真的奇怪

newhandfun07/28 15:23比起建立制度,解決人比較輕鬆(X)

safe07/28 16:39感謝大大無私分享

superpandal07/28 20:05原PO是事後越想越不對勁 而且也保了B 所以不是解決提

superpandal07/28 20:06出問題的人 而是後知後覺發現被坑了上來找人評評理

superpandal07/28 20:07況且B是提出問題的人與B犯錯不能互相抵銷認為B沒錯

viper970907/28 20:23推分享