CopenhagenContext 2015

Specifications (requirements documents, user stories, functional design specs, etc.) play an important role in software projects. But that role is often misunderstood. The common myth is that a specification is written before the intended product is created, and that it is a complete and authoritative description of that product. In fact, this is almost never true. A tester can spend his entire career without seeing such a thing.

The reality is that almost all specifications are written by distracted, bored engineers- not professional communicators- who are trying to communicate things that haven't been fully thought through or agreed upon by all stakeholders. Specifications are often little more than rough sketches.

The tester stands between the product and it's spec. The tester must come to understand the spec (he does this by any means necessary, including testing the product) while simultaneously coming to understand the intent of the spec and the actual behavior of the product. What testers discover may cause changes to spe'c or the product or both at once.

James and Pradeep will take the participants through a journey of hands on exploratory testing of an application which has a simple specification. The goal will be to experience how testing is not only a process of examining a product, but also critically analyzing (and potentially rewriting) it's specification.