產(chǎn)品經(jīng)理可用性測試計劃

產(chǎn)品經(jīng)理可用性測試計劃測試計劃是整體可用性測試的基石。計劃要說明測試方法、時間、地點、誰推動測試、為什么測試和測試內(nèi)容。但是，有時在項目期限臨近的巨大壓力下，可能不會制定詳細的測試計劃。最后，你認為你已經(jīng)知道了即將進行的測試，你不必再花時間寫它了。但是，這樣不規(guī)范的方法顯然是錯誤的，最終不可避免地會引起問題。為什么要制定測試計劃？合理的方法是：一旦知道測試將要進行的那一刻，就要準備測試計劃。（約翰f肯尼迪，測試名言）此后，隨著項目的進展，不斷改進計劃，收集反饋等往返。當然，靈活性也是有限的。測試前必須設置特定的時間節(jié)點。此后，計劃要保持不變。同時測試的產(chǎn)品在這個時間節(jié)點后，在測試結束之前不能再更改。您可能已經(jīng)知道測試計劃是產(chǎn)品開發(fā)周期中唯一具有明確時間點的文檔，因此特別重要。當期限臨近時，你要盡力不要更換要試驗的設計產(chǎn)品。進一步的更改可能會使以前開發(fā)的測試方案不再可靠。例如，需要研究的問題，甚至數(shù)據(jù)收集方法的可靠性也會受到影響。如果需要在預定時間點后更改測試，則測試可能無效，并且在測試前更改的產(chǎn)品可能無法正常工作的風險必須讓所有人都理解。以下說明了需要制定詳細計劃的原因，以及開發(fā)團隊如何使用計劃作為溝通工具。作為測試的規(guī)劃指南。正如設計圖準確地描繪了要建造的房子一樣，測試計劃也準確地說明了如何測試你的產(chǎn)品。建筑承包商在蓋房子時不會希望按計劃即興發(fā)揮，可用性測試也遵循這個邏輯。測試計劃保證一切妥當。在測試第一名時，你肯定不希望測試中還存在不明確的事項。作為主要的溝通工具，測試計劃是設計師、開發(fā)人員、測試主持人和團隊其他成員的主要溝通工具。開發(fā)團隊和管理團隊（如果有興趣并且在團隊中）的官員應該仔細閱讀測試計劃的文檔報告。也就是說，您需要了解測試是如何進行的，并確認是否滿足了具體要求。你可以利用計劃從其他成員那里得到建議和反饋，使每個人都能同意即將進行的實戰(zhàn)測試。正在進行的項目每天每周都會更改，測試結束后，我不想有人質(zhì)疑他或她的一些要求沒有出現(xiàn)在測試中。此外，如果這是組織的第一次測試，那么測試結果相關人員必須審查測試計劃。這也保證了計劃的商業(yè)性和政治性。計劃指明或暗示必要的資源測試計劃說明或暗示測試所需的內(nèi)部和外部資源。準確地列出什么時候會發(fā)生的事情，預測測試所需資源的工作就變得更加明確和容易了。無論直接還是間接暗示，測試計劃都包含成功測試所需的資源。計劃是測試和實際階段的連接點沒有測試計劃，細節(jié)可能會模糊。尤其是在截止時間的壓力下。測試計劃將你的測試方法系統(tǒng)化，迫使開發(fā)團隊提醒即將到來的最后期限。說了這么多，這是完全可以接受的，發(fā)生的可能性很大。當你對測試目標有更多的了解，并與參與測試的考試進行更多的溝通時，測試計劃也會在這個階段逐步優(yōu)化。項目是動態(tài)的，測試真正開始后，看起來最完美的計劃也要更改。通過優(yōu)化測試計劃，你可以適應過程中遇到的變量。例如，當時間和資源的限制越來越明確時，你可能會變得不那么雄心勃勃，但你可能想敷衍了事。或者說，也許你沒有按照自己的設想找到足夠的合格參與者。文件中的所有模塊或章節(jié)的要求可能不是及時準備好的。也許你的測試目標太不準確，需要簡化和集中。這些都是現(xiàn)實世界的例子，他們強迫你修改測試過程和測試計劃。附注：制定計劃時，請始終記住最終用戶。隨著項目的進展，很可能會忘記測試具有特定特征的用戶和產(chǎn)品的關系，而不是產(chǎn)品本身。測試計劃的組成部分如果測試類型不同，或者組織對測試規(guī)格的要求不同，則測試計劃的格式也不同。但是，通常包含以下九個部分，下文將詳細介紹。測試目的、目標和對象研究問題受試者的特征方法（測試設計）核對表準備測試環(huán)境、設備和后勤主持人在測試中的作用收集的數(shù)據(jù)和評估方法報告內(nèi)容和演示文稿其中，測試主持人的作用很大，因此將從第4章詳細討論為獨立章節(jié)。剩下的部分將在本章中討論。檢查測試目的和目標文檔的這一部分說明了執(zhí)行此測試的原因。不是讓你說出測試調(diào)查的具體目標或問題。相反，你的焦點或出發(fā)點應該是站在組織的角度，關注重點問題。例如：測試是為了解決公司呼叫中心或技術支持部門以前上報的問題而設計的嗎？根據(jù)服務器日志或網(wǎng)站使用數(shù)據(jù)，公司網(wǎng)站的訪問者在過程中從一個節(jié)點辭職，無法完成業(yè)務嗎？公司最近發(fā)布了要求在上市前測試所有產(chǎn)品的新規(guī)格嗎？管理者知道開發(fā)團隊在這個時候了解真實用戶很重要嗎？測試目的上升到較高的高度是恰當?shù)摹Ｒ驗楹罄m(xù)研究問題及說明部分可以將大目標具體化為可衡量的水平。測試與組織的業(yè)務目標密切相關。這樣，測試才能成為解決問題和探索機會的最佳工具。什么時候不做測試以下是產(chǎn)品必須進行可用性測試的非常模糊和不恰當?shù)脑颉＿@些原因可能很少書面化，通常是口頭交流。但是，下一個測試理由不合理，最終會影響整個項目?？梢蕴岣哂脩趔w驗（只能測試產(chǎn)品部分的用戶體驗，而不是產(chǎn)品和用戶之間的所有接觸點）。其他人都在做可用性測試程序。用作可用性測試的會議室本月第三周都很空閑（會議室每天晚上都空著）。Lou老師剛剛參加了新的計算機協(xié)會人機交互特別興趣小組ACMSIGCHI會議，學習了這種有用的測試技術。（Lou老師首先讓公司高層推薦這項有用的技術。）我想確認一下該類型產(chǎn)品是否有市長/市場需求。（這個邏輯顯然是相反的。焦點組和問卷是產(chǎn)品早期階段更合適的方法。）你可以說服自己。特別是當你非常緊急地進行可用性測試時，“我只是想做測試，我不在乎原因。我們可以稍后再考慮測試結果。”“短期內(nèi)，前面的任何理由都可以開始測試。但是，從長遠來看，如果測試是產(chǎn)品開發(fā)不可或缺的一部分，那么就必須將測試與產(chǎn)品要求和組織的總體業(yè)務要求相結合。否則，在測試被認為是短期流行的新技術時會遇到困難。進行測試的最佳理由以下列表說明了合理的測試理由，有助于產(chǎn)生有效的結果，并為以后的測試奠定基礎。我想確認兩個主要用戶都能很好地使用產(chǎn)品。我想知道提供文檔是否能解決界面中的常見問題。我收到了很多關于使用產(chǎn)品的投訴。我想確認這些不滿的本質(zhì)和今年的開發(fā)預算如何解決這些問題。通信研究問題本章是測試計劃中最重要的部分，介紹了需要解決的問題和研究重點，以及與測試計劃、設計和操作相關的部分。研究問題應盡可能準確、準確、明確、可測量。即使是在產(chǎn)品開發(fā)初期進行的導航測試——非結構化測試，也必須準確地說明想要的內(nèi)容。如果沒有明確簡明的研究目標，就會發(fā)現(xiàn)自己處于不利的情況，進行的測試無法回答項目組成員關心的核心問題。或者你會發(fā)現(xiàn)，測試總是處于無休止的爭論中，因為“被測試的東西”這一根本問題尚未達成一致。從我自己的經(jīng)驗來看，我們正在推進準備工作，但測試本身的爭議不斷，這也是測試目的沒有書面報告的原因。下面兩個例子的研究問題太模糊，不明確。例1:現(xiàn)在的產(chǎn)品有用嗎？例2:我能推出這個產(chǎn)品嗎，還是需要更多的工作？研究的困難不是這些問題沒有意義。相反，這些問題不完整、模糊，沒有說明或暗示如何衡量或量化結果。根據(jù)這些解釋進行的測試最終會導致結果偏差。為什么相關人員對要解決的問題都不能達成一致，你怎么能確認已經(jīng)找到了解決問題的方法呢？當然，在這種情況下，通常連研究問題都找不到。下表列出了各種不同產(chǎn)品的研究問題，這些情況的研究問題是適當?shù)?，重點明確的。研究問題是在與開發(fā)團隊或開發(fā)人員、技術人員、市場人的討論中形成的。如果不需要總結測試目標，只提出大致的問題或目標，也不需要沮喪，這將是：他們還沒有準備好考試。需要更好地理解測試目標、目的和過程。他們需要幫助將目標轉(zhuǎn)化為具體的可測量和可觀察的研究問題。不要猶豫，是時候介入或提供幫助了。如果難以設計測試方案和/或適當?shù)闹笜?，無法確定適當?shù)淖罱K用戶，甚至無法確定數(shù)據(jù)收集的形式，則可以再次回到研究問題本身，確定是否需要明確。描述受試者的特征測試計劃的這一部分描述了測試產(chǎn)品的最終用戶特征。與組織中的其他成員合作以確定目標用戶的特征非常重要。有關如何創(chuàng)建用戶簡介和招募受試者的具體步驟，請參閱第7章。圖5-3以在線酒店預訂網(wǎng)站可用性測試的受試者特征為例。在描述受試者特征時，首先要記住招募適當數(shù)量的受試者。在談到參與測試的受試者人數(shù)時，最重要的原則是“不能有太多受試者”?？紤]到結果統(tǒng)計上的有效性，小樣本量缺乏統(tǒng)計效力，無法驗證組之間的差異顯著。在實際實驗設計中，每個條件至少要有10~12人接受考試。但是研究結果表明，在非正式可用性測試的情況下，有4~5名代表性用戶就足夠了。代表目標群體的該集團的受試者將發(fā)現(xiàn)產(chǎn)品80%的可用性問題，這80%是產(chǎn)品的主要問題。當然，如果有時用資源來測試4~5名以上的受試者，你會發(fā)現(xiàn)其他20%產(chǎn)品的重要問題。我們參與的許多測試也證明了上述原則。在一項測試中，Jeff測試了8名受試者，其中80%的問題在前四名測試中已經(jīng)被發(fā)現(xiàn)。但是，第八名的受試者和最后一名受試者在某項任務中出現(xiàn)了嚴重錯誤，不得不尋求對產(chǎn)品的電話支持。如果只有四個人受到考驗，我們永遠也發(fā)現(xiàn)不了這個嚴重的問題。如果你的測試經(jīng)驗還不豐富，招募盡可能多的受試者不僅可以降低遺漏重要問題的可能性，還可以提供鍛煉你測試技術的額外機會。如果沒有時間和預算，可以嘗試“打折”可用性測試。這意味著，在開發(fā)周期中，您可能希望進行幾次小型、重復的可用性測試。在一次測試中，招募了4-5名目標用戶，進行了1-2套工作條件，并將結果應用于界面設計。然后進行另一個規(guī)模和任務相似的測試。經(jīng)過3-4次測試后，你已經(jīng)有了較大的樣本量，開發(fā)團隊也能發(fā)現(xiàn)不同測試之間的變化。測試方法說明測試計劃的這一部分詳細說明了如何調(diào)查受試者以及如何進行測試。本質(zhì)上，測試方法是測試設計的概述。也就是說，為了使測試觀察者大致了解內(nèi)容，我們提供了對正在測試的整個測試過程中的每個節(jié)點的詳細說明。為什么測試計劃要包含這么多細節(jié)？下面列出的理由可以解除你的疑惑。幫助他人理解和可視化測試過程，以便他人提出意見或建議。從考試執(zhí)行者的角度來看，有助于關注考試到達前需要準備的資料和事項。提醒你，測試計劃必須與其他資源方協(xié)調(diào)。例如，前臺在接受考試時不會忘記問候。允許多個測試主持人（如果測試計劃需要）按照類似的流程和規(guī)格進行測試。設計測試對可用性專家來說是必不可少的和專業(yè)的技能，通常包括實驗設計和方法以及基本的統(tǒng)計分析知識。要設計可用性測試，首先要清楚地理解測試目標，并根據(jù)提出的測試問題設計解決問題的最有效的測試計劃。如果測試設計有缺陷，或者在執(zhí)行測試時沒有嚴格的實驗控制，結果將是不可靠的。這不僅會導致錯誤的提案，更糟的是，會直接損害組織的可用性工程建設。因此，在進行可用性測試之前，請有經(jīng)驗的同事審查測試計劃，聽取建議和反饋至關重要。測試設計主要基于兩種類型的測試對象3354產(chǎn)品本身和產(chǎn)品用戶?，F(xiàn)有資源、障礙、甚至創(chuàng)造力都會對設計成果產(chǎn)生重大影響。時間、金錢、管理和開發(fā)團隊的支持、考試招募能力和其他實際問題可能成為限制因素。以下是您可能遇到的一些典型案例的測試設計案例。此外，我們還提出了保證試驗嚴格的指導原則。最簡單的測試設計：測試屬于同一類型（如老年人）的多個用戶，要求他們完成站點不同部分的代表性任務。獨立組間設計或受試者間設計顧名思義，獨立組間設計意味著站點的各個部分將由不同的用戶進行測試。如下表所示，組間設計需要15名受試者，每個受試者只完成一個任務。這有助于消除工作優(yōu)先級帶來的潛在學習遷移效果。用戶完成作業(yè)A可能有助于成功完成作業(yè)B,因此很難確定與作業(yè)B相關的可用性問題。另外，如果所有任務都很長，受試者可能累了，你也要使用這種設計。受試者設計測試15名受試者可能很難實現(xiàn)。現(xiàn)實是，你只能考5個人，只好讓他們每個人完成所有3個模塊。（阿爾伯特愛因斯坦）這就是試驗內(nèi)的設計。但是，必須考慮學習的遷移效果。你可以使用平衡抵消技術消除學習效果。為了平衡，必須更改操作順序，如下圖所示。每次考試完成任務的順序不同。工作順序隨機化削弱了遷移效果，在上述情況下，至少嘗試4個人就足夠了。但是，隨機化順序會引起其他問題。在日常生活中，很多流程本身是有順序的（例如，注冊后可以支付）。因此，雖然必須讓用戶按正常順序完成任務，但這可能會掩蓋后續(xù)任務的可用性問題（在測試過程中，可以衡量是否有學習效果）?；蛘呤翘峁╇S機順序的任務（通常在實驗室），被試者會被迷惑和陌生嗎？大多數(shù)人同意你應該保持合理的任務順序。如果你決定這樣做，你要盡可能注意遷移效果。你可以在執(zhí)行正式任務之前讓受試者提前訓練，使受試者之間的使用經(jīng)驗達到相同的水平。另外，各部分進行完畢后，接受考試后，要每隔一段時間休息一次。測量多個產(chǎn)品版本現(xiàn)在，讓我們來看看另一個一般情況。例如，想比較一個產(chǎn)品的兩個版本，版本A和版本B,以確定最終設計中哪個版本更好。同時，你想比較兩種用戶組，主管和技術人員，使用產(chǎn)品的差異。這相當于22矩陣設計。如果采用獨立組間設計，測試計劃是表中的數(shù)量單元格指向不同的受試者。該設計需要16名受試者，并分配給4個條件：4名管理人員使用版本A,4名技術人員使用版本A。如果你只測試8個人，那么每個條件的單元格只嘗試2個人，因此，如果每個類別的數(shù)據(jù)太少，測試結果可能沒有意義。（BernardShow,SLATLET）但是，兩組考試、管理人員和技術人員可以操作這兩個版本，使用一個版本，然后使用另一個版本。和前面的例子一樣,后測試版本可能有優(yōu)點,你可以從第一個版本的測試中學習一些工作。然而,另一方面,這種效果可以反轉(zhuǎn)。試圖在第一個版本中形成某種習