剛入職的新人如何快速了解公司業務
來自專欄軟體測試之道
公司業務的重要性
公司業務的重要性對軟體測試人員來說不用多說。作為軟體測試人員需要對公司業務完全了解,僅僅是了解還不行,需要做到精通,熟悉公司業務流程、功能等需求,目的就是為了能夠更好的進行測試活動。
只有對軟體測試需求完全掌握了,測試人員在測試過程中才能做到有的放矢,測試思維才能打開,測試過程中的細節才能被注意到。
比如,你在測試過程中碰到一個場景,系統後台或界面給你一個錯誤的返回,若是你對需求完全熟悉,你一定知道這個地方的返回是有問題的,如果你對需求不熟悉,那你可能就視若無睹,白白放過這樣一個bug。
這種情況在測試過程中遇到的頻率很高,若當時對需求不了解,可以向開發或最熟悉需求的測試人員請教,將這個點拋出來,大家一起討論看否是一個bug,如果測試人員有意識拋出還算好,但如果根本就覺得這個返回就應該是這樣呢,那埋下的隱患是不是就很大。
那測試人員應該怎麼做才能更好地了解業務?
王豆豆去年新入職現在公司,公司業務比較複雜,雖然同屬金融行業範疇,但是還是有大區別,同時公司業務根據行業規則不斷變化,所以遇到不斷學習,目前王豆豆也只算掌握了60%,但掌握業務的能力已被認可的,王豆豆就根據自身經驗分享作為剛入職的新人如何快速去了解公司業務。
剛入職的新人如何快速了解公司業務,王豆豆要從二個方面來分析如何快速掌握:
第一個是業務流程;第二個業務細節
1.業務流程
對剛開始入職的新人來說,剛開始一定是先從公司業務框架和業務流程學起,這個時間段需要做的就多看,多問,多做。
01 多看
多看指的是多看公司需求文檔,需求文檔包括任何一切有關公司業務的文檔,可能是公司業務背景,公司框架說明,以前的測試用例,測試報告,原型圖,公司系統等等。
盡自己的可能多找與公司業務相關的文檔、數據查看。
02 多問
多問就是指多向同事請教,不是不恥下問,而是不要害羞上問,其他人都可能比你懂得多。
現在企業對新人,可能會安排一個老同事帶你,也可能沒有,直接就安排你進項目做,但前期一定會給你留一點時間熟悉公司業務,如果有同事帶你,那是好運,但要明確一件事情就是別人帶你,並不是他的主要工作,而是額外工作;如果沒有,也不必急,學會自己去梳理,去掌握需求。
向同事問問題也是一門學問,不是遇到問題就開始問,也不是逮著誰都問,能自己解決的就最好自己解決,需要多觀察,通過觀察確定問問題的時機。
剛才王豆豆說過帶你的工作是額外工作,如果項目任務很忙的時候,帶你的測試人員既要完成平時的工作,又要解決你的問題,會給他造成一定的困擾,所以一定不要有問題就問。
王豆豆使用的辦法就是:
1.先將不緊急解決的問題記錄下來,然後找一個時間統一問;
2.緊急問題,如果這個問題不解決就沒辦法繼續下面的流程,那這樣的問題就必須立馬解決,如果帶你的人在忙著測試,那你可以先找其他人解決,如果不忙,那就正好。
王豆豆就是很好運的那個,王豆豆能這麼快掌握公司業務,很大程度上都是因為遇到很nice的同事,每遇到的一個問題都能很好解決,解決不僅僅是告訴答案,而是從流程,從結構,從根本原因,從設計目的去分析這個問題,解答很詳盡,基本問一次就相當於把一個流程或一個功能點吃透。
03 多做
不管你問得再多,看得再多,如果自己不動手去嘗試,那都是白費。
第一個做:
看文檔或系統時,動手畫出大致地系統流程圖來,也可以是系統框架,系統功能模塊等。
第二個做:
在問問題時,記錄下自己問的所有問題,避免重複問,如果你是第一次,我能給你詳細的解答,但如果是第二次,那我會記得我曾經給過你解答,如果還有第三次呢?那是不是我對你的印象就不會那麼好,我會覺得你對工作根本不上心。
第三個做:
執行---跑業務流程,分析流程的動作背後原因
假設公司業務有付款的功能,那就自己動手從用戶註冊-〉登錄-〉賬戶存錢-〉付款的業務場景來做,一個個完整的流程跑,一邊跑一邊記錄頁面交互點,每一個動作引起界面或任務或資料庫的變化,然後修改一點再跑再記錄。
比如付款賬戶有錢或沒錢的界面返回,資料庫的變化,同時了解每執行一個動作,所需要的前置條件,執行所需要的數據從哪些地方取等等。
關注點較多時,不一定只執行一次就全部了解,可以多次重試,但最終結果是每一個動作,你都需要掌握,這也是我們業務細節部分需要掌握的。
2.業務細節
這個階段一定是建立在你對公司系統框架,業務流程,產品類型都是相當清楚的前提下再關注的點。
首先要清楚什麼是業務細節?
王豆豆以為業務細節就是通過表象所看不出來的,而是需要根據數據,任務,動作共同去分析的。
王豆豆目前覺得應該二個辦法:
第一個方法是多跑業務流程
前面已經講過了,根據前面所講的方法來分析每一次執行動作,記錄執行前的前置條件和取數據的表,以及執行後的變化,包含資料庫,界面,測試環境記錄的日誌等。
第二個方法是看代碼
學會看代碼是每一個測試人員都應該掌握到的。
如果公司沒有完整的需求文檔,測試人員可以通過看代碼分析需求,業務流程的變化,自己就能梳理出需求來。
看代碼可以發現測試人員在前端和業務流程上發現不到的問題,同時還能提高測試人員在某類功能點上測試的效率。
以測試人員測試Mapping類業務為例,大家都知道Mapping(映射)是指各系統或子系統中相同點的不同映射。
例如1在A系統中表示小學生,在B系統中表示中學生,2在A系統中表示中學生,在B系統中表示小學生,在A系統中輸入1,在B系統界面需要顯示小學生。
如果要測試這樣的業務,功能測試至少需要二條測試用例來覆蓋,那如果是看代碼呢,是不是直接就可以看出來了,你又可能會說不就是多二條測試用例么?那如果這樣的Mapping值很多呢,功能測試就需要測試很多次,而通過看代碼能很快發現AB系統的映射是否正確,是不是效率提高很多。
同時看代碼可以清楚更多業務設計細節和流程的跳轉及條件等。
以前沒有看過代碼,剛開始看似確實很難,但看得越多就越容易,學會看代碼的前提是對相應編程語言的基礎了解,知道如何使用。
以上就是王豆豆熟悉業務的方法,歡迎大家和我討論更多更有效的方法。
推薦閱讀:
※軟體測試對於零基礎該怎麼制定學習思路
※關於黑盒測試的一些總結(適合新手入門使用)
※從0到1搭建測試自動化框架
※寫在CNAS現場評審之後
※手機黑盒測試