當我有不同人物角色相似的小黃瓜情景時，我該如何避免重複自己？

Question

我正在編寫小黃瓜場景，並遇到一個問題，用戶故事適用於我們正在設計的系統中的多個角色，具有細微的差異。

基於我讀過，首選的方法是從這個角度寫功能的文件：

作爲一個[角色/人物]

我希望[功能]

使[效益]

問題在於，我最終會爲每個角色寫出或多或少的相同場景，這將最終導致大量重複。

舉一個具體的例子，在招聘申請中，不同的角色需要能夠查看在公司註冊的申請人實體。唯一的區別是，根據您擁有哪些特權級別（即您的角色），即執行級別，區域經理，區域經理，分部經理，分支員工，外部客戶，需要對集合應用某種過濾的申請人可以查看。

解決這一問題的一種方法是定向圍繞實體（申請人）的特性/用戶故事而不是假面即

特徵

作爲應用程序的用戶（NB 。而不是提指定的Persona，我們指的是一個「通用」用戶角色）

我希望能夠查看申請人

，以至於當我請求查看申請人

那麼我可以查看我允許基於我的許可申請，我可以履行我的工作職責

方案

這種情況簡潔地捕捉用戶故事。但是，我想測試不同的使用情況，即分行經理只能查看分配到其分行的申請人，地區經理只能查看分配到其地區的申請人，客戶只能查看申請人在其公司的工作分配。

什麼是最好的方式去做這件事，你認爲圍繞實體而不是角色編寫用戶故事的方法是可以接受的嗎？

Answer 1

我不會擔心重複，更關注清晰度。

如果利益相關者看到區域經理被允許查看某些內容並允許外部客戶查看關於同一應用程序的其他某些內容，那麼我會在Gherkin中表示這一點很重要。

我確定這些規則不會經常更改，因爲它們可能位於域的核心。這意味着你不會經常更換它們。如果你需要改變它們，你的利益相關者必須很容易理解這一點。

如果您發現存在許多差異很小的變體，請考慮場景大綱以捕獲所有不同的版本。這可能會導致減少重複，同時仍然清楚瞭解這些差異。

如果這些更改具有更多的技術性質，並且您的利益相關者不關心，那麼請使用單元測試來捕獲實現，而不是使用小黃瓜。

但是在這種情況下，重點不在於重複，更多的是創建一個易於溝通的共同理解。

請記住，小黃瓜是一種溝通工具，而不是一種編程工具。作爲通信語言，其他規則適用於編程語言。

Answer 2

「作爲[角色]」不是關於誰是該功能的用戶，而是誰需要該功能。大多數情況下，這是一些需要功能的利益相關者，以便公司能夠受益並做更好的業務。

就你而言，這是關於查看申請人。不同的訪問應該在同一個特性文件中用更多的場景來描述。但是，您的所有訪問角色對於解釋此功能並非至關重要。儘管Gherkin背後的工具可以測試，但Gherkin的功能和場景更多的是捕捉它們背後的想法，而不是涵蓋所有可能的場景。選擇1-2個最重要的訪問角色，其餘的選擇降低測試級別，主要是單元測試。

試着記住測試金字塔，其中驗收測試只有所有測試的一小部分。