這個話題挺有趣的,是「少數服從多數」呢,還是其實是「多數暴力」?
記得應該是小學時,學校為了讓學生們開始有所謂的「民主」觀念,開始教導「少數服從多數,多數尊重少數」這樣的觀念,小一時幹部應該會由老師指定,小二或小三之後幹部就開始用「投票」的方式進行。隨著年紀的增長,越來越多「表決」的事件開始發生,例如贊不贊成該週小考取消?某個自習課可否臨時改體育活動?校外教學要去哪裡等等。
大概自小五小六或國中時,學校課程開始教到自然科學與物理化學,開始介紹到像是牛頓、伽立略等人,這個時期我們學到了,原來在十六世紀以前,人類是認為「地球」是宇宙中心,地球是平的,太陽從東方升起,從西方落下(註1)。直至「哥白尼」、「克卜勒」、「伽立略」等人相繼提出新的天文觀點,質疑過往認為地球是靜止不動的宇宙中心,甚至伽立略還「激進」的提出地球應是繞著太陽而轉,這樣激進的言論不能被教會所接受,伽立略因此終身被禁錮在家中不得與外界接觸。
註1:西元二世紀的「托勒密」認為地球為宇宙中心,其他的天體分別固定在許多不同的球面上,繞地球作圓形運動。
所謂的民主便類似這樣,當你與多數人的意見不同,即使若干年後證明你是對的,但在當時你就是錯的。只是較為先進的民主觀念,希望能夠尊重少數人的聲音,大抵是很多事情並不是明顯的對或錯,只是多數人比較傾向於某種做法或看法,在能力所及,如果能讓少數不同意見的人也能夠有所滿足自是最好。就好比說即使紀律嚴明的軍隊也會特別為素食者另行準備餐點,更別說一般人的宴客也常見會為素食者準備特別餐點。
但是多數暴力是怎麼回事?簡言之就是多數的既得利益者僅為自己的便利而行事,並未去考慮其他少數者應有的權益。
偶爾我會搭乘捷運上班,正好我上班的路線與尖峰時段的人潮方向相反,更詳細的說,我上車地點本身就是個商業區,因此從捷運站出站的人潮相當的多。捷運站在地上畫有進出站的動線,但上班尖峰期,出站與進站的人數比例可能是 50 比 1 ,甚至是 100 比 1 。也就是說突然間湧出 100 人出站,同時卻可能只有 1~2 人進站。即便四部手扶梯動態的調整成三部出站一部進站,但通到卻總是塞滿出站的龐大人潮,大約八成以上的出站人潮無視於地上的動線,大辣辣的逆向走在應屬進站的動線上,大概心想反正沒什麼進站的人嘛,有何不可。僅有大概一至二成的人遠遠的若看到有進站的人靠近,會盡量空出通道讓進站的人得以行進。這就是一種多數暴力的表現。
多數暴力,大概是群居動物的天性吧。偶爾電視轉到 Discovery 或是國家地理頻道,看到拍攝野生群居動物的生態,有時就會看到某些較弱勢的個體被群體所排擠,搶不到較暖的地方避寒,或是搶不到足夠的食物,漸而變成體弱多病,當遇上獵捕者時,則往往成為必然的犧牲品。
想要改善,還是只能盡量自發的去關懷周遭,注意他人的感受,在行有餘力時多給其他人一些空間吧。這種風氣是要靠群體養成的。
Categories
2007年11月27日
「少數服從多數」還是「多數暴力」?
2007年11月25日
何謂專案
有些人對於專案的定義不是很清楚,甚至容易與常態性的管理事物混淆在一起。簡單的說,專案是指在一定時間內,為了完成特定目標的組織活動。好比說一家做進出口貿易的中小企業,如果老闆擬定了一個目標,要業務與相關行銷人員針對年終至隔年農曆過年期間進行某一產品的進口促銷方案,這就可以被當作一個專案來看待。
因此,專案包含了以下的幾個特性:
- 明確的目標
- 特定的時間(明確的開始與結束時間)
- 非重複性(非日常例行姓事務)
- 特定的人員
哪些事務不屬於專案管理的範疇?例行性事務,例如公司總務或行政人員每日每日的例行性事務,發放薪水、三節禮金、勞健保管理等;系統管理員每日的系統維運工作;學校老師年覆一年的教學工作等。簡言之,屬於重複的例行性工作事務並不屬於專案管理的範疇。
如果看一個產品的某一版本,他的規劃直至產出的過程是一個專案;但如果把焦點放在這個產品線是會持續延續下去,例如 2.0 版開發將至最後完工階段,便會開始研發下一個 3.0 的新版,那麼這個產品線本身應屬於一個計畫(Program)而不是專案。
2007年11月15日
是文化入侵還是全球化的常態?
生活周遭有越來越多的文化入侵的跡象出現,但是,究竟是文化入侵,還是全球化的常態之一?
當你在跟別人允諾你一件事情時,過往的人或許會說「好的」,但你說「OK」好像也並不會怎樣特別。當你發現你統一發票中獎了,你或許會說「太棒了」,但你如果說「wonderful」就似乎有點刻意了。有些詞語是隨著各國之間的文化交流越來越多之後,便會逐漸的習慣在日常生活的詞語裡頭夾雜著來自其他國家或地區的特定詞語。
生活在台灣這片土地,外來用語的逐漸普遍,似乎多數的人感受不深,但喜愛看日劇的人,或是有學日語的人,便會知道現代日語裡有相當多的外來語,有些外來語在日本統治台灣的時期甚至沿用至今,很多人還誤以為是台語。例如「機車」,你說「歐都麥」也不太有人會聽不懂,但其實他是日語裡的外來語,原是英語的「autobike」。
自從台灣解嚴之後,各地方語言開始重新被重視,台語也有相當數量的用語被「國語化」或者說生活化了。生活周遭會經常聽到國台語夾雜的對話,多數的人也習以為常了。
然而,玩電腦的人大概是較早面對來自對岸用語的其中一個族群。過往有不少中文的資訊來自對岸,或是有不少的軟體被翻譯成簡體中文,早在 Intel 80286 的倚天中文時代便已經有簡體中文轉換繁體中文的程式了,於是,只要簡單的轉換內碼,簡體中文便可用繁體中文對應的內碼與字體來呈現。例如「工厂」可以被正確的轉換為「工廠」,「电视」轉換為「電視」等。
但有些詞語是在不同的文化背景之下衍生出不一樣的慣用說法,或是有些是翻譯自國外的詞語,翻譯的結果略有不同。舉例來說,常見的「Default Value」台灣慣用「預設值」,大陸的翻一則是「默认值」;「password」兩岸雖都說「密碼」(密码),但大陸那邊也有說「口令」的;Windows XP起安裝後必須要「Activate」,台灣翻譯成「啟動」,大陸說「激活」;當要建立一個新的文件時,台灣說「新增文件」,大陸說「创建文档」......
對於說慣、用慣「預設」、「啟動」、「新增」、「檔案」等這些詞語的台灣人,看到「默认」、「缺省」、「激活」、「创建」、「文档」等字眼,應該多少會感到不習慣。
還記得給年前我初次到大陸出差,那邊的同事對我說要請我向上面申請一樣東西,他連說了數次我都全然不知他在說什麼東西,我甚至請他乾脆講英文罷了,最後才知道他是說「U盤」,也就是早期我們說的拇指碟(現在很少這麼說了),或是隨身碟。
現在隨著兩岸開放,許多電視劇往大陸那邊發展,兩岸的演員合作來演,已經分不清究竟屬於台灣電視劇或是大陸電視劇了。也因兩岸的文化交流越來越頻繁,更多大陸那邊的用語開始出現在生活周遭,好比有些新聞主播開始把「火紅」放在嘴邊,過去台灣是不會用「火紅」來形容一個藝人正值頂峰時期,通常是形容某某人很「紅」。在大陸那慣用「很火」,等同於台灣這邊說的「很紅」。
我著實想了好一會,這是文化入侵還是全球化的一環?即使像是全球化的一個部份,但怎麼想也覺得與「外來語」不太相似。外來語,直覺會覺得是近似於「歐都麥」、「韓都魯」(方向盤,handler)、「OK」、「soga」等這一種類型,但來自大陸那邊的用語融合進台灣這的日常生活,卻怎麼也不像一種外來語。想了想,如果說把大陸的用語,與國台語混用的情況作個比較,卻突然發現這樣的相比挺相似的。
說慣台語,或是處在很多人講著地方語言的環境,自然而然對於國台語夾雜的狀況能夠適應。一個原本不太會說台語的人,久而久之也會習慣這種國台語混用的情況。大陸用語出現在台灣這邊的日常生活中,情況挺類似的,如果就把他視為是某個地區的慣用語言,簡言之,把他視為方言的一種,似乎就很能理解了。
2007年11月14日
店內人氣與營收之間的關係
一些可讓顧客久留的商店,例如餐飲店、書店等,人氣的多寡,與其營收不見得成等比例。其中一個因素在於顧客的消費額度,以及顧客的流通率。
設想一個步調很快的早餐店,姑且不看外帶餐飲的顧客,若這家早餐店在店內用餐的顧客,平均都是大約 10 分鐘就會離開,假定店內共有 30 個座位,則一小時內大約會有 180 位顧客,也就是說平均每個座位在每小時可以服務 6 位顧客。
如果對比一家咖啡連鎖店這種顧客往往會喜歡在店內待較久的店,同樣我們以早餐的熱門時段來作推估,假定顧客平均待 20 分鐘後離開,也就是說每個座位平均每小時可服務 3 位顧客,若該店同樣有 30 個座位,則一小時內僅能服務 90 位顧客。
如果說你今天開了一家店,一開始客人不熟悉你這家店,但逐漸的你的知名度越來越大,客人也越來越習慣與喜歡你這家店,直到有天你店內開始在黃金時段以及前後一~二小時之間高朋滿座,先別高興的太早,也別高興太久。要分析一下營收是否真的增加了。
我有時候看到有些店,顧客可能進門只點個基本餐,然後就在裡頭待上個 2 ~ 3 個小時,如果說是人少的時段也就罷了,若是尖峰時段,那將會影響到可服務的客人數,自然也就影響到總營收量。最明顯的例子是速食店這種屬於半開放式的餐飲店,顧客在一樓點完餐就到二樓以上的樓層用餐了,結帳完畢之後,店員將不需要再為顧客進行服務,也不會去理睬顧客。則當顧客在店內待很長的時間,那麼當座位不足時,想要內用的顧客便將受到影響。
在鬧區或是補習班密集的地區的速食店經常是一位難求,仔細一看,會發現很多學生在裡頭看書,桌上僅有一杯飲料,這些學生可能一待就會待上三小時。類似這種例子,將會是營收的一種盲點,即看似高朋滿座,但實際的進帳卻有限。
因此,假若在鬧區開店,要斟酌一下希望可以讓顧客待多久。或者說,必須要好好評估總成本,然後去計算平均每位客人的消費額,再比較平均每小時必須要能夠服務多少顧客才能攤平成本,以這樣的角度思考應該怎樣規劃店內的桌椅擺設,以及店內的氣氛。
如果說希望客人只是到店用餐後就離開,並不希望客人久留,那就應避免讓店內氣氛過於悠閒。如果希望提供一個可以讓客人久留的地方,那麼不僅是店內應舒適之外,也要好好考慮提高餐點的單價,必須有類似「出租空間」的概念,才能攤平成本。
2007年11月12日
差異版本翻譯
之前提過關於同步翻譯(不是同步口譯)的主題,在這裡繼續提同步翻譯的想法。不過我想到其實有時這也是一種差異版本翻譯的概念。
翻譯領域裏藉由電腦輔助翻譯軟體(Computer-Aided Translation,通常簡稱 CAT)以及翻譯記憶庫(Translation Memory)的技術,可以有很多方式處理新舊版本之間既有翻譯的沿用。
舉例來說,假定以下為檔案A在1.0版時的前10行:
properties.A.01.name=File
properties.A.02.name=Edit
properties.A.03.name=View
properties.A.04.name=Format
properties.A.05.name=Tool
#
properties.B.06.name=Open
properties.B.07.name=Save
properties.B.08.name=Save as
properties.B.09.name=Close
並且其對應的中文翻譯為:
properties.A.01.name=檔案
properties.A.02.name=編輯
properties.A.03.name=檢視
properties.A.04.name=格式
properties.A.05.name=工具
#
properties.B.06.name=開啟
properties.B.07.name=儲存
properties.B.08.name=儲存為
properties.B.09.name=關閉
當下一個 1.1 版新增了一行,而使得前11行變成下面這樣:
properties.A.01.name=File
properties.A.02.name=Edit
properties.A.03.name=View
properties.A.04.name=Format
properties.A.05.name=Tool
properties.A.06.name=Insert
#
properties.B.06.name=Open
properties.B.07.name=Save
properties.B.08.name=Save as
properties.B.09.name=Close
我們的目標是既有的翻譯要能夠盡量的被沿用,以程式開發者的角度來看,假使比對 1.0 與 1.1 之間的差異,事實上是在第5 及第 6 行之間被新增了一行,其他部份並沒有異動,理論上在中文的翻譯檔案裏只需要對應的插入這新的第六行的中文對應翻譯即可。於是 1.1 版的中文應如下面所示:
properties.A.01.name=檔案
properties.A.02.name=編輯
properties.A.03.name=檢視
properties.A.04.name=格式
properties.A.05.name=工具
properties.A.06.name=插入
#
properties.B.06.name=開啟
properties.B.07.name=儲存
properties.B.08.name=儲存為
properties.B.09.name=關閉
不過事實上並沒有這麼簡單。版本之間的差異往往不會只有數行的新增這麼單純,複雜時數十行的新增、刪除、以及異動都可能會有,目視差異來進行手動的版本同步將不再可行並且易有疏漏。
不過,暫且沿用上面這較簡單的例子,一些翻譯的技術可以辨識出既有的翻譯對與新的來原是否相符,若相符則可沿用既有的翻譯。
然而,為了使翻譯能夠更精確,能夠處理相同的來源文字在不同地方具有不同的翻譯,部份的技術採用了上下文比對的方法,以滿足來源文字與目標文字一對多對應的需求。
簡單來說英文的 State ,查一查字典,它在不同地方將可能代表了「州」或是「狀態」。在地址輸入的欄位中把 State 翻譯成「狀態」可就不妙了。上下文筆對的方式便可以使翻譯配對能夠有更廣的選擇。
然而,也因為上下文比對的採用,像上面再簡單不過的例子,也可能導致一些既有的翻譯無法被配對而採用。某些上下文筆對的方式,是取前、後一至數行的文字作為參考文字,因此以下的兩個例子會被視為不同的文句(灰色文字表示為參考的上文或下文):
A:
properties.A.02.name=Edit
properties.A.03.name=View
properties.A.04.name=Format
properties.A.05.name=Tool
#
B:
properties.A.02.name=Edit
properties.A.03.name=View
properties.A.04.name=Format
properties.A.05.name=Tool
properties.A.06.name=Insert
於是,僅僅因為新增了 Insert 這一行到第六行,將可能導致第四行被認為在新的版本裏上下文與舊版不同,而既有的翻譯配對將不會自動被採用(被視為不是完美配對 Perfect Match)。即使它的相符率可能僅僅是降為100%或是99%,但是這也將可能導致額外的工作量增加。
過去提過的同步翻譯,或是協同翻譯的想法,其實是在討論像這種差異版本之間的翻譯應該怎樣來處理較好。以程式開發者的角度來看,當同時有多人在開發同一套程式時,開發人員經常要做的一件工作便是程式合併(code merge)的工作,必須進行版本間的差異比對,然後將自己的版本與另一人的版本、或是與主版本進行合併。
簡單的說,如果過去我曾經複製了檔案A的 1.0 版,一個星期後檔案A異動至 1.1 版,我可以藉由比對 1.0 與 1.1 之間的差異,發現是在第六行新增 Insert 這一筆,則我可以將這差異加入我手上的 1.0 版的第六行位置,而達到與 1.1 版同步的效果。
目前常見的翻譯軟體對於這種差異版本的翻譯沿用技術並不全然是如上述這般,這導致其實我們僅僅需要針對「properties.A.06.name=Insert」這一行進行翻譯,然後加入中文版裏,變得更加複雜。
這問題大致是因為現有的翻譯技術僅是基於翻譯對(Translation Pairs)來進行比對,頂多再加上該翻譯對的前後文作為參考資料,但並沒有真正去記錄檔案版本間的差異。
過去至今已有很多程式版本管控的系統,諸如 RCS (Revision Control System) 、 CVS (Concurrent Versions System) 、 SVN (Sub-Version) 、或是微軟的 Source Safe 等,儘管有些只是單純的版本管控,有些是為了可應付多人同時開發的版本管控,但大體而言都解決了版本間差異的管理。翻譯的技術如也能處理這種版本間的關連性,應該可以為翻譯的效果帶來不錯的改善。
簡而言之,上面提到的例子理想上僅需翻譯「properties.A.06.name=Insert」而得到「properties.A.06.name=插入」後,藉由 code merge 的概念再次加回目標語言中。
如果有次版本開發概念的人應該更容易理解。概念上就好比在程式的主版本支幹上,另行建立一個分枝(建立另一個語言的分枝),每當主支幹有異動時,藉由比對主支幹新舊版本的差異,將差異同步至分枝裏,而達到與主支幹同步的目的。
2007年11月9日
軟體平行/同步/協同開發下的軟體翻譯工程
6/19/2007
過往比較常見的軟體翻譯工程,普遍鑑於原始版本 (source version) 已經完成或是接近軟體開發的最後階段,才會開始進行軟體的翻譯工程。對於大型商業軟體而言,由於軟體開發週期常,加以引用不少先進軟體開發技術,當軟體開發已達80%左右的完成度時,多數的規格以逼近底定,此時不太會有新功能的引進,因此諸如操作流程、界面、功能呈現等皆不會有大的變化,在這個時期提前開始進行翻譯工程,即使在最終 RC (Release Candidate) 版本仍有外抽字串的變動,也僅是小幅度的變動。
在這種傳統的開發模式,亦即非平行開發 (parallel development) / 同步開發 (concurrent development) / 協同開發 (collaborative development) 的模式下,翻譯工程是基於來源語言 (source language) 是處於穩定狀態下來進行的。因此,即使在軟體完成度僅達 80% 便開始進行翻譯,直至最終軟體邁進 RC1 甚至 RTM 版本,之間的來源語言頂多只會有小幅度的變動,例如低於五次的小改版。
在此類來源語言處於一個穩定的狀態下,翻譯工程常見的是在第一次進行全面翻譯,當翻譯完成時,會建立翻譯記憶庫 (translation memory) ,則之後每次的小改版,依舊拿新的來源語言版本來進行翻譯。藉由翻譯記憶庫的對應 (mapping) ,未有變動的字串將可獲得 100% 的對應翻譯,則翻譯僅需針對變動字串以及新字串來進行即可,篇幅以及工作量將會很小。
試想,假設當翻譯工程開始進行,直至最終的 RC 或是 RTM 版本之間,來源語言有太多次的變動,例如多達十次以上的變動,或是週期性的,每週甚至每天皆有一個變動,並且希望翻譯可以盡量跟上來源語言版本,那麼既有的模式便會變得過於煩瑣、擾人、且不太實際。
另一種狀況,若是翻譯工程在軟體開發的很早期便開始進行,例如在軟體開發完成度達到 50% 便開始,加以期間的變動相當頻繁,且希望翻譯的目標語言可以盡量與來源語言版本同步,那麼翻譯工程勢必得思索一個更有效率的方式來進行。
舉一個例子,當第一次進行翻譯時,假定此時是基於 Rev.010 來進行,並且此時來源語言共有 1,000 行(假定每行對應一句來源語言),翻譯進行了一週完成,此時來源語言版本已更新至 Rev.011 ,並且新增/異動了 10 行。姑且以每週會產出一個新的版本 (Revision) 並且預期每週平均會有 10 行的來源語言字串的異動,那麼意味著每週進行一次的翻譯工程,其實只需確保這異動的 10 行能夠同步至翻譯的版本。若採用傳統的模式,則每次皆是進行約 1,000 行的自動翻譯(自翻譯記憶庫找尋已有的對應),然後再找出異動的字串來進行翻譯,以其達到與新的來源語言版本同步。
如果採用另一種方式來進行,即利用比對工具,將 Rev.010 與 Rev.011 之間的差異匯出,只針對差異進行翻譯,然後將翻譯完成的差異,匯入原已翻譯好的目標語言版本 Loc.Rev.010 ,則達到與 Rev.011 同步的結果,因此可稱為 Loc.Rev.011。這樣的模式,僅需要針對差異來進行翻譯,而不須頻繁的針對 990 句不會異動的字串一再的進行重新翻譯(自翻譯記憶庫自動比對)。
業務的外移
企業為什麼要把業務委外?
先回頭想想自己家裡有沒有哪些業務算是委外了。家裡有哪些工程是比較困難的呢?油漆粉刷、冷氣安裝、衛浴設備更新、熱水器安裝......通常這些工程我們會請店家來進行施工。過去主要是因為技術門檻較高,不得不請專家來進行。隨著人工越來越貴,另外加上自動機具越來越普及, DIY 風潮開始風行,較為簡易的像是粉刷、實木地板拼裝等,已經有不少人開始自己著手進行。前提自然是要有時間,外加有這樣的興趣,並不單單為了省錢。
上面看似舉了一個反例,其實,再仔細想想,自己周遭有沒有哪些事情,在過去五~十年以前,多半都是自己來的,現在卻逐漸變成「委外」了?肯定有的。諸如洗衣、燙衣、裁縫、三餐、甚至是住宅清掃。不少雙薪的夫婦,由於上班皆必須穿著正式西裝或是套裝,而這些衣服基本上自己處理挺為麻煩,因此多半送洗,當然這麼做的人一方面也是經濟負擔上較輕,以金錢換取時間;三餐呢?試想,老一輩的人,早餐在家吃,午餐是早上會是前一夜準備的,晚餐依舊回家吃,等於三餐都吃家裡,而現在有多少上班族,甚至三餐都在外吃!?那麼,把外食視作個人餐飲委外,是不是一個合理的說法呢?
企業為什麼要把業務委外?假設一個重視整體產品品質的公司,逐漸發現到長期雇用專人來編寫產品使用手冊,似乎有點負擔不了了,不管是手冊量越來越多,或是因為行銷國際的關係,使得手冊必須編寫多國語言,假設依舊自己編寫的話,勢必得要聘請更多的專人來負責。編寫本國語言的手冊也就罷了,一個文筆不會太差的專科生可能就可以勝任,但是要編寫其他語言的手冊呢?至少得聘請個大學外文系生,還不見得能寫的一手通順的文章,工資比起專科生馬上貴上許多。更別提還得寫多國語言!這時怎麼做呢?請翻譯設翻譯吧!這就是委外的一種了。
很簡單的一種想法,當你用自己的時間與人力來作,對比外包給其他人來作,省下來的金錢比起你自己做來的多,或是省下的時間你可以產出更多的產值,那就值得外包。
舉個例子,一個知名律師假設在其下班後兼差沒有什麼疑慮的狀況下,單單的法務諮詢每小時以500元計(這真的已經是很少的了),試想,這位律師週末是要花八小時來打掃家裡上上下下,還是花個兩千元請人來打掃,然後自己去做這法務諮詢,扣除雇傭花費,還可淨賺2,000?
業務的外移,如果不是為了省更多的錢,那自然是不需要去考慮的了,誰都想要自己一把抓,因為總是自己親自參與才會確保事情能更盡量如己所意,交給其他人,不見得能符合自己的想法。但是,只要藉由一些有效率的管理方式,便可讓事務快速的交給專業人士來進行。不管是自己找出有效率的交辦方式,或是找尋專業的人士來全權打理。
想想看自己上班的公司,有哪些業務是委外的吧!
清掃肯定多數都是委外的吧!
影印機的維護也多半是委外!
空調的定期保養也是!
地毯的定期清洗更不用說!
有些公司甚至把IT委外了!
委外這樣的事情,小至從自己身邊便開始發生,大至公司、政府多種事務都有委外的事實。
不驚不怪、不稀不奇!
Applications that are easy to be used
In the "Designing Interface" book which wrote by Jenifer Tidewell, one section is quite interested.
跟不上全球潮流的外資企業
Professional
方法論
賺錢有素, 盜亦有道
Rosenbluth Travel's success - The customer comes the second
The secret of Hal Rosenbluth's success, and his company's, is actually very simple. He concentrates on his employees first and his customers second. The formular works. Rosenbluth Travel was named one of the top ten in The 100 Best Companies to Work For In America, and happy customers have quickly transformed a small family business into a global industry leader, grossing over 1.5 billion annually.
In "The Customer Comes Second", Rosenbluth Travel's CEO and entrepreneurial genius, Hal Rosenbluth, reveals new ideas for hiring, performance reviews, technology innovation, and creative compensation. He shows how to build highly effective teams, inspire loyalty, and turn your workplace into a hotbed of creativity where people produce truly incredible results.
Find out why this book is causing such a stir; how it can transform you and your company. By the way, your customers will love it.
Link
Upgrade path
All softwares have their own upgrade path. A mature software will provide you very clear way that how you can do on your upgrading.
Testing all the possibilities?
When you are in high school, there is a lesson in mathematics class to teach you how to count the probability.
The lesson started with something like you need to pick up a red ball inside a black box.
The first thing you need to know is how many balls there, then you need to know how many red balls.
If there are 10 balls and only one red ball, then you will get the result that the probability to pick up a red ball is 1/10.
The lesson will then teach you how to count something more complex.
A similar example is to count the probability that you pick up a red ball and a blue ball from the black box.
If there is totally 10 balls inside the box, only 1 red ball and 1 blue ball. Then the probability is 1/10 * 1/9, which is 1/90.
In the real world, the reason it's so hard to list all the possibilities is due to we may not be able to find all the variables. In mathematics, you can, but in the real world, you can not.
A Sample Test Plan Structure
Below is a sample Test Plan structure which I created before for some project.
1. Background
2. Purpose of this Document
3. Reference
4. Features to be Tested
5. Features not to be Tested
6. Test Approach
7. Test Item Configurations
7.1 Rack Configuration
7.2 Platform Configurations for Each Testing Item
7.3 Environment Locale to be Tested
8. Resources
8.1 Human Resources
8.2 Hardware Resources
8.3 Software Resources
9. Test Cycle and Schedule
10. Risks
11. Assumptions
12. Test Entrance/Exit Criteria
12.1 Entrance Criteria
12.2 Exit Criteria
13. Defects Reporting
14. Contacts