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,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. 有能力建置測試環境到可以部屬待測軟體。 測試的軟性觀念,這邊開始才真的進入測試的領域。5
Re: [請益] 如何當軟體QA??測試其實很多概念 難度其實不一定低於RD 首先來講講環境 DevOps之所以出現 最主要就是解決環境差異造成的問題