當你遇到"程式碼就是文件"時, 要如何進行測試
Testing when "the code is the documentation"
http://blogs.msdn.com/joshpoley/archive/2008/09/03/testing-when-the-code-is-the-documentation.aspx
作者說在他工作生涯中, 經常聽到這個可怕的聲明: code is the documentation. (我常聽到的則是, 沒有改什麼, 或是這次需求很簡單, 所以不需要文件). 不管背後的原因是什麼, 反正你就是不會拿到任何文件, 來說明這個系統是如何運作. 當然啦, 拿到一份過時的文件, 也是同樣的慘狀.
(記得當年第一次看到"code is the documentation", 覺得真的很好笑, 不想寫文件就不想寫文件, 還可以用這麼有學問的方法來描述)
當作者遇到這種狀況時, 通常會利用以下模式來處理. (分成四個階段)
1. 先研究調查
- Spend some time upfront to get an understanding of what the software currently does and how it acts.
- A good chunk of time is used reading through and reviewing the code itself.
- Write a very basic (straight line) test making it easier to trace through the code in a debugger, which gives me a better feel for the program flow and organization.
2. 一邊製作一些測試, 一邊和RD/PM確認
- Once I have some understanding of what the code is supposed to do, I then start cranking out test cases.
- Throughout the investigation and while I'm writing and running the tests, I'm also communicating with the developer (and the PM if there is one) in order to answer specific questions about the behavior.
3. 解決衝突
- After I've written a chunk of tests, there are undoubtedly a number of areas where a bug may or may not exist depending on someone's point of view.
- Since I've written my tests based on my perceived conception of how the software should behave (and the developer has done likewise with the code) there will be areas where my test expects one behavior, but the program does something else.
- And without a specification to arbitrate, this often becomes a heated battle.
- Especially since the developer has already written the code (and is undoubtedly working on something else now), he/she will be reluctant to go back and change it based on the whim of a tester.
- This is where your persuasion and diplomacy skills come into use as you need to make a case and argue on behalf of the customer.
(作者描述的情況, 還真的是十分寫實. 因為大部分的狀況, 都是沒有文件. 所以常常出現各說各話的狀況. QA說要這樣反應比較好也可以, RD說要這樣實作也沒錯, 所以後期花在這樣的時間真的很多)
4. 將結果文件化
Documentation
- After finishing up the tests and the stability of the software has solidified, I typically go back and provide some form of documentation.
- At the very least I ensure to comment specific weirdness along with my tests. But depending on the area, I may also provide some high level information to co-workers.
- At the other end of the documentation scale, you could always go and write the specification yourself, which would definitely help to improve the maintainability of the system.
(或許QA會嫌棄RD不寫文件, 但每當到了這個步驟, QA也是常常不會去寫文件, 來描述他所學會或是探索到的東西. 這不是當一角色的問題, 而是大家真的都不喜歡寫文件.)
留言列表
