Tirgul 2 summary

We have discussed acceptance tests, their difference from unit tests, and outlined their definition using hidden assumptions discovery.

Hidden assumptions are discovered by answering the following questions from customer, user, developer, and tester points of view.
  • Customer
    • What business problem are we trying to solve?
    • How do the user stories solve it?
    • How can the user stories be implemented and not solve the problem
    • What alternative problems and solutions exist?
  • User
    • What is the best/worst thing that can happen?
    • What will really irritate the user?
    • How can the user fail, and how would we want the system to response?
    • How frequent will be the user's interaction with the system?
  • Developer
    • What is the simplest and easiest way to implement the user stories?
  • Tester
    • How likely is it that the simplest implementation:
      • Will solve the customer's business problem?
      • Will solve similar relevant problems?
      • Will be the best solution?
    • The answer is virtually always not very likely – what additional information is necessary to make the answer likely?
    • The tester identifies hidden assumptions between customer and user, and between developer and user, which lead to hidden assumptions.

When considering the example, we arrived to the following short summary.

The business problem the customer is trying to solve is extension of his business to the Internet, allowing users (customers from his point of view) to perform the same tasks as clients can perform in his store. A real possibility for implementing the user stories and not solving the business problem is to make an unusable site for the store. Alternative problems / solutions would be e.g, ability of users to check out / buy songs and albums using cellular phones.

The best thing that can happen to the user is quite clear. The worst / irritating thing – for instance, going with the process until the credit card is rejected, and the data is not saved. The user can get 1000 results for simple query, or no results due to a misspelling. The user can fail by entering some data in unsupported locale. The system should never go down, providing clear error messages. Users won't buy frequently, but we can expect some meaningful number of teenagers listening to song samples at any given time.

The developer seeks an easy life, so the simplest and easiest way to implement the solution will be some sort of PHP/MySQL combo with a single table without indexes, search results dumped in a single HTML page, etc (payment handled by someone else, over phone, I can go on and on).

The acceptance tester considers all these answers, and arrives to hidden assumptions, a subset of which is:
  • All tasks performable in brick and mortar store should be available on the site: listening to excerpts, etc.
  • Site usability is of utmost importance (unlike, for example, corporate intranet sites)
  • A mobile version should be available, and accept pay-with-call payment
  • All entered data must be saved along the way
  • Search results should be separated into multiple pages, and search refinement ability should exist (doesn't matter how implemented – keep previous text in the search box, or special search in results)
  • System should support international locales
  • Search should be fuzzy (allow misspellings)
  • Search should be fast (this implies appropriate database indexes, or caching)
  • A watchdog monitor should provide soft / hard resets to database / server when necessary
  • A content distribution / load balancing framework should be employed (e.g., Akamai) – for rigid data like song snippets
  • An industrial-strength billing system should be used, accepting all major credit cards, PayPal, etc.

Implementing acceptance tests without dependence on ready project is described in class slides, I don't think specific architectural details are important.