Infoq發佈了文章，這裏我還是吐槽原文，未修改的，讓大家品味下：
2、無悔選擇測試之路-路上的抉擇、進取
有了流程規範，接下來是實施和持續改進，運用在一個項目上，先做了三個月吧，不停地測試，編寫功能測試用例，也走了2條彎路：
1、用例花了大量時間編寫，就連：打開瀏覽器，輸入xx，點擊登錄，這個也記錄了（這種是早期狀況）。
2、我居然還請纓加入開發，因爲看到一些任務完成不了，後來雷叔也指明，測試做測試應該去做的，如果我當時幫忙做開發，那麼很多測試都完成不了，一樣保證不了質量。
所以，測試人員除了要了解業務之外，使用簡單、清晰的語言結構來進行測試之外，還應該準確定位自己，明白自己在整個版本迭代中，控制質量的位置！
大家可能想知道，那段日子鍛鍊了什麼？那三個月無法忘記，每天高強度測試，用的最多的就是，功能測試：邊界值、場景法；白盒測試。其實就是鍛鍊了測試的基礎技能和流程管理。
後來測試管理逐步建立，但是在測試過程中，應當如何提高代碼質量，也參考了敏捷開發中高質量 Java 代碼開發實踐:http://www.ibm.com/developerworks/cn/java/j-lo-agile/，做了一些適合團隊的改進：
這6點不言而喻，這種迭代版本中java代碼質量提升的模式，已經採用了將近一年，非常有效果。
同年Q2，對測試管理進行了改進，其中是受到，@段念-段文韜，組織敏捷測試（http://www.infoq.com/cn/news/2011/01/dn-agile-test-3）影響，採用類似“一頁紙計劃”的測試文檔（在此要感謝@段念-段文韜）在redmine進行管理，之前每次整理測試計劃，發送給開發人員，實際上耗費了一些時間，並且成效不大，現在的任務：需求、開發、測試，全部交給redmine管理，所有事情一目瞭然，對任何人都是可見的，有沒有完成，進度如何，非常清晰。
ok，之前不是講過檢查表的做法嗎？雖然覆蓋了不少範圍，用了一段時間，收效不大，決定改進，變成季度性檢查，包括的方面比較多。
後來爲了規範整個開發測試流程的管理，包括開發、測試的交互，又制定了SQA框架，輕量級的：
圖 最初制定的SQA框架（2011年3月31日）
後來發生了比較大的變化，做的更好、更輕量級，無獨有偶，買了一本@朱少民老師，的：《全程軟件測試》，發覺這個SQA框架也是***到目前的每個環節，更適合目前團隊的scrum模式，在此也要感謝@朱少民老師，真是相見恨晚，不然可以少走很多彎路！！！
大家可能會問，scrum模式，有很多用戶故事，測試人員怎麼利用？爲什麼想到這個，當知道遺漏了測試場景，會很不爽，怎麼避免呢？加上@Aullyxiao的《軟件測試之魂》提到分層測試的想法，想了想，還可以結合這麼整：
對於目前的開發架構來說，一個用戶故事，或許涉及這四個點，可以從這個四個點入手來進行質量保證，如何做呢？單元測試就開發人員處理了，代碼審查，測試人員可以參與和監督，其實就是要保證將：開發任務與提交到svn的代碼進行關聯，這樣子，當測試人員檢查開發任務的時候，就可以找到改變過的代碼，曾經試過從這些代碼裏面查看邏輯，找到分支場景，補充到測試用例裏面。當然，在此期間，看過@架構師Jack，《功能測試用例基礎設計模型》，也採用了其中一些；還有@季哥來自淘寶，的探索式測試，我覺得自己還需要時間來消化。