Re: [心得] 我在科技業遇到的鬼故事之一
單純經驗交流一下
我遇到正常的軟體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都搭建得起來，流程摸久也就習慣了。
簡單成本就能大幅提高軟體品質與工作效率。最大差異在於，你有沒有待過這樣的工作環境，學習到這種工作觀念而已。
(可以思考一下，以上有哪些點，怎麼改善自己工作流程，不用硬套別人公司做法)
--
推這篇
依照他遇到的 case 正常 CI 跑應該是採不太到問題
可能需要用 integration test 或者是 behavior test 架設
特定環境 不過從他的文章看不出來有沒有這種東西 :)
Integration通常有另外的repository，跑其他整合測試才對
，或是在QA做真實上線環境下的整合測試，變化還蠻多的。但
原則就是大家都要看得到別人的UT 怎麼做。真的別用嘴巴討
論到Dev有沒有做UT，太不科學了。
沒有在自己電腦以外，公認的測試環境，跑的UT/IT，一律都
不能算有做，基本原則。
上面那個完全同意 沒上 CI /QA 畫押的測試怎麼會是測試
人能炸爛線上環境的不檢討制度也是很有趣
因為環境很難改變，大家都愛檢討人啊XD
推分享
我以為Push後在Jenkins上面會自動跑完git fetch抓分支，
build code，跑Gtest，自動化測項，Review完後給QA人工
測完才merge是基本常識，看來很多公司沒這麼做
看原PO描述，他們公司的UT環境是隨需求在隨時改，而且
沒有側錄機制。(這也好像是常態，除非非常重視SDLC而
且真的實作的公司)，所以出事只能靠嘴巴追責任而不是靠
log追蹤開發流程。
而上篇說，B有責任UT自己交出去的東西，他自承沒作（無
論是不是說謊），這樣就一定有責任。差在真的沒作是輕
責，作了故意放過是重責。
你的1&2是開發者自己測pass不能算有效,但自己測都失敗是根本
不該commit叫QA幫你試.. 除非有人想看preview
自己pass不算有效那自己fail也不算無效吧 commit後是自動QA
有過就過了 這問題主要是環境 自己電腦環境不一定對 所以才要
CI/QA看結果
自己fail還 commit是有事嗎？
推推
推推，整串讀完正需要這個
笑爛 那跑Test幹嘛
推這篇，這才是正常的軟體開發流程
笑爛，同推這篇，拜託用制度解決問題而不是一直在解
決人好不好
推分享 這樣的流程好好導入原原po就無從把自己team的鍋
推給B囉
原po公司重點在於沒有根據客戶環境做測試，尤其看起來像
是做專案的廠商，沒有這個環節QA還敢放行真的奇怪
比起建立制度，解決人比較輕鬆（X）
感謝大大無私分享
原PO是事後越想越不對勁 而且也保了B 所以不是解決提
出問題的人 而是後知後覺發現被坑了上來找人評評理
況且B是提出問題的人與B犯錯不能互相抵銷認為B沒錯
推分享
爆
首Po講一個我在科技業遇到的鬼故事 這件事主要發生在兩個人身上： A:是我同部門的同事，主要開發kernel層以下的功能。 B:是隔壁整合部門的同事，主要是開始kernel層以上的功能。 有一天A開發了某一個功能，B整合完之後發現會導致資料損毀。於是B發了一個bug給A，![[心得] 我在科技業遇到的鬼故事之一](https://i.imgur.com/13sxjYWb.png "[心得] 我在科技業遇到的鬼故事之一")
這個怎麼想都是公司的問題 居然沒有CI/CD? 環境怎麼會是以個人當標準? CI/CD過了 誰local有問題就你家的事啊 這種垃圾公司原PO還是快逃13
難怪IC house要推當責Accountablity 提到的每個人都幾乎有責任啦 就跟空難和起司理論一樣 不是只有一個單純的原因造成 Product owner每天或每周都應該了解進度/severity72
這篇文最鬼的明明就是原PO，這個Feature在他的組開發然後有問題，自己組的人+QA竟然 測不出來，結果隔壁組的人竟然有權限把Feature打開，B就算說原本就知道有問題硬要搞 最後補一句「有可能是我自己環境有問題」也是能全身而退 說到底身為新Feature的lead管產品品質+QA都管不好，有問題的code還能進到release br anch，最後還能PO出來讓大家評論B，這才是我看過最鬼的鬼故事吧78
我是原po，我來交代一些細節，供大家參考一下。 角色： 我在這裡的角色是application owner，我要推一個應用給客戶去使用。 我這個application需要多個feature來組成，B是我其中一個feature owner。 B這個feature需要多個kernel function整合才有辦法達成，當然B自己也要寫不少code。8
→ pokkys: 所以B根本不需要講他是故意的話。 07/25 19:37 所以大部分的人都搞錯重點了 因為事情對或錯往往都不是重點 而是看哪個部門比較大聲 B大也可以裝傻 退一步假裝真的是當時誤以為自己搞砸環境4
不是mindset也不是制度問題吧 是你們所有人的環境為什麼都跟客戶不一樣？ B只有一開始的環境類似於客戶 後來也不一樣了所以可能也做不出來 環境不一樣25
再回一篇，先說我不是B但是這個細節出了更明顯不是B的問題了啊 這個Bug本來就是一個corner case只是好巧不巧在B開發的時候遇到一次，要是今天B剛好 就沒遇到這個Bug，你們還不是一樣照常Release，客戶一樣爆掉，這樣B不就剛好衰幫你 發現Bug而已？ 你硬要說B的態度有問題，他也只是表達出他遇過且在你們根本沒修的情況本來就很可能8
到這邊為止 A看起來有把問題反應給你 你的工作應該是跟B的主管協調,看能不能讓B優先處理這個issue吧 大部分職場都會把開發需求區分piority 如果這是個嚴重的issue, piority設高並且必須優先處理.24
第一篇文章推文： pokkys: 我的職位要扛feature成敗，所以我也因此卡到升遷。 pokkys: 沒有火B這件事我也是傻眼+不滿，所以我比B還早離職 XD 第二篇文章內文： 其他人的部分，我是極力不想對A究責，B的主管也是一樣的態度。最後我們兩個送上去給老闆的說法是這兩個人的責任，10分裡只有1分。
27
Re: [心得] 我在科技業遇到的鬼故事之一大家好我是原po，大家討論那的激烈，我覺得我需要補充一下。 我認為有一個癥結點需要解釋一下，雖然有可能解釋完結果可能更糟 XD 因為中間有一段，完全是我的臆測，我也沒有絕對證據去證實我的論點。 如果各位要反駁我，我也完全接受。 我主要是要講一下，為何我會覺得B應該被火？24
Re: [請益] QA學生實習的問題其實我也有類似的問題，小弟我目前也在某美商當軟體測試實習生 因為公司原本員工眾多，但隨著部分產品開發成熟的關係，有些東西已經轉往美國 很尷尬的是，因為過去人數多，所以整個開發流程根據板上，應該算滿正式的（吧？ 專案管理有用 Jira，手動測試後要寫 automation test case，用 robot framework 因為這些自動化程式會放到 Jenkins 上，所以我們也有用到 Git22
[請益] 軟體業新人的工作瓶頸朋友沒帳號 幫忙代PO 手機排版還請多包涵 ------------正文---------- 各位軟體業的前輩好，小弟是個剛入門軟體業的新手(只會寫asp.net) 大約半年前錄取了一家上市公司的資訊部門，年薪大約55萬左右(含年終+獎金) 自己的背景只有私立學店+多益800+自學asp.net半年多。以這樣的條件來說小弟已經覺得11
Re: [請益] 請問這樣的git使用方式是否是正確的?個人意見，僅供參考 不太確定常不常見，但看起來是合理的。 可以想到的好處和情況是 不同的service 可以分開Build，Build 之後的artifact 可以依照每個service 的開發進 度deploy 到不同的測試環境，利於不同進度的開發和整合。8
Re: [請益] 如何當軟體QA??之前寫的軟體測試幾個層級，提供參考。 最入門的狀況，Intern/工讀生通常只會碰到這 A. 依照Test Case進行測試。回報Issue,重現步驟 B. 有能力建置測試環境到可以部屬待測軟體。 測試的軟性觀念，這邊開始才真的進入測試的領域。![Re: [請益] 如何當軟體QA??](https://www.talentbooster.net/gleeceez/TB_MetaFB2_1200x650.jpg "Re: [請益] 如何當軟體QA??")
5
Re: [請益] 如何當軟體QA??測試其實很多概念 難度其實不一定低於RD 首先來講講環境 DevOps之所以出現 最主要就是解決環境差異造成的問題