評論
打印
Narrator:Listen to part of a lecture in a Computer Science class.
獨白:聽下面一段計算機科學的課程講解。
The professor is discussing software engineering.
教授正在討論軟件工程的問題。
We've been talking about the software development cycle, and today I'd like to move on to the next stage of that cycle-testing, and why finding bugs during testing is actually a great thing.
之前我們一直在講軟件開發周期，今天我們進入下一階段的討論-軟件測試，以及為何在測試過程中找到bug是件好事。
Eh...eh... the quality of the software product often relies heavily on how well it's been tested. Liz?
呃，軟件產品的質量往往很大程度在取決于它的測試情況。利茲，有什么問題嗎？
Um... just a quick thing. Bugs are the word for problems in the program code, correct?
就一個小小的問題，bug是指編程碼存在的問題是嗎？
Yeah, in code or in a computer itself.
是的，編程碼或者計算機本身存在的問題都叫 bug。
There is a bit of a story behind that term.
其實這個術語的背后還有一個小故事。
Um... back in the 1940s, when the computer industry was just starting, a group of computer scientists was working late one night, and there was a problem in one of the computers'circuits1.
恩，追溯到 20 世紀 40 年代，那還是計算機產業剛剛起步的時候，幾個計算機科學家一直工作到很晚，因為計算機的一個回路出現了問題。
When they examined it, they found a five-centimeter long moth caught in there.
當他們去檢查的時候，發現一個五公分的飛蛾卡在了那里。
Once they debugged the computer, it worked just fine.
當他們拿走飛蛾以后，計算機就恢復正常工作了。
And ever since then, all kinds of computer problems have been known as bugs.
從此以后，所有計算機的問題都被稱為 bug 了。
Anyway, you want to find bugs while the software is still in the development and testing phases.
不管怎么說，bugs 最好是在開發或者測試階段就被發現。
Finding them when the software product has already been put on the market can be quite embarrassing.
如果當軟件產品已經投放市場了才發現 bug 的話，局勢就會比較尷尬了。
Generally speaking, every software development project has a group of testers and a group of developers. Jack?
大致來講，每個軟件工程都有一組開發人員和一組測試人員。杰克？
And they are different people?
他們都是不同的人嗎？
They are generally completely different group of people.
大致來說他們是由兩組完全不同的人組成。
My personal opinion is that they have to be different groups of people because developers often have a bias for their own work, and it blinds them to certain problems that might be obvious to somebody else.
我個人的觀點是開發人員和測試人員一定要是由兩組不同的人來組成，因為軟件開發人員總會自己的作品有些偏愛，這就導致他們忽視一些其他人看起來很明顯的問題。
So it is always good to have a different set of eyes to go in there and make sure that everything is tested properly.
所以說有不同的人來參與到項目中來的話，會使測試更完善。
Ok, now, here's the key. Developers and testers have different mentalities.
好啦，其實是這樣，開發人員與測試人員的心態是不一樣的。
The mentality of the software developer is constructive, creative, they are spending long hours working together to create and build something new.
軟件開發人員是有建設性、有創意性，他們往往花大量的時間來共同創建新的產品。
A software tester, on the other hand, their entire goal is to look at this product and find problems with it, to improve it.
而軟件測試人員的主要任務就是觀察這些產品并發現問題，然后來提升軟件的質量。
Now, this difference between the testers and the developers can lead to an environment where there is a bit of friction.
那么軟件開發人員和測試人員之間的不同就會引起一點小摩擦。
And that friction sometimes makes it difficult for the two teams to work together.
這種摩擦有時就會使開發人員和測試人員很難在一起協調的工作。
There are two projects that I worked on a couple of years ago.
兩三年前我參與了兩個項目。
One, which I'll call Project Split, well, the testing and development teams did not work well together.
我稱其中的一個為分離項目組，這組的開發人員和測試人員就很難在一起共事。
And the other, I'll call Project Unity, during which both teams worked very well together.
另一組我稱之為團結項目組，這組人員就合作起來很愉快。
Now, during Project Split, we had defect meetings where the developers and the testers met together, eh... eh... to discuss various problems and how they should be fixed.
第一組人員在進行缺陷討論會議時，也就是開發人員和測試人員在一起討論各種各樣的問題并找出解決方案，
And you could sense the conflict just by walking into the room.
你在一進入會議室的時候將就能感到那種緊張的氣氛。
Literally, the testers and the developers sat on opposite sides on the table.
準確來講是，測試人員和開發人員完全對立來坐。
Um... and ... and the developers were very defensive about the feedback.
呃，而且開發人員對收到的反饋總是持有懷疑的態度。
Well, if bugs are being pointed out they wouldn't be too happy since it's their work.
恩，當 bugs 被指出的時候他們肯定不會開心，畢竟那是他們做的產品嘛。
Exactly. Now, because the two teams weren't working well together, the fixes were coming very very slowly.
的確如此。正因為這兩組人員不能協調的工作，所以修正工作總是進行的很緩慢。
And you know, a lot of times when you fix bugs you introduce new bugs, or you discover bugs and other areas that only come to light because something has been changed, so fixing all those new additional bugs was also being delayed.
而且正如你們所知道的，有些時候當你在修正 bugs 的時候又會引發一些新的 bugs，或者在進行了一些調整之后，新的 bugs 才顯現出來，所以說這些新加的 bugs 總是未能及時修復。
Um... the test process went on much longer than expected and we ended up having to put the product on the market with known bugs in it, which was obviously not ideal.
呃，測試的過程比預期的要長得多，我們最終就不得不將存有 bugs 的產品投放市場，當然這并不是明智之舉。
Ok and what about Project Unity? How was it different?
好的，那么團結項目組呢？有何不同嗎？
Um... this was different because two teams worked closely together during the defect meetings, instead of put up walls.
恩，這組的不同之處體現于缺陷討論會上，開發人員和測試人員并沒有產生對立的局勢，而是很好的進行協作。
Um... we didn't even talk about, you know, who should fix this, which is at fault.
呃，我們甚至無需指明誰來進行修復，這又是誰的錯。
We all acknowledge what needed to be fixed.
我們也都知道到底哪些地方需要修復。
So if we had ten bugs, we said, Hey, you know what?
所以，假如說我們有十個 bugs，我們就會說“嘿，不如這樣吧，我們先來修復這個吧”，
Let's do this one first because this would expose another whole bunch of defects that we haven't even seen yet.
因為這樣就可以顯露出一系列我們還沒有發現的缺陷問題。
So we were being proactive and effective.
因為我們也很有前矚性和效率性。
And because we were so much more effective with our time, we were actually able to do more than just fix the bugs; we even put in some improvements that we hadn't planned.
正因為我們做事很有效率，事實上我們總能不僅僅是修復了bug，還能注入一些之前沒有計劃過的升級元素。
