救災領導 VS. 敏捷開發方法

有關《哈佛教你發揮救災領導力》一書，還沒說完呢！
現在要來談談《哈佛教你發揮救災領導力》和敏捷軟體開發之間的關係。

第27頁
「現實不斷變化，保持情境體認是永無休止的工作。」

第30頁
「專家團隊必須共同探索、試驗和創新，整合深厚的知識與構想，而不只是應用它們。各個成員必須機動地因應情勢需要，靈活地加入或退出各個工作群組。」

第35頁
「礦工通常在鑽孔完成，到達目標深度後才測量結果。在團隊領導人建議下，聖荷西的鑽探小組開始每隔幾小時便測量結果，一旦發現鑽孔出現太大的偏差便放棄，並重新鑽孔。」

第36頁
「…及時評估的做法，讓團隊花在無用鑽探工作上的時間與資源減至最少，而且可及時糾正偏差。」

第37頁
「…快速受挫、快速學習…，因為時間是他們最缺乏的資源。」

第39頁
「…，這意謂著企業必須從一個秩序井然的順序流程，轉換到一個動態、反覆的流程」。

第40頁
「要求專案的全部利害關係人，從一開始就以團隊形式合作，交流構想，尋找解決方案…」

第41頁
「現在的威脅與機錢愈來愈模糊不清、變幻不定，因此需要更具彈性和創意的團隊合作，需要領導人懂得同時控制與授權。」

以上。很令人驚訝吧！居然這麼多符合 Scrum 施行的要點。
這裡只是從第一章【智利礦場的領導課】中的例子，其實第二章【挺過核災的領導力】中也有相通的概念，而且更從團隊的角度去看。

這樣能不能激起軟體人也來看看這本書的欲望呢？

《哈佛教你發揮救災領導力》分享

今天來討論的是《哈佛教你發揮救災領導力》這本書。
全書分為：
1. 第一部：共四個章節，選輯自HBR(哈佛商業評論)。
2. 第二部：一個導讀、四個章節，由國內學界人士執筆。

第二部比較像極短篇小說，第一部相對為文較嚴，基本上文風不同；HBR的文章裡的個案事例較具體全面；國內學界的案例就比較接近個人心理及本土事例。

以下是一些分享：

1. 【智利礦場的領導課】及【挺過核災的領導力】兩章，均強調了：「抱持希望，但不掩飾真相」的精神。顯示面對災害，應該面對現實、以理性為基礎。

2. 現實是變化的永無休止，只有不斷地意義建構(sensemaking)、與成員溝通並達成共識、作出調整才行。總之，要讓「事情持續進度和讓事情恢復秩序的狀態之中」。

3. 承1，這兩個章節不同的是，前者在用人上的選擇較多，跨界求才、明快更替人力的作法是非常靈活果決的。這點在技術選擇上也是一樣的。而這並非指【智利礦場的領導課】中的災害搶救時間較多，其實正好相反：少浪費時間才是爭取時間的要訣！

4. 【智利礦場的領導課】中提供的專業分工/團隊劃分，是非常關鍵的作法。所謂在危難之中應該不分彼此的說法不總是正確，這篇文章中做了很好的詮釋。

5. 承續第4點，本書通篇大致上都認同一個觀點：「平時沒有合作的準備及演練，災難來時，誰都無法有效提供幫助」。而如何視災中的混亂變成可預測、能忍受的估算來對待，全靠平時的努力及投入。

6. 平時的努力，說來明顯易懂，其實也有大不易之處。見第四章【別讓虛驚成浩劫」便知。所謂「見微知漸」，這點是所謂經驗、所謂專業敏銳度可敬之處。書中還列舉了幾點做為 checklist，算是挺貼心的啦。這點和《快思慢想》中，防止系統一晃點系統二的作法是一致的。(連現任台北市長也強調這個)

7. 第三章的【救災有限公司】可視為一個獨立的章節來看：只要你希望你的組織和救災單位有掛上邊，就很值得一看。若讀者只是想知道：為什麼有些企業這麼好？會致力於救難支援的活動？有這個好奇心的人，也可以看看。

8. 總結：
    (1) 救災需要專業及熱情，光有同理心是不夠的。
    (2) 一頭熱只會造成困擾、加劇現場的混亂。
    (3) 殺頭的生意有人做，賠錢的生意沒人做。

言盲

您的工作團隊，有發生「言盲」現象嗎？

在《快思慢想》、《认知与设计 - 理解UI设计准则》…等相關著作中，都提到了人類大腦可以分成兩種系統。

在《快思慢想》的主要內容中，在於分辦兩種系統的差異及相互的干擾，並採取必要的方式盡可能掌握住兩系統切換時帶來的天生缺陷。

而在《认知与设计 - 理解UI设计准则》的內容中，則是引用兩系統之間的干擾告知UI設計者，何時應該利用或避過這些干擾。

兩系統的干擾之一在於：系統二啟動時，會使得系統一停工。

一個經典例子：「有一些受驗者，看一場兩隊分別身著黑色及白色球衣的籃球比賽，他們被要求去計數"白色球衣的隊員傳過幾次球"。在比賽過程中，有一位裝著黑熊玩偶裝的人，在場上來來回回走上了好幾次。而幾乎沒有受驗者留意到他。」

這是大腦中系統二阻斷系統一的功能的例子。系統二是相對懶很多的腦，運作系統二，人體要分泌腎上腺素、消耗體內的含氧量及被轉換出來的葡萄糖。這時人是費神、緊蹦的、專注的。因此而導致系統一的暫時失靈。

系統一比較原始、反應快、依靠直覺、視覺及經驗。也就是說，系統二在運作時，人的反應會變慢、肌肉變僵硬、經驗和直覺可能失準或自我懷疑。

一般來說，書上比較會強調別讓系統一在不知不覺為系統二代答了一切的答案。而筆者在這裡講的「言盲」指的是系統二阻斷系統一的現象。

語言和文字是人類後天發展出來的，對於它們的解析，是必須動到系統二的。如果語言中經常用到一些需要額外學習的字眼，或是文字的表達的不清楚，系統二就必須花費更大的力氣去解譯，據說這其中可能產生最長一秒以上的思緖暫斷，而一秒鐘就可能遺漏話語中的關鍵字或是被複數個思緖拉走人的專注力。

據網路傳言，人一天中平均會有5萬個想法。一天中若活動12小時，一秒中就會有超過一個想法，腦子愈快的人，在思緖暫斷的情形下，就會漏掉更多的想法。

文字還有另一個討厭的特色：不會100%精準，頂多足夠。這也是翻譯後的文學就不夠好、有時聽/看者有他意的原因。

在言談或解讀文字的過程中，喪失掉東西，筆者個人稱之為「言盲」。

筆者認為，討論時不該空談。空談指的是「只用講的」。討論尚且如此，何況是必須有產出的開會呢？(留意到討論和開會的不同了嗎？)

再專業一點地說，當我們在分析想法時，其實不應該夾雜具體字眼。在軟體開發領域上，具體來說，在思索需求時，其實是不該把 UI 的字眼夾帶進去的，因為那會侷限、干擾真正需求的產生。其他的技術字眼就更不用說了。

此外，能畫出來的就該畫出來，讓視覺啟動系統一，讓經驗和直覺派上用場；至少不用考驗到大腦短期記憶區的能耐 (古典來說，是指所謂的「7正負2)。

那畫不出來的呢？代表我們不夠了解，所以畫不出來；代表可能其實根本不需要，所以我們不會真的了解；代表可能根本做不到，所以畫不出來。只要畫不出來的，多半，都有問題。

所以大家真的要浪費一面牆或一面白板嗎？有看過時髦的軟體公司、神祕的特務電腦在玻璃上用類似立可白的白筆在畫什麼嗎？那個不是廣告或電影效果哩…，那是有必要的。

在團康一樣圍在一起的立會只適合確認15分鐘內能決定的事項；任何會議都該有記錄；記錄很簡單：在白板寫上問題、引導出答案，然後拿出炫炮的手機把結果照下來，然後把白板擦乾淨。如果大家的辦公室裡有一塊老是沒被擦乾淨的白板，就代表它沒被善用。

視覺化會啟動大家的右腦，能飛快地達成共識。利用一些簡易通用的符號更好，歧義會更少。這些都是語言、文字所不能及的、快速的、簡單的、有效率、有效能的小小方法 。


您的工作團隊，有發生「言盲」現象嗎？用鬼打牆幾次？忘記幾次？漏掉幾次？「有，其實有說」幾次？一個月的事情，要做幾個月？

閱讀《開放資料大商機》

《開放資料大商機 - 當大數據全部免費！創新、創業、投資、行銷關鍵新趨勢》(時報出版)的原書名為〈OPEN DATA NOW: The Secret to Hot Startups, Smart Investing, Savvy Marketing, and Fast Innovation〉。

本文不是書推，而是分享一下自己對於本書的想法及閱讀策略。

原書名有比較明顯的指示：開放資料！中文書名則顯得被動地多：假設大數據都準備好了、又不用錢時…。

找到這本書之前，我有兩個疑問：

1. Open Data 有哪些運用了？
2. 除了政府單位外，還有哪些來源？
3. 驅動這些資料出現的真實力量為何？(我對施政單位的考量沒興趣，但是我想知道非公營單位會怎麼想？)
4. Open Data 和我們的未來有什麼關係？

找到這本書後，看了「書名」，會覺得有點…差。

首先，Open Data 不等於 Big Data。原書名可沒有 Big Data 的影子。
其次，誰會這麼好心幫創業家、行銷單位準備好這些資料？

然後，我再聯想到：開不開放，誰來決定的？不危險嗎？

本書分為兩個部分：

Part 1: 開放資料的力量 - 這個部分講的是「案例運用」。
Part 2: 商業環境 - 這個命名還挺爛的，至少我看不太出來這個詞要講什麼。

閱讀之前，我抱著上列種種疑問，期待得到答案。對我來說，想得到的是一個能說得通的 circle 生態。相對來說，我對於「案例運用」興趣較少。原因是：這些是國外的案例，對台灣來說不一定適用，我們的腳步要怎麼踏？這一點不一定要和國外一樣；此外，當我在閱讀這些案例時，一定又有其他案例被產生出來。所以一開始我的閱讀策略就是打算從 Part 2 開始。

Part 2 沒讓我失望，把 Open Data 的供需關係點出來了(雖然目錄裡每個章節的名稱取得有點沒重點)。

這裡只引其中一小段，分享給大家：

「達克．席爾斯 (Doc Searls) 指出，由廠商主會的「顧客關係管理」(Custom Relationship Management，簡稱 CRM)盛行已久，但很快就會出現由消費者主導的「廠商關係管理」(Vendor Relationship Management，簡稱 VRM)。」

閱讀 Part 2時，會提到 Part 1的一些案例，若有興趣，也可以進行交叉閱讀。

最後，本書中文譯者的譯作我應該看過不少本。不過，單就這本來說，我還是覺得通順不足，無法掃讀，佔用了我比較多時間。

為什麼用 Git？

這是一個有點舊的話題。不過，要找一個簡潔的答案似乎不太容易，所以就自己小小記錄一下。

這裡只針對 Git 的分散式架構來說明。(也可以說是「點對點」)

1. 因為不是 CS 架構，所以就少了SPOP (Single Point of Failure)的風險。
2. 每次檔案的增加、修改都「可以選擇是不是要 add」，讓程式碼的控制多了很多彈性。以往被 add 進 SVN 的檔案就是會被管理，除非自 SVN remove 檔案，使之喪失被 SVN 控管的能力。但是在 Git，則不需如此：檔案依然被控管，只需在必要時加入 commit 的行列就可以了。
3. 隨時commit！不受 Server 的網域影響，也不會和原始碼所有共有者衝突。
4. 第3點非常利於TDD及重構。
5. 承第4點，也利於 Agile 的實現。

簡言之，Git 對於實行 Agile 的貢獻非常顯著。

Remote Work 的執行要點

這篇文章是整理自《Remote: Office Not Required》一書。嚴格講起來，我看的是此書的日文版《強いチームはオフィスを捨てる: 37シグナルズが考える「働き方革命」》。日文書名的翻譯大略為：厲害的團隊捨棄辦公室：37 Signals 所想的「工作術革命」。

日文的書名比英文原版的激進一點。若說「不需要辦公室」，可能代表「有也不錯」的弦外之音，甚至是「有當然更好」。不過，日文版的書名並非為了行銷炒作，讀了書的內文後，會發現內容真的是在強調沒辦公室的好處。日文版的書名，以這點來看，說不定反而更為傳神。

整理如下：

如果大家不在辦公室工作，壞處是什麼？

1. 溝通不易，甚至產生障礙。

2. 員工向心力不足。

誤解是什麼？

1. 可以節省固定成本。

解決方式是什麼？

1. 不論團隊有多分散，每天至少要有四小時的重疊工作時間。

2. 使用能輔助遠距工作的工具。這類的工具需要具備幾項功能：資訊公享(軟體團隊則另需要程式碼共有的機制）、共有透明的行事曆、工作記錄、任務分配、進度檢視、語音及影像即時傳遞。其中，影像的部分不是指看到對方的臉，而是要有一個像電子白板的介面讓彼此能針對議題進行討論。

3. 習慣後，和坐在同一間辦公室的感覺幾乎沒有差異。

4. 最好有一個線上頻道可以讓大家工作累了可以互相哈啦一下。(和知識管理領域裡提的「茶水間對話」是相通的)

5. 每個星期一次和團隊見面，即使只是交流一下最近的生活、興趣也可以。

6. 以上作法，若要實施，請至少認真地持續三個月，而非只抱著估且一試的心態。

最後，我們來看看 Remote Work 的好處：

1. 可以吸納各地良才，不在受地域及時域的限制。(不過若時域差距太大，其實是有影響的。)

2. 有一半以上是只有自己工作的時間，反而比較彈性、能保持專心。畢竟每個人的狀況不同，能依其狀況適度利用時間，遠比固定場所和時間的被盯哨來得好。

3. 減少不必要會議及討論發生的可能。很多經理人習慣以增加會議的方式來推行工作。但是加入會議的人或主席都不一定能真正在準備好的情形下進行會議。這種浪費幾乎是每位上班都要經歷的痛楚。雖然經理人和會議都是必要存在的，但是多了就有害。

3-2. 會議的前後都會破壞人的注意力。這個就是豐田的七種浪費中最常發生的「動作的浪費」。因為等一下要開會，所以什麼事不要現在做；因為剛開完成，剛才什麼事做到一半？原本是打算怎麼做的？要花時間回想。

4. 成果導向。比起是否準時上班？休息時間是否過長？為什麼看 Facebook？最重要的還是工作的成果。Remote Work 看的是貢獻、功勞，而不是苦勞或疲勞。

5. 降低 SPOP (Single Point of Failure) 的可能。公司停電或網路不通等狀況都可能對業務帶來影響。但是 Remote Work 則可以避免這種所有雞蛋被放在同個籃子裡的危險。

6. 減少經理人無故增加無益的工作量的可能。

我的結論：

其實遠距工作學問還挺多的。不過以工作效率的角度來說，我個人觀察，一般員工一天中完全燃燒的時段很有限，很多好想法、解法，也很常不是在辦公室想到的。有些人最有效能的時段是自己在家的時候，因為不會被人打擾。

工作環境是很有學問的。我個人也很常在辦公室腦子一片空白，尤其是對面一群沒表情的人、過於冷白的牆壁的時候。這還算好的，有些人的工作態度還會影響團隊士氣，而不是每個主管都會管這個的。

只要能結合工作目標和個人目標，方法是可變的，執行的結果還是看個人。習於被限制才能做出事情的人也在所多有，所以也不是每個人都合適 Remote Work。要 Remote Work 還得看個人強度…。要有讓一切都更好的覺悟才行。

一眼認識 HomeKit

整理了一下 HomeKit 的 static overview。

分享給大家。

【敏捷迭代式開發中的測試】第三篇：有哪些測試？

這篇文章只是摘錄 《 Software-Testing-And-Continuous-Quality-Improvement-Third-Edition》
Page 43 ~ 50 。


table 3.1 testing technique Categories

Technique	Manual	Automated	Static	Dynamic	Functional	Structural
Acceptance testing	x	x		x	x
Ad hoc testing	x				x
Alpha testing	x			x	x
Basis path testing		x		x		x
Beta testing	x			x	x
Black-box testing		x		x	x
Bottom-up testing		x		x		x
Boundary value testing		x		x	x
Branch coverage testing		x		x		x
Branch/condition coverage		x		x		x
Cause–effect graphing		x		x	x
Comparison testing	x	x		x	x	x
Compatibility testing	x	x				x
Condition coverage testing		x		x		x
CRUD (create, read, update, and delete) testing		x		x	x
Database testing		x		x		x
Decision tables		x		x	x
Desk checking	x			x		x
End-to-end testing	x	x			x
Equivalence partitioning		x		x
Exception testing		x		x	x
Exploratory testing	x			x	x
Free-form testing		x		x	x
Gray-box testing		x		x	x	x
Histograms	x				x
Incremental integration testing	x	x		x	x
Inspections	x		x		x	x
Integration testing	x	x		x	x
JADs (joint application designs)	x				x	x
Load testing	x	x		x		x
Mutation testing	x	x		x	x

© 2009 by Taylor & Francis Group, LLC

Continued

44 ◾ Software Testing and Continuous Quality Improvement table 3.1 testing technique Categories (Continued)

Technique	Manual	Automated	Static	Dynamic	Functional	Structural
Orthogonal array testing	x		x		x
Pareto analysis	x				x
Performance testing	x	x		x	x	x
Positive and negative testing		x		x	x
Prior defect history testing	x		x		x
Prototyping		x		x	x
Random testing		x		x	x
Range testing		x		x	x
Recovery testing	x	x		x		x
Regression testing				x	x
Risk-based testing	x		x		x
Run charts	x		x		x
Sandwich testing		x		x		x
Sanity testing	x	x		x	x
Security testing	x	x				x
State transition testing		x		x	x
Statement coverage testing		x		x		x
Statistical profile testing	x		x		x
Stress testing	x	x		x
Structured walkthroughs	x			x	x	x
Syntax testing		x	x	x	x
System testing	x	x		x	x
Table testing		x		x		x
Thread testing		x		x		x
Top-down testing		x		x	x	x
Unit testing	x	x	x			x
Usability testing	x	x		x	x
User acceptance testing	x	x		x	x
White-box testing		x		x		x

© 2009 by Taylor & Francis Group, LLC

Overview of Testing Techniques ◾ 45 table 3.2 testing technique descriptions

Technique	Brief Description
Acceptance testing	Final testing based on the end-user/customer specifications, or based on use by end users/ customers over a defined period of time
Ad hoc testing	Similar to exploratory testing, but often taken to mean that the testers have significant understanding of the software before testing it
Alpha testing	Testing of an application when development is nearing completion; minor design changes may still be made as a result of such testing. Typically done by end users or others, not by programmers or testers
Basis path testing	Identifying tests based on flow and paths of a program or system
Beta testing	Testing when development and testing are essentially completed and final bugs and problems need to be found before final release. Typically done by end users or others, not by programmers or testers
Black-box testing	Testing cases generated based on the system’s functionality
Bottom-up testing	Integrating modules or programs starting from the bottom
Boundary value testing	Testing cases generated from boundary values of equivalence classes
Branch coverage testing	Verifying that each branch has true and false outcomes at least once
Branch/condition coverage testing	Verifying that each condition in a decision takes on all possible outcomes at least once
Cause–effect graphing	Mapping multiple simultaneous inputs that may affect others, to identify their conditions to test
Comparison testing	Comparing software weaknesses and strengths to competing products

© 2009 by Taylor & Francis Group, LLC

Continued

46 ◾ Software Testing and Continuous Quality Improvement table 3.2 testing technique descriptions (Continued)

Technique	Brief Description
Compatibility testing	Testing how well software performs in a particular hardware/software/operating system/network environment
Condition coverage testing	Verifying that each condition in a decision takes on all possible outcomes at least once
CRUD testing	Building a CRUD matrix and testing all object creations, reads, updates, and deletions
Database testing	Checking the integrity of database field values
Decision tables	Table showing the decision criteria and the respective actions
Desk checking	Developer reviews code for accuracy
End-to-end testing	Similar to system testing; the “macro” end of the test scale; involves testing of a complete application environment in a situation that mimics real-world use, such as interacting with a database, using network communications, or interacting with other hardware, applications, or systems if appropriate
Equivalence partitioning	Each input condition is partitioned into two or more groups. Test cases are generated from representative valid and invalid classes
Exception testing	Identifying error messages and exception- handling processes and conditions that trigger them
Exploratory testing	Often taken to mean a creative, informal software test that is not based on formal test plans or test cases; testers may be learning the software as they test it
Free-form testing	Ad hoc or brainstorming using intuition to define test cases
Gray-box testing	A combination of black-box and white-box testing to take advantage of both
Histograms	A graphical representation of measured values organized according to the frequency of occurrence; used to pinpoint hot spots

© 2009 by Taylor & Francis Group, LLC

Overview of Testing Techniques ◾ 47 table 3.2 testing technique descriptions (Continued)

Technique	Brief Description
Incremental integration testing	Continuous testing of an application as new functionality is added; requires that various aspects of an application’s functionality be independent enough to work separately before all parts of the program are completed, or that test drivers be developed as needed; done by programmers or by testers
Inspections	Formal peer review that uses checklists, entry criteria, and exit criteria
Integration testing	Testing of combined parts of an application to determine if they function together correctly. The “parts” can be code modules, individual applications, or client/server applications on a network. This type of testing is especially relevant to client/server and distributed systems
JADs	Technique that brings users and developers together to jointly design systems in facilitated sessions
Load testing	Testing an application under heavy loads, such as testing of a Web site under a range of loads to determine at what point the system’s response time degrades or fails
Mutation testing	A method for determining if a set of test data or test cases is useful, by deliberately introducing various code changes (“bugs”) and retesting with the original test data/cases to determine if the bugs are detected. Proper implementation requires large computational resources
Orthogonal array testing	Mathematical technique to determine which variations of parameters need to be tested
Pareto analysis	Analyze defect patterns to identify causes and sources
Performance testing	Term often used interchangeably with stress and load testing. Ideally, performance testing (and any other type of testing) is defined in requirements documentation or QA or Test Plans

© 2009 by Taylor & Francis Group, LLC

Continued

48 ◾ Software Testing and Continuous Quality Improvement table 3.2 testing technique descriptions (Continued)

Technique	Brief Description
Positive and negative testing	Testing the positive and negative values for all inputs
Prior defect history testing	Test cases are created or rerun for every defect found in prior tests of the system
Prototyping	General approach to gather data from users by building and demonstrating to them some part of a potential application
Random testing	Technique involving random selection from a specific set of input values where any value is as likely as any other
Range testing	For each input, identifies the range over which the system behavior should be the same
Recovery testing	Testing how well a system recovers from crashes, hardware failures, or other catastrophic problems
Regression testing	Testing a system in light of changes made during a development spiral, debugging, maintenance, or the development of a new release
Risk-based testing	Measures the degree of business risk in a system to improve testing
Run charts	A graphical representation of how a quality characteristic varies with time
Sandwich testing	Integrating modules or programs from the top and bottom simultaneously
Sanity testing	Typically, an initial testing effort to determine if a new software version is performing well enough to accept it for a major testing effort. For example, if the new software is crashing systems every five minutes, bogging down systems to a crawl, or destroying databases, the software may not be in a “sane” enough condition to warrant further testing in its current state
Security testing	Testing how well the system protects against unauthorized internal or external access, willful damage, etc.; may require sophisticated testing techniques

© 2009 by Taylor & Francis Group, LLC

Overview of Testing Techniques ◾ 49 table 3.2 testing technique descriptions (Continued)

Technique	Brief Description
State transition testing	Technique in which the states of a system are first identified, and then test cases written to test the triggers causing a transition from one state to another
Statement coverage testing	Every statement in a program is executed at least once
Statistical profile testing	Statistical techniques are used to develop a usage profile of the system that helps define transaction paths, conditions, functions, and data tables
Stress testing	Term often used interchangeably with load and performance testing. Also used to describe such tests as system functional testing while under unusually heavy loads, heavy repetition of certain actions or inputs, input of large numerical values, or large complex queries to a database system
Structured walkthroughs	A technique for conducting a meeting at which project participants examine a work product for errors
Syntax testing	Data-driven technique to test combinations of input syntax
System testing	Black-box type testing that is based on overall requirements specifications; covers all combined parts of a system
Table testing	Testing access, security, and data integrity of table entries
Thread testing	Combining individual units into threads of functionality that together accomplish a function or set of functions
Top-down testing	Integrating modules or programs starting from the top

© 2009 by Taylor & Francis Group, LLC

Continued

50 ◾ Software Testing and Continuous Quality Improvement table 3.2 testing technique descriptions (Continued)

Technique	Brief Description
Unit testing	The most “micro” scale of testing; to test particular functions or code modules. Typically done by the programmer and not by testers, as it requires detailed knowledge of the internal program design and code. Not always easily done unless the application has a well-designed architecture with tight code; may require developing test driver modules or test harnesses
Usability testing	Testing for “user-friendliness.” Clearly, this is subjective, and will depend on the targeted end user or customer. User interviews, surveys, video recording of user sessions, and other techniques can be used. Programmers and testers are usually not appropriate as usability testers
User acceptance testing	Determining if software is satisfactory to an end user or customer
White-box testing	Test cases are defined by examining the logic paths of a system