這個項目並不是我所預期的那種，它跟一般的項目不一樣，沒有需求，設計和實現。我們所要做的就是解決Bug。可以這樣講，直接進入測試和維護階段。
我們的工作是很痛苦的，因為解決Bug本來就很痛苦，特別是當Bug數量較多，而時間又很緊迫的情況下。我們所處理的Bug也讓人感覺到什麼是鬱悶和糾結。因為Android是一個開源的系統，我們所拿到的東西就是達到幾個G的源碼。沒有文檔，沒有需求說明，沒有設計，就連代碼中的注釋都少的可憐。專案經理，開發人員，測試人員都面臨著一大堆不確定的東西。由於沒有需求說明，所以對於一個特徵的正確行為或期望行為到底是什麼樣的，沒人能給出正確答案。由於所有的人都不知道正確的行為究竟是什麼樣的，所以在相互溝通上浪費了大量的時間另外，由於缺少對系統的理解，所以對於本不應該修改而做的修改，就引發了大量的其他Bug。
後來的總結與分析證明，系統中真的由於代碼缺陷所引起的Bug數量是很少的。開始的一小部分Bug是由於測試對特徵不理解，造成的，理論上來講這並不是Bug。但開發人員在修改這些Bug的時候，由於缺少對系統的理解，因此雖然看上去修複了Bug，但是引入了大量的其他Bug。後來的大部分Bug都是由於前期的修改造成的。
本來這種不確定不足以引發這麼大的問題，但由於對方公司的制度問題，也引發了大量的不是Bug的Bug。而且其中的很大部分還做了修改。試想，給沒有缺陷的代碼做修改去修複本不是Bug的Bug，結果會是多麼的悲哀。對方公司的測試都是自由測試人員，以使用者的身份來測試，他們只要每天找到三個Bug就算合格。他們只有Bug數量上的要求，但對於Bug的品質卻從不過問，而且對方公司還按測試人員所提的Bug數量作為他們業績的主要參考。這就造成了，他們在找Bug的時候，帶著功利心理，不是以提高系統角度來測試，而是以找到問題（甚至故意製造問題），或是讓系統出錯為目的。因此，有此Bug讓人非常的無奈，這也浪費了項目群組成員的大量時間。最悲情的是為了修改某些本不要修改的Bug而做的修改又會引入大量新的Bug。
