昨天一個偶然的機會，臨時充當了下軟體測試的角色，體會很深！也讓我對軟體測試人員有了更多的瞭解和理解，並對自己（開發者）也提高了要求。
開發、測試不分家，心在一起，勁往一處用就可以大大改變產品的質量。這個道理大家誰都明白，但是我們是做到了60分，還是90分呢？這是值得我們深思的！
情景1：
我拿到一個產品，讓我測測，我首先根據自己的理解來測試這個產品，保證連結的正確，資料不敢保證，隨著測試的逐漸深入，我發現，有些功能根本不知道是做什麼用的。
感想：一個產品如果沒有需求文件，就算有使用文件，那又有何意義呢？
情景2：
我找到了需求文件，對裡面的內容進行檢視，多多少少還是幫助了我理解了這個產品的功能，但是好多頁面展現，無從考究！例如一些展現的關係圖，是根據什麼繪出來的？箭頭代表什麼？等等等等！總之給我的感覺就是功能依照使用手冊會用了，但是不知道是用來做什麼的！頓時你會想到，這些都是什麼做什麼用的？為什麼文件沒有寫清楚？難道還要我逐條寫下來，依依的問？
感想：情景2做到了60分，因為有了需求文件，但是這份需求文件，有跟沒有差別不大，主要是解決了有、無問題。對於根本性的問題還是沒有解決。
這時候想想我們自己做開發的時候，是不是以為這個很簡單，我們組內都清楚，就沒有寫在需求裡呢？現在想想，開發覺得自己明白的東西，往往別人是不明白的！看來以後寫文件的時候，我們需要轉換一個角度來寫這個文件。逐漸達到70分！
情景3：
找到開發問了這個功能，開發簡述一遍，是簡述哦！大體知道這個功能是幹啥的了，也能看到展現，但是展現的對錯與否，誰又知道呢？
感想：測試點很重要，我們的展現對錯，是要考慮測試人員對這個系統的理解，如果我們能夠在文件中，寫清楚測試點，那麼測試人員就會更有依據來判斷展現的內容是否正確了，如果做到這點，我相信應該可以打80分了！
情景4：
隨著時間的推移，我煩躁了起來，感覺能用，不知道為什麼用，每個功能都可用，但是如何串聯在一起呢？看了產品的SPD，使用手冊，沒有對各個模組串聯著用的一個概覽，這讓我和惱火，我當時心裡只有一個想法，這咋測？沒有需求評審嗎？雙方之前沒溝通嗎?
後來得知溝通過，需求是因為專案多，開發沒時間，只是簡略的說做了什麼，沒有說做到什麼程度，什麼效果！
感想：看來對需求的溝通事值得我們深思的，開會了、溝通了，依然沒有解決問題。所以我覺得只要是會議，一定要雙方達成一致，且一定要形成結論，不然那就是扯淡！話糙理不糙！就是這麼個道理！
本以為這一天的時間是浪費了。其實不然，通過這一天的實際換位，真正的達到了換位思考的效果，理解了測試人員的苦衷，也瞭解了一些作為測試人員最需要的是什麼樣的文件，需要的是開發怎麼的配合。同時自己身為開發人員的我，覺得在今後的開發中，一定要落實文件，積極配合測試人員！當然開發人員也有苦衷！但是我們需要先從自身找原因，解決掉自身問題，也許很多難題會迎刃而解也說不定呢？