Search code examples
bddacceptance-testinguser-stories

Must an actor of a user story be a human being?


User stories are traditionally written as expression "As a [User Type] I want [feature] so that [some benefit]". In the books and online resources [User Type] typically correspond to a role of a human being. However, when describing features of system internals, it is often easier to put some unattended service in place of a user, e.g. "As a ServiceX I want some data to be regularly refreshed to that I can do XYZ using most recent information".

Such form makes it straightforward to write easy-to-understand acceptance tests for related parts of the system. But is this conceptually right? Shouldn't user stories be based on features giving business value, and since systems and services are not interested in gaining business values, they should not be actors of user stories?


Solution

  • Systems most certainly are interested in gaining business value. An actor could be an automated agent written by a third-party, and which embodies that third-party's intent. In fact, this is becoming a dominant form of interaction as web services become a more popular feature of major web sites, thus allowing complex inter-site interactions on behalf of users but involving only machines.