Posts in category: Learnings & Experiences

Language is not just for writing, it plays a significant part in our thinking process. It has been discussed widely as how “Language shapes the way we think” (Read and listen to one of these at http://blog.ted.com/2013/02/19/5-examples-of-how-the-languages-we-speak-can-affect-the-way-we-think/ for an interesting TED talk blog & talk).
Once we are comfortable with a language, we “think” in that language. For example, we form sentences in the mind to understand, form narratives to describe, think in terms of if-then to discern logic, create command sequences to create actions and so on.
Language is made of the syntax ’the rules’ and the content ‘the semantics’. The syntax i.e rules shapes the way and the depth of understanding of the content.
Language allows us to:

1. Describe a story “Understand
2. Breakdown the problem “Simplify”
3. Setup clear boundaries “Baseline”
4. State the purpose “Goal”
5. Organize our thoughts “Plan”
6. Issue instructions to get things done “Action”
7. State what has happened “Report”
8. Document stuff so as not to forget “Remember”.
   Now let relate these to ‘testing’. Look at the 1-7. Sounds familiar? This is what we do when we commence testing – Understand, Simplify, Baseline, Setup goal, Plan, Action/do(Test), Report and Remember for future.Now let us see how the language which we typically use to document/write shapes how we think.

1. Describe a story “Understand”
   Understanding is a key element to good testing. To understand whose need(s) we are trying to satisfy and the value expected, it is critical to think like an end-user. We often use the term “think from the user point of view”, but it is easier said than practiced. To enable a deeper and better understanding of the system a persona-based approach i.e of Describing the behaviour and the associated attribute(s) in first person as if the end user is describing it from his/her point of view enables you to put yourself in the shoes of the end user, empathise and therefore understand better.

2. Breakdown the problem “Simplify”
   Any non-trivial thing is presumed complex. A true hallmark of good understanding is de-mystification, that of making it simple. From a language perspective, it is about summarizing, of describing in short sentences and not exceeding a paragraph.

3. Setup clear boundaries “Baseline”
   A clear baseline as to what-to-test (I.e requirements/features) is necessary to ensure clarity in what we need to and that we have indeed covered i.e evaluated completely.  Using a imperative style sentence that is short and precise forces us establish a clear baseline.
   For example a customer requirement may be stated as “That the system admin shall be able to …” while an example of technical feature is “That the system shall provide ….”.
   Note that a descriptive or a narrative style is a strict no-no here.

4. State the purpose “Goal”
   Testing is about ensuring that the needs of the various end users  delivered via the technical features do meet their expectations. Not only it is necessary to clearly outline the needs as a clear baseline, it is equally necessary to ensure that the expectations are well stated.
   This implies that the baseline has to be qualified with a criteria that is indeed objective. For example “That the system admin shall be able to do ‘blah’ within ‘x’ seconds on these ‘y’ devices”.
   I.e A short imperative sentence with a qualifier that is objective.

5. Organize our thoughts “Plan”
   This is one of the things that we do most frequently in daily life,  the To-do list. The way we do this is to list down activities in a numbered bulleted list in sequential order (based on time).
   The language that we typically use is in first person using an  imperative style. The method that we use to think is in terms of bullets with a imperative style heading with a narrative style to describe the plan of each To-do action in detail.

6. Issue instructions to get things done “Action”
   This is where we come up with scenarios to test. What I have observed  is most often a narrative style description that describes the actions to performed, the data to be used, and the method of validations to assess correctness.
   From a language perspective it is necessary to be action oriented here I.e describe each scenario as a command and the associated expected result in single sentence and then describe the steps to perform. For example “Ensure that the system does/does-not ‘foo’ when ‘bar’ is done”. First be clear of what you want to accomplish before you jump to how-to-do.

7. State what has happened “Report”
   Now this is the fun part as reporting can describe multiple facts that are all connected, leading to complexity and confusion. From a language perspective, reporting is describing outcomes arranged by elements across time with associated detail and therefore the sentence to describe these can turnout to be inherently complex. This is applicable to defect reporting, reporting test cycle outcomes, to reporting final rest results and to describe learnings etc.
   To ensure clarity of thought, it is necessary to partition the description first in terms of summary and detail, then partition the detail into smaller elements, describing each element along various dimensions.
   In the case of defect report we describe a short synopsis of the problem and then then describe with multiple elements like ‘detailed observation’, ‘method to reproduce’, ‘environments observed in’ etc.
   In the case of test report, we commence with a summary and then describe the various each element in a section with different dimensions to describe in detail the elemental information as possible subsections.

8. Document stuff so as not to forget “Remember”.
   This is really the free form part, the part that we jot down everything we observe, learn from past. This is one part that we cannot stick to one style of syntax. This is a mixture of all styles mentioned above and beautiful mixture of terseness with detail.
   The structure of sentence matters to the way we think, understand, perceive. Ultimately the content(semantics) matters, but the structure does matters too. Syntax is a great guide. A guide that shapes how you think, enabling you to stay on the path of clarity. Syntax used in a rote matter may be seen as restrictive, but clearly it marks the path of clarity. Use it. Use it wisely.
   It matters how you write/document. Clarity is truly a function how you describe. Remember language shapes the way you think or how it makes others think!

Enjoy!

A similar article was published in “Musings Over Tea Time – Anthology of T Talks by T Ashok” in May 2014. The full article is available on page 15 under the title “Language shapes the way we think” and can be accessed here.