What Structure Does a Test Have?

I was an audience in webinar from Manju Maheswar on Heuristics.  This webinar led me to discussion with Klára Jánová on how the heuristic will help in having structure for problem solving.  Here are my tweets as my discussion.

There is a question from Klára Jánová -- "Thanks! What structure does a test have?"  In my opinion this question goes down to fundamental and philosophical level of Testing.  When spoken in casual, the outcome of a test is seen in binary that is pass or fail.  Is that right or not so right, that's altogether a different topic of discussion.  I will not get into it.  But that binary is associated as result to a test and it has an experience attached to it.  That "experience" attached to the test is an "essence of test" which I would like to bring here in this post.  In simple, if a bug is an experience that I encountered in using the product, then test is an experiment to know what is that experience.  The test exposes a tester or anyone to an experience with information, as an outcome.  How we act upon this experience and information on witnessing it, is what tells the further story.

What we feel out of an experience is the shape or structure we give to it.  That said, the test has a structure to it as an experience. This experience will let us to respond further rationally in a structured and organized way to learn further by debugging.

Apart from the said above, there are much more elements that adds structure to the thought of a test identified. The picture shared below will give the gist of elements which fine tunes a test to be precise, deterministic, practical and an experiment with a question.

Above all these, a test is a heuristic.  That means, an experience is as well a heuristic.  So, the software is a heuristic having sets of experiences to its users.  The software has a structure in multiple forms.  The functions (methods), classes, packages (modules) and the data structures used gives the structure internally to a software.  How the product is built and interfaced gives the external structure.

Now, if I happen to talk in this philosophical tone may be not all take it seriously, is what I believe.  I can understand it and nothing wrong in it.  That’s an experience too!   I will have to communicate and talk how the team with which I work communicates, you see that’s a context.  Usually the interests will be in -- binary that is pass or fail; the artifacts which is by-product of testing activity (test cases, bug reports, etc.); the tools and more.  I will have to work in that mode in those contexts.  A function (method) and class written will have yield to an experience from what it does.  Yet I hope there will someone in programmer, manager and in software engineering, can relate to experience part of a test.  When I talk to testing practitioners who speaks the language as this, I talk to them as this.  That's the context of people and practices, again.

Okay, how's the experiences are structuring for you from the encounters with the tests you executed and from the code you wrote?