本節書摘來自華章出版社《移動app測試實戰》一 書中的第1章，第1.1節，作者：邱鵬 陳吉 潘曉明，更多章節内容可以通路雲栖社群“華章計算機”公衆号檢視。
對于每個研發組織，因為産品的特性、組織的特點和一些曆史原因，對于産品研發流程的了解和設定都有不同的考慮。但是以我們工作過的幾家網際網路來說，因為網際網路産品的一些共同點，大緻的産品研發流程其實大同小異，或者是做類似的事情但叫法不同。考慮到本書的讀者可能目前的工作範圍不一定是網際網路産品，或者還沒有機會了解整個研發流程，這裡先做一些基本的介紹，也便于後面章節關于品質提升方面的讨論。
為了了解流程，首先需要介紹一下網際網路産品研發相關的分工，主要的角色如下：
産品經理。負責産品方向和具體需求的規劃，需求文檔的編寫。是待開發需求的提出方，或者代理方（來自業務部門等第三方的需求，由産品經理轉化成研發團隊的需求形式）。通常對于較大規模的産品，産品經理是一個團隊，每個人分工負責部分功能子產品的需求細節。
項目經理（以下簡稱pm）。負責項目的立項和時間安排，并跟進項目研發的進展、變更和風險，以及各種跨團隊的協調工作。在一個大的項目中，通常也會有多位項目經理分工協作。
設計師。負責産品的互動設計、視覺設計等方面。主要的産出是産品的互動原型和設計稿。
開發人員。負責産品的技術架構設計和代碼編寫，産出是可運作的實際産品。通常根據專業領域也進一步劃分為架構師、背景開發、web前端開發、android開發、ios開發等多個崗位。
測試人員。負責産品的品質把關，包括功能、性能和穩定性等多方面的測試内容。進一步細分包括業務功能測試、測試工具和平台開發、專項技術測試等崗位。部分組織裡面也将品質管理放在測試團隊。
運維人員。負責産品的服務端運作環境的建設和維護，以及日常的配置管理、容量規劃、網絡和裝置故障處理等工作，常常也包含監控平台的建設和管理。取決于研發組織是采用自建idc，租用idc或者采用第三方雲計算平台，運維團隊的工作可能有所不同。
營運人員。負責業務和産品的推廣和拓展。對于移動網際網路産品，常見的工作範圍包括app的推廣，各類營運活動的規劃和推動，同第三方一起開展的市場活動，以及營運平台的規劃等方面。
在前面各個角色分工的基礎上，圖1-1展示了一個基于研發階段和角色分工的流程圖。也是在網際網路研發中比較常見的一個流程，可以看出每個階段要做的主要工作，以及對應角色在該階段的産出物。
圖1-2給出了一個以主要研發活動為線索的流程圖，從中可以看出各個參與角色對應的研發活動的銜接。比如在需求評審完之後pm組織大家排期；開發自測完成之後交給産品經理體驗；測試完成并釋出測試報告，以及釋出政策确定後進行釋出上線。
為了适應網際網路快速疊代的節奏，整個流量相對比較輕量。以上流程描述的是單個需求的處理過程，實際中，對于同一個app或者背景版本，一般是有多個需求并行的，而且不同版本的需求是有交叉重疊的。在一個版本研發的後期，通常會進行下一個版本需求的讨論和評審。
在本章的後續部分，以及後面關于品質管理和推動的章節，會對其中的多項重要流程實踐做進一步深入的講解。在這裡我們讨論需求評審和技術方案評審。需求評審是一個比較常見的研發流程實踐，但是實際上大部分人還是低估了其價值，執行的過程中也做得不夠充分。對于網際網路産品快速疊代的節奏，固然需求評審會花去一些寶貴的時間，但是事後來看，無論正面的案例還是反面的案例，這個時間花得還是非常值得的，正所謂磨刀不誤砍柴功。需求評審，特别是現場會議形式的評審，是一個非常難得的多方溝通的機會。多個角色可以統一對需求的了解，有疑問的地方可以及時讨論。
從測試人員的角度，需求評審的價值主要在以下幾個方面：
充分了解需求，為後續的測試用例編寫打下基礎。
基于對需求細節的了解，可以更準确地評估測試的要點和工作量。
發現需求中模糊不清的地方。從品質管理的角度，這也是一個非常好的缺陷預防的方法。
為了現場評審有更好的效果，并提高評審的效率，建議評審組織者在評審會召開之前将需求文檔提前發給評審專家進行預審，在預審結束之前評審專家預先将發現的問題發給評審組織者，這樣可以在會上針對問題進行評審，使評審更充分、更有效，否則需求評審會有可能會演變成一個需求講解會，進而達不到預想的效果。
除了需求評審，對于一些偏技術性的需求，或者一個全新開發的功能，很有必要做技術方案方面的評審。請對應的開發人員來講解一下準備采用的技術方案。一方面可以請其他資深的開發人員幫助評審，另一方面從測試人員的角度，了解基本的技術實作也有助于設計測試用例，并提前為可測性做一些準備。
下面這個例子可以幫助我們了解技術方案評審的價值。下面是一個偏技術類需求的例子，是一個自行開發的app端的sdk，用于将app遇到的一些異常問題彙總上報，包括crash和各種錯誤，其他營運類資料的上報也是類似的邏輯。在第8章關于監控埋點的部分也會做相關的介紹。
圖1-3是針對這個需求的一些測試用例。
從以上用例可以看出，如果不了解一些技術實作的細節，很多測試場景根本無法覆寫，比如：
未上報的臨時資料是通過本地資料庫來存儲，就會有相關的測試場景。其中資料庫檔案大小需要有一個上限，這個其實也是評審過程中測試提出來的，避免在一些極端情況下占用過多的存儲空間。
上報程序是基于接口下發的政策來控制上報邏輯的。這個部分也會引起一系列可能出現的問題。
對于一些可能遇到的異常情況，設計上是如何考慮的，這些其實在技術方案評審的時候就可以考慮到。
類似的例子很多，對于一個全新的功能也是如此，不同的開發人員會有不同的設計上的考慮，哪些邏輯放在app端？哪些放在背景？同步的機制如何做？有哪些新增的接口？這些都是技術方案上的考慮，不同的設計會帶來不同的測試場景和測試點。
不覆寫這些場景就會有很多品質問題的死角，而這些都是app性能和安全性的隐患。
關于流程，我們的觀點會更偏向實用主義，并不在乎是否是純粹或者經典的某種模式。比如上面的技術方案評審，也是來自于項目運作中實際的需求，讨論下來覺得部分功能有必要開展就加到流程裡面。
另外在工作中我們發現一個特點，在我們了解的幾個大的網際網路公司裡面，不太經常談靈活概念，而更多是根據業務運作的特點，以及團隊不斷的磨合，整理出一套相對有一定适應性的流程。
另外，還有一個觀點，對于一個使用者量很大的網站或者app，當版本有大量的需求疊代，比較頻繁地來做釋出（網站更明顯），每個需求的開發周期比較短，同時又是多個角色大量的人員合作，經曆了幾個版本，一段時間以後，大家就逐漸磨合出了一套适應這個需求的流程，并在過程中不斷優化調整。是以，所謂的網際網路的做法也并不是因為它比傳統的軟體流程先進，而是它更适網際網路産品的運作方式而已，本質上還是産品形态和需求驅動的。