看了一篇關於軟測的文章，文中說到軟測的三個階段，最後乙個階段是說以人為本的測試，筆者略有感觸，所以也來談談「以人為本」的測試。
剛進公司的時候，筆者也非常痴迷於測試流程，cmmi之類，覺得流程框架之類很偉大，指引並驅動著我們的工作，每一項工作都應該有輸入輸出，並且符合標準，基線化猶如心中女神一般，充滿嚮往，心醉神往。然而軟體工程發展至今，即便像出現了各種各樣的開發流程，但由於其複雜性，易變性，等諸多其它人為因素，導致整個軟體工程中的各個階段都不可能百分百符合要求，甚至連百分之五十都沒有，於是最後到測試人員手中的交付物可能寥寥無幾，甚至質量低下，這不能說是其他人員的不努力，只能說是現狀仍然沒有乙個比較完美的解決方案來保證每一環都沒有偏差。
這是軟體工程的現狀，那現有的測試流程呢，我想一般公司的系統級別的測試流程大致多為制定測試計畫，寫用例，執行用例，跟蹤缺陷。如果說這幾個環節，每個都做到位，我想這樣的測試一定是能夠給軟體帶來極大信心的，只是又有多少人知道該怎麼寫計畫，該寫些什麼，用例該怎麼寫，該測什麼；大部分人都知道等價類邊界值這樣的測試方法，然而究竟該怎麼樣劃分這個等價類，邊界到底該定在**，又有誰能準確無誤地描述清楚呢。流程規範告訴我們要覆蓋所有的需求和功能，流程規範還告訴我們每個功能要用等價類邊界值，異常分析等等方法去測試，流程規範又告訴我們要用用例去覆蓋功能，這樣的測試是充分的，是全面的。誠然，這些都沒錯，但是實際上可能嗎。接著說到執行用例，一套不完備的，可能描述都有欠缺的，測試目標不明確的用例再去被執行，其結果可想而知，究竟有多少用例是有價值的，是能夠真正發現問題的，這的確是需要打乙個問號的，在實際的工作中，發現問題往往並不是依靠執行用例，而是測試人員的個人能力，於是引出「以人為本」的測試。
按照用例按部就班地執行無異於抹殺了測試工作者的智慧型，軟體工程正是因為其複雜性、創新性而區別於工廠流水線，一味地按照某乙個固定的框架、規定、流程、程式之類必定是要死的。尤其是測試，測試人員需要的不是高效的執行率，循規蹈矩的態度，亦或是各種陳舊的方法技能，需要的是自身對於測試理解的高度，一種批判精神，一雙敏銳的眼睛，一顆求真執著的心，和乙個時刻都會有些古怪想法的腦子。在測試過程中，更不應該按部就班地執行用例，而是要不斷探索，不斷挖掘，帶著一顆好奇心，像來到乙個新大陸一樣充滿熱情與興奮。系統正常流程是這樣，那如果我按一下那個，再點一下另外乙個會怎樣；如果我在位址列裡輸入這些引數會怎樣；如果我突然關機，突然斷線，會怎樣。時刻有這種新奇的想法，一定會帶來一些意想不到的結果和體驗。測試人員更應該比開發人員具備開闊的思維和想象力，來向開發展現另乙個不一樣的世界，他們從未到達的一種境界。開發關注的是如何實現，測試就應該關注開發沒有想到的事情，甚至是前端業務人員沒有想到的事情，這就是測試人員的高度，對於業務的精通，對於軟體本身的熟悉，對於需求和功能的理解，都必須得有自己獨特的見解和想法。依賴於個人經驗和能力的測試才能真正做好測試這份工作，把這份工作帶到乙個新的高度，與公司層面相匹配的高度。
不管任何工作，只有真正「以人為本」，才能發揮自身最大的潛能，帶來最大的效益，測試人員是可以證明這些的。
敏捷開發 開發以人為本
再談了需求 甚至可以說是complains 之後，就可以切入正體了，並且我將以我的乙個專案經驗來闡述敏捷開發？事實上我對這其中的許多方法學感受不深，不過我下面會談到我參與過的乙個算是用了半個敏捷開發的專案吧。不過我首先想提出的做為乙個程式設計師，如果要開發乙個專案，你第一件事想到的是什麼？是設計嗎？...
以人為本的質量管理
目錄 一 沉浸式的事後質量管理 二 草船借箭式的預防質量管理 三 領導作用 人本管理的實踐 質量管理領導力 這本書主要講解的質量管理領導力，是基於人本管理，包括兩個方面 從上到下由公司高層推動質量，形成的質量管理領導力 自下而上由基層員工參與 反思 解決流程 制度 質量等問題，養成的質量管理領導力。...
軟體企業以人為本的16項措施
以人為本不能停留在口頭上，要落實到具體的實施上，以下是我的實踐或是我在軟體企業看到的實踐 1 重視現有的員工勝過去搜尋外面的新人 2 鼓勵員工在職深造，學成歸來的要重用 3 招高水平的員工進來 4 穩定的高於本地域行業平均水平的收入，使其沒有後顧之憂，專心事業 5 為每乙個員工進行職業路線的規劃 6...