1樓：樂穎
周期短，個人對模組或系統的了解是有必要的，如何快速知道怎麼去測，進而定位到問題。同時，免不了要回歸測試，維護好相應的資料、測試用例，拿來，修改，另存，完成任務後再慢慢整理文件類…
2樓：Frankie楊
一看就知道題主是傳統行業過來的人。
傳統的測試，覺得流程很重要、各種文件很重要、測試用例很重要、bug管理很重要，唯獨不覺得自己的大腦重要。
所以傳統的測試，一定會堅持測試要分好幾個階段，每個階段都要有若干的文件支撐，每個階段都會設計一些「高大上」的標準，用例的設計和撰寫是最關鍵的任務，而且測試用例還要分級要系統化管理，bug也要分級也要管理起來，測試報告要非常正式尤其格式必須符合要求。
就像演戲一樣，劇本、道具、分鏡頭、攝影、攝像、燈火、燈光、演員、後勤、彩排、剪輯以及後期乙個動作都不能少，好像完成整套動作就能保證作品的水準似的。。。
而敏捷下的快讀迭代，週期實在太短，所以真的無法完成這麼多真真假假的動作，所以傳統的測試感覺到無所適從了。
敏捷下，有些「假」動作就不必了，實打實地開動大腦去思考，拼的是真功夫！當然，會有很多人覺得那些「假」動作，是天經地義的、標準的、正式的、專業的測試技術，那我只能無語了。
「高達上」測試流程，不必！
各種測試相關的文件，不必！
測試用例的管理，不必！
bug管理以及「可笑的」bug統計，不必！
除去那些有水分的動作，實實在在的做測試。
說到探索性測試，我覺得需要測試工程師對測試物件有充分的了解，不僅僅是全面的了解，而且要有深度，形成乙個立體的了解 ------ 需求是乙個維度、技術實現是乙個維度、執行環境（作業系統、資料庫、網路等）是乙個維度！然後再加上積極的思考、靈活使用的工具、融洽的同事間合作等，形成高效的測試能力。
不必不拘泥於什麼白盒、什麼黑盒，也不必仰視什麼自動化。心裡能夠一清二楚，比任何測試技術都有價值。。。
產品怎麼快速迭代呢？
啊哈時刻產品經理 產品要快速迭代，一般就採用敏捷專案管理。Scrum是迭代式增量軟體開發過程，通常用於敏捷軟體開發。Scrum是乙個包括了一系列的實踐和預定義角色的過程骨架 是一種流程 計畫 模式，用於有效率地開發軟體 在每一次衝刺 乙個15到30 天週期，長度由開發團隊決定 開發團隊建立可用的 可...
使用者研究如何跟上產品的快速迭代？
UIDX 你弄反了。是產品迭代跟著用研跑，不是用研跟著迭代跑。乙個大用研可以規劃出至少2年內的產品路線圖。使用者研究不是研究 使用者現在喜歡什麼 而是研究 使用者是誰，他們什麼樣，他們會喜歡什麼 這樣我們才能決定 產品要做成什麼樣，向哪個方向迭代 說白了，使用者研究是決定目標的，行動是跟著目標走的。...
產品是快速迭代推動專案上線好還是追求極致沒bug？
阿歡 首先沒有bug是不可能的，其次使用者是需求推動的，如果你的初期產品可以解決使用者的某個痛點，就算bug一堆也不會沒有使用者，反而會在上線後被使用者和資料推動，確定下一步的迭代方向，這時候的方向是真實由市場反饋的，所以可信度還比較高。當前如果在開始推出產品時一點都不能用也是不行的，還是要有取捨，...