Wednesday, July 21, 2021

Why Knowledge Transfer (KT) is not as easy as Fund transfer (FT)?

Those in IT industry - there is a familiar phrase called "Knowledge Transfer" or popularly known as KT. Having genesis in IT services industry this phrase was coined to indicate a training process between someone who is considered as SME (subject matter expert) and someone who is receiver of the training.

Typically happens between client side SME and an engineer/analyst from vendor side. In the early days of outsourcing between US and India - you could hear this term in all client and management meetings. "How is KT going on", "when are we completing KT and start doing work",  "Client SME does not have enough time to complete KT".

In its new avatar - this KT make its way into cross training within the team and breaking "key person dependency". 

I always wondered how knowledge is transferred between two individuals or one individual and a group of individuals? What knowledge we are talking about? What is knowledge after all? What it means to know anything? How do we measure level of knowledge that one person has at any given point of time.

These questions took me to the idea of Tacit knowledge and explicit knowledge.

From Harry Collin's Tacit knowledge book 

"Much of what humans know we cannot say. And much of what we do we cannot describe. For example, how do we know how to ride a bike when we can’t explain how we do it? Abilities like this were called “tacit knowledge” by physical chemist and philosopher Michael Polanyi, but here Harry Collins analyzes the term, and the behavior, in much greater detail, often departing from Polanyi’s treatment.

In Tacit and Explicit Knowledge, Collins develops a common conceptual language to bridge the concept’s disparate domains by explaining explicit knowledge and classifying tacit knowledge. Collins then teases apart the three very different meanings, which, until now, all fell under the umbrella of Polanyi’s term: relational tacit knowledge (things we could describe in principle if someone put effort into describing them),  somatic tacit knowledge (things our bodies can do but we cannot describe how, like balancing on a bike), and collective tacit knowledge (knowledge we draw that is the property of society, such as the rules for language). Thus, bicycle riding consists of some somatic tacit knowledge and some collective tacit knowledge, such as the knowledge that allows us to navigate in traffic. The intermixing of the three kinds of tacit knowledge has led to confusion in the past; Collins’s book will at last unravel the complexities of the idea.

Tacit knowledge drives everything from language, science, education, and management to sport, bicycle riding, art, and our interaction with technology.  In Collins’s able hands, it also functions at last as a framework for understanding human behavior in a range of disciplines."

This post from Michael Bolton takes the ideas around "tacit knowledge" and "explicit knowledge" using very entertaining video where kids give written instructions to make peanut butter sandwich  to their dad. See what happens.

Time to learn more about this....

Revisiting Jerry's famous Mary had a little lamb heuristic

 Let me propose a hypothesis "Anything written/expressed in natural language is inherently ambiguous".  As one of hallmarks of civilization and evolution - language evolved as a tool for communication. Language connected people, got embedded in culture, grown into world of literature and finally technologists (being human) started using natural languages to represent and communicate "technological content".  This is where the hypothesis I mentioned in the beginning of this post comes into being. 

For technological or any formal purposes such as finance, legal transactions -  absolute clarity on intent and meaning of constructs of the language - words and sentences is a mandatory requirement. As we can see sentences in natural language can be interpreted in many different ways. Each reader/consumer of such language constructs makes his/her own meaning based on context that is assumed. Also there are differences in spoken and written versions of same text. So we have a problem in use of natural language in formal cases like software development and other areas. In addition to fundamental ambiguity as part and parcel of natural language - transmission of content from person to person add's its own elements of complicating meanings.

Jerry Weinberg, father of testers - recognized and wrote about this long ago. In a book "Exploring Requirements - Quality before design" with Donald Gause - he introduces a tool/technique or heuristic with a catchy name "Mary had a little lamb" - to find out how ambiguous simple line from popular nursery rhyme can become. "Nursery rhymes are infamous examples of ambiguity because of some of them have been transmitted from child to child over hundreds of years, and the original meanings of the rhyme might have been lost of transformed" writes Jerry when introducing the technique.

"Is it possible that a line from Rhyme "Mary had a little lamb" have hidden meanings ?" asks Jerry. In order to bring out such hidden meanings - he proposes following trick.

"If we emphasis each word in a line, one by one and then in combinations we can easily identify 6 or with some additional effort up to 30 meanings of just one line of the rhyme"


Mary had a little lamb

(Its Mary's Lamb - Not Sophie or John)

Mary had a little lamb

(She no longer holds the lamb now)

Mary had a little lamb

(she had only one lamb not many)

Mary had a little lamb

(Its really surprisingly small)

Mary hand a little lamb

(she did not have a dog or a rabbit - it was a lamb)

With all emphasis

Mary had a little lamb

(As contrasted with Pallas who still has four turtles)

So you have one way to subject a sentence to a sharp scrutiny for ambiguities.  Jerry in same book provide yet another corollary to MHALL (Marry had a little Lamb) technique.

This is called MCTT  - Mary Conned the Trader. In this technique - we substitute synonyms for each word in the sentence. Once we have listed down probable synonyms for each word - we can create new sentences as probable interpretation of original sentence taken in another context. By changing context's we would try to identify hidden meanings and possible interpretations.

How does this work? First - take the help of dictionary and elaborate meanings and synonyms of words and list them down.

Let us take words "had" and "lamb"

Had - Past Tense of Have

Have - to hold possession, to acquire ownership, accept, to marked or characterized by, to build a position of disadvantage, beget, bear (have child), bribe, eat

Lamb - young sheep one year old or without permanent teeth, young of various other animals (antelope), person as gentle or as weak as lamb, dear or pet, a person easily cheated, flesh of lamb as food.

With these different meanings - let us get some more meanings of MHALL

- Mary owned a young antelope

-  Mary is (or was) mother of particular small, gentle person

- Mary bribed a small person trading securities who was easily cheated

- Mary ate a little of flesh of a lamb

- Mary held a little sheep under one year of age or without permanent teeth in a position of disadvantage or certain defeat

- Mary acquired a little sheep under one year of age or without permanent teeth.

Well - what if Mary is not a human  but another animal or tree or a group of people.

Mary (Sheep) had given birth to a little lamb last month.

Jerry concludes the section in the book with following comments -

"The commonly held view that the poem is about an innocent young lady with a loyal pet is naive in the extreme - not as naive, though as sophisticated adults who pick some line out of requirements document and without giving a second thought, proceed to develop a product based on single, wrong interpretation."

For testers - its important to look at requirements from multiple angles and perspectives. Application of these two techniques - MHALL and MCTT as heuristic (thumb rule) helps them to see ambiguities in natural language constructs.

Some additional resources about natural language and ambiguity

Before I end this post - a question. Why communication in natural language had to be fundamentally ambiguous?

When are you trying to use these in your projects? Do let me know.

Friday, May 21, 2021

What is Test Design and Test modeling

 Test modelling - Activity of representing system/feature under test as a model. 

A sample hierarchy


        Entities/Objects/Users (Roles)

            Dependencies between objects

                Relationships - IS A and HAS A (Type and containment)

                    One to one, One to Many

                        Properties (variables and constants)

                                Values (domain) of properties

                                    Default values, boundaries of values

                                        Combinations of Values to create test scenarios

Object - Action - State Change.

List actions on each objects.

Create a map of what will happen when an action on object happens

Simultaneous actions

Dead locks


how do we use  BB design techniques

EQ partitioning

State machine

Decision Tree


Take  a par of variables and create a Grid.

GUI Testing check lists (applicable to new GUI)

Static vs Dynamic Models

Model - when nothing is happening. No user interaction

Dynamic - when users are interacting

Time element

It might help to user Object Oriented Design to represent above idea.

There are objects - have properties and functions.

Nouns and Verbs

System will have objects/entities. Objects have properties, properties can be constant or variable.

Take each variable - explore the domain of the variable. See what kind of values it can take and 

String these variable values into test scenarios.

This act of modeling - goes through iterations. It's like a photo film negative development. With each iteration  - various features of system start showing up.

Idea of Test coverage -

Imagine a 2 D shape - area of features in two dimensions.

Covering area means exercising the walking through the area.

how about Volume ? 3rd dimension - features and values

Wednesday, May 19, 2021

How to improve Questioning skills

 Following up on a post in The test tribe FB group - here are my toughs on improving questioning skills

First - few ground rules on questioning

  • Questioning is a skill - improvable on deliberate practice
  • Questioning does not mean being disrespectful to other party
  • At times questioning might be taken as challenging the authority - deal with it appropriately.
  • Empty your ego and false sense of "I know this stuff" - instead approach "what else I don't' know here" What else is hidden from me now.
  • Frame questions and follow-ups in a way that it does not turn off or irritate other party
  • One good way to start question is to describe or re-phrase the understanding in words of other person wherever possible and seek view on if your understanding is correct
  • No question is silly (from the view point of the asker...:) Only unasked question is silly
  • while answer is being given - listen carefully - where applicable watch body language of the responded. Do not rush or pounce on  immediately.
  • Listen with an intention to understand not with an intention to answer in return
  • If you question basic ideas - it will not make you less in any way or a fool
  • Display courage and humility

Tips/Practice ideas
  • Ask one question at a time (Courtesy : Jerry Weinberg narrated by Ajay Balamurugadsa) 
  • Approach everything with "awe" and a sense of wonder.
  • Approach everything with mind of "newness or not seen before"
  • Develop good vocabulary and skill to say one thing in many different ways
  • Be good with creating examples and analogies
  • Dramatize your answers and questions
  • Do a role play
  • Create diagrams 
  • Ask "What does *this* mean? 
  • Seek meanings , interpretations and context of words
  • Learn about word etymologies
  • Develop understanding through responses received
  • Do lots of imaginations
  • Show child like curiosity
  • Split words from sentences - ask "what does this mean" to every word
  • ask "what id"
  • Ask what are constrains or limitations here - what if these constrains are not there - for example - what if we can fly defying the gravity or what it we can walk on water
  • Question universally known and understood words and ideas
  • Question authority
  • Do not settle for right answer - seek more broader set of responses
  • Be respectful
Human relationship aspects of Questioning
  • You always run into risk being perceived as arrogant, egoistic, "know all" OR completely dumb
  • You are mostly likely to put people out of their comfort zone and make them feel nervous
  • People may not speak to you nicely or avoid talking to you
  • Understand emotional aspects

Types of Questions:
  • Open Ended -  Non conclusive answers
  • Specific - 
  • Binary - Yes/No
  • Questions to check knowledge
  • Questions to understand

Tuesday, November 24, 2020

What's big deal with testers? Hit that punching bag !!!!

 Once in every 1 or 2 years - testing team or function comes under "question". I have seen this consistently for last 20 years. For business leaders, Heads of Business verticals - testing has been a punching bag. Whenever leadership changes or sales go low or profits fall - suddenly discussion on "efficiency" and throughput per person becomes an important metric. Why do we need such a big testing team? why cannot developers do all the testing required? Why not end users do the testing required? why cannot be automate this stuff and get testing head count out of equation? Why cannot we do crowd sourcing? - are the questions that business leaders ask. Testing leads and managers - start running from pillar to post to justify why they exist -- come up with all sorts weird metrics and process maps to show why testing required. But business leaders are hell bent on cutting that "extra" fat in the system. There go "testing team " out of the company.

What is big deal about testing or testers ? They ask. First of all let us ask what is/ required to do testing? Knowledge of the system or business domain or technology that used to build it?  Let us explore...

Business analysts know the product inside out as they have "defined" it (by writing down BRD - business requirements document). They should be the ones best suited to do all or required testing. No?

Developers too claim that they know system inside out  - as they have created it. They know nuts and bolts of the system where each one is. Should they be the best ones to test the system?

End users are best to test the system as they are the ones that eventually use the system they know what should be there in the application. Are the the best party to test?

Before we respond to above possibilities - let us also look at how industries shaped the views about testing. In software world (or software enabled businesses), broadly there are 3 types of industries - Software product companies, IT services companies and IT organizations or captive units of other (non software) businesses - likes of banks or pharma or Automobiles etc. Each of these have a very specific and unique "culture" about software and hence about testing.

Software product companies call software development as "Engineering" and all activities about creating a software is put under one umbrella "software engineering". Testing is part of "engineering". Pre-agile Era had testing as part of "development" life cycle and developers did all testing that they could. Agile and Post Agile (now DevOps era) killed "testing" function or skill or requirement by few beliefs or practices. Agilists extend logic of all testing should be done by developers and said "quality" is every ones' responsibility. Thru practices like TDD and formalized unit testing - testing as seen as excercising or executing every line of code (they wrote). Testing would mean writing code - hence programming and testing at some point merged into one skill. If you are in an engineering team you did not do coding means - you are either a business analyst or project manager (or scrum master - not ring master !!! :) 

IT organizations  or captive units are next big communities - looked at testing as either some necessary evil or something that programmers or technologists should do. Business leaders of these groups saw entire software development as an alien thing and kept a safe distance from it. For these software or technology was a support function and thought any investment in activities (like testing) related to software development as "distraction" from their main business function. Technology teams in such organizations too had a strange problem or approach. They thought all required knowledge of business domain or application resides with business so technology job is sincerely translating whatever business gave as requirements. No questions asked. They also propagated a view that technology testing is a shallow happy path and basic validation. They believed its not their cup of tea to learn business domain.  So where did  bulk of testing go? To business and End users in the form of "User acceptance Testing".

IT services companies did not have any of such challenges about thinking about domain, business, technology and testing. They simply supplied what their clients wanted. Hence IT services companies had mix of both IT org and product company cultures. IT services companies did not have to have their testing culture. In the beginning (pre-2000) - by riding outsourcing wave - went and told their outsourcing bosses - "testing is low risk work - we can take it away and do it for very low cost". I have heard pricing models of testing services on unit basis - xx $$ per test case. How crazy was that? When they ran out of business supplying "low skilled" (almost brain dead) "executors" of test cases (called manual testers) - they started selling them as business analysts. In that parlance - business analysis did some testing but knew business domain and could "write" BRD's. Even today many testers think that "business analysts" are one notch above testers in terms of salary and org hierarchy.  That option too soon ran out. These companies then started selling failed or low skilled developers as "automation engineers". This going even today..... skilled testing has been dying... not dead yet.

I ask -- what is big deal about testing - what makes testing  "tick" in todays situation? Share your views.


Sunday, November 08, 2020

My journey of Software Testing - Looking 20 years back - Part 1

“You seemed to have a good eye and aptitude about find bugs in software. Why don’t you pursue a career in Testing/QA? “said Premjit my manager at i2 Technologies roughly about 20 years ago. As it turns out he was damn right in assessing my special skill and interest for looking for bugs in software. At that time – like many other peers I felt Premjit was trying to put me down by asking me pick up a career in Testing/QA while I was aspiring to be a software developer and create awesome applications. That time (true in most of jobs even now), developer meant to write/design code while tester means to “test” (use) those applications to find bugs. Honestly, I felt, it was a let-down for me.

I reluctantly took full time testing role (at that time, in software product companies, testing was a part time job and everyone were called as software engineers). I have to admit that it was decision born out of fear of losing job. But in retrospect – here I am 20 years later – celebrating that shift Premjit suggested me. Post that shift, initial few years were bumpy, I kept looking at my developer friends and used to envy them. In initial few years I took roles that are closer to development while my full-time role was to test. I was software librarian for a new product development - teaching and establishing software versioning and build management. It was interesting as I could hear few developers appreciating my knowledge development practices, IDE (Visual studio) know-how etc. Soon, testing component of my job increased and I became moulded well into doing testing. I went on investing in learning about testing deeper – I took a course (2-day workshop) by T Ashok of Stag Software – who happens to be my first guru on software testing. He still continues to be a great friend, guide and mentor. I attended a testing conference by STeP -in in 2004 – got convinced that the career I took up indeed has good prospect – looking at and hearing all those leaders from industry who were managing testing teams. I was introduced to leaders like Srinivasan Desikan – I still continues to be in touch with him. In another interesting encounter in same year, in QAI conference, I meet Vipul Kochar – good friend with whom I continue to share good collaboration on software testing related initiatives in India. Vipul in his talk (in that QAI conference) on exploratory testing – introduces me to the works of James Bach who still continues to shape up my thinking and influences me about “fearless and think—for--yourself” approach to testing.  That’s I think happens to be a major turning point in my career in testing. That QAI conference was a unique experience as that was my first instance of speaking in a conference, guess what!!!  topic of my talk was “Agile Testing – is history repeating itself”.  I also meet Krishna Rajan in that conference who would 6 years later would give a job for me at Barclays. So, in many ways 2004 was an eventful year for me.

In the mean time I made transition in to IT services world and started learning more about testing by reading through works of James Bach and Cem Kaner. I then came to know about Context Driven Testing school of testing. There used be a yahoo user group called “software testing” where James, Cem and others from CDT were regular contributors.

I vividly recall a post (query – actually) in that group where I expressed my doubts of testing as I saw during that period – 2005. This interaction on that forum with James Bach as a clear eye opener for me and would set me in quest of knowing and learning more about testing in coming years.

Here, I share few snippets of my questions and answers by James. Read carefully. This is how a newbie tester starts off.

My first question about testing was about role of Domain expertise. Major view at that time around me (it is even now largely persisting) was for doing good testing and excel in that one needs to be a domain expert.

I ask “In testing domain expertise is important - for example without knowledge of stock markets – you cannot test an application that is meant for stock markets. I agree with this notion but banking only on this is recipe for failure.”

James responded to this – “Someone without specialized domain expertise can contribute to a test
project within any domain. Besides, some domains aren't that challenging to pick up, and in some cases, the test oracles aren't that difficult.  However, trying to test, say, a radiology imaging system using only testers who have no knowledge of radiology would seem dangerous to me.”

That as an important lesson to me – while having domain knowledge in area application is a good thing but that is not a mandatory thing. You can contribute to testing by various other skills in spite of being a newbie in that business domain.

My next question was [paraphrase] “Any developer can do testing (he/she does any way unit testing and other forms of developer testing). So, if we train him/her on automation tools - we are ready for state-of-the-art Testing. Why we need a separate role for testing?”

James responded – “Any developer can do testing. So can any plumber, any housewife, or any politician. Anyone at all can do testing. Do they do it well? That's the question. Developers bring certain skills to testing that I like to have in my test group. They also bring certain biases.”

This taught me why it is important just not do testing but doing it well – like a specialist would do. Anyone can do testing – that is a fundamental human trait to check things. But a professional tester would do testing “well”.  Developer Testing has its own biases. I was introduced to the idea of what developers often miss when they test – conformance oriented or confirmation heavy testing.  When you are a professional tester – you would look at the task of testing as if your whole world depends upon how well you do it. It’s no longer a ‘task” that had to be done. This thought made a huge impact on my thought process of testing.

I, then asked about another popular field of QA Process” – Why certain companies bank on quality jargons - CMM, ISO, Six Sigma saying that testing and QA are one and the same. Further they claim they follow CMM /ISO/Six sigma based so quality is obvious outcome – we don’t consider testing as specialized skill. We are fine with our developers doing all required testing.

James dismissed this by saying “Well, that's just corporate religion. I'm frustrated with that, too.”

This was a burning question that I had at that time “As mentioned in points 1, 2 above, if we have developer who can do  testing  with automation tools and business experts who bring  the necessary business knowledge and speed/efficiency in testing - where is the scope for  Tester - How do I emphasise/sell  the concept of " testing" being a unique software life  cycle activity and brings definite value to end product. In other words, in what way a tester is different (in skill sets and nature of work) than developers and business consultants or analysts?  What is the need for hiring testers instead of developers doing testing too?”

James responds – “I think if you don't have a clear idea, yourself, about what testers do and what skills they have, you won't be able to convince anyone else. Here's one skill: the skill of making models. This is a sub-skill, in my reckoning, of general systems thinking. Another skill is critical thinking, which involves using logic, of course, including the process of abductive inference. These skills are difficult to evaluate in an interview. Hiring people who aren't developers is worthwhile for a few reasons: there's more people to choose from, they probably have different biases, they won't be trying to get into a programming job, they will probably be better at testing overall and they will become better testers over time. I like hiring people with a philosophy education, when I can find them. You have to *demonstrate* the value of testing culture, in order to sell testing culture.  Read the articles and class materials on my website. Go to and take the BBST online testing class.

I learnt through this response from James that – I did not have clear idea of what good testing was myself. I was just observing industry trends, what I hear in conferences and what my peers speak about testing. I was also constantly distracted by “jobs” that are related to testing but not testing actually.

Looking back, I laugh at myself and raw thinking. But these interactions would lay good foundation for my future learning.  My continued asking about my doubts about testing with likes of James and others Context Driven testing community in coming years would make be a better tester and would put me in a position that I can answer questions like these to myself.

To be continued ….


Monday, June 24, 2019

There is no such thing called defect/bug in Machine Learning/AI domain

One question that comes up again and again in Testing world today is about role of testing in the domain of applications in Machine learning and Artificial Intelligence. To be precise, many in testing community are curious and some-what confused about what they need to do differently (if at all) and what skills they need to acquire additionally. This is post is an initial attempt to share my thoughts in this direction.

What is an ML Application ?
(Machine Learning is considered to be a branch of Artificial Intelligence, hence Omitting using AI along with ML)
The term "Machine Learning" is not new, it was coined by Arthur Samuel in 1950. Definition given by Arthur was "ability of computers to learn without being explicitly being programmed".  In reality, computers do not learn, but software programs learn - a small difference, if you chose to care. How do programs gain such ability to demonstrate such human-like ability to learn? Any any or every program be made to "learn" like this? What has enabled today's computer's technology enabled such possibility being realized? Answers to these questions take the post beyond the topic about ML, Testing and defects/bugs. In short - I would say ability of computers to store and process large volumes of data at the speed needed at processing transactions - has enabled Machine learning as Arthur Samuel might have envisaged.

What is Machine Learning application then? A program that  uses a set of algorithms processing sets of specially selected and curated data about a problem that program intends to solve. Under the hood, the algorithms "fit" the data to some selected mathematical "function" called as "model" such that the programs logic is data driven not hard coded. When I say hard coded in ML parlance - you will not find explicit chunks of if-else or select-case or do-while depicting rules of logic. The "model" through "fitting", generates the logic that data presented to it shall comply.

What kind of problems ML programs can solve? Largely two categories of problems - prediction and suggestion. A machine learning program can classify a bunch of financial transactions (say credit card) as fraudulent (potentially) or genuine or recognize faces in a picture or auto complete what you are typing in a search box on a web page. 

What does it mean for a program to learn ?
In simple language - learning for a program is to discover parameters of mathematical function that program uses to establish relation between input and output. Let us take an example of classification that aims to predict whether an image contains text or not. In this case the image and its properties (what each pixel tells about the whole picture) are inputs and output is a binary decision whether image contains text or not (1 or 0). For a human eye - it is easy to make the decision where as for computer  - the problem needs to be presented as (an example) a mathematical function like y =f (x). This function will have its parameters that the program needs to compute. For this purpose the program needs to presented with loads of data (input images and decision whether there is text is there or not). By processing this data the program is expected to identify the relation between "y" and "x" which is a mathematical function like y=mx+c (here m and c are parameters of the function).
This process of arriving at parameters of the function by working through data is called as "learning". Once the program learns the relationship - then, it can predict "y" - decision that whether image contains text of not - given any new image that program has not "seen" before.

Needless to say computer (program) does not "see" the image like a human eye - it (program) sees the image as a matrix of numbers that indicate pixel color scale or density. There easy python modules/programs that can convert an image into a matrix of numbers that a learning program can consume.

Also important to note all that data that the program has "seen" or processed during the process of "learning" does not stay with the program. What is left in the program is just the "essence" of data that leads to establishing the relationship y=f(x) in the form of parameters of the function. The data that program uses to "learn" the relationship is called as "Training Data" - how innovative !!!

Coming back to main topic of the post - what does a bug mean in this context ? When a program incorrectly calls an image as containing text when image does not contain text  - do we call that behavior as application bug? ML programmer would probably call  it as "program is learning" or "program needs to see more data to increase its accuracy of prediction". In this way - every opportunity for program is learning, like we say a lawyer or doctor as "practicing" - ML program, probably never "performs" but always in the process of "learning" !!!

What do you say? If program does learning (I have dislike for the term "machine learning" as its not machine that learning - its the program that is learning. Try saying programming learning, or software learning !!! its funny) - what testers need to learn ? What is left for testers to learn if programs become intelligent ?

Wednesday, May 15, 2019

Industrialisation of Testing, Heuristics and Mindfulness

Over last two week end - The Test Tribe (popular testing community) hosted two sessions on facebook - one from T Ashok on Smart QA and other from James Bach on "Testing Heuristics". Both sessions were well received and interestingly I could see some connection between ideas that were part of these two sessions.

Industrialisation of Testing - Up until now - I thought industrialization in testing as bring "factory" metaphor into what we do as testers - intellectual search for problems in products we test. Ashok T in his session took a different position. He says industrialization in testing is about doing less through exploiting work done by fellow testers in the form of tools, test ideas, methods etc. He drew parallel with how software development community though its open source revolution - makes it possible to build application with writing less and less code. He stressed on creating open source revolution in testing so that testers can share their ideas so that we can use, reuse and grow testing repository. That would be true industrialization. There has been such work happening in our community - what we need a platform and such active participation/contribution.

Mindfulness Ashok in his session urged testers on mindfulness - acting with awareness of how we work, why we do what we do. Very nature of the mind is such that it wants wander and then programs in subconscious mind take over - run the what we do without our conscious engagement. Testers through their habits go about their day's business without being consciously aware of decisions, choices they make. Through mindfulness, testers would need to break the autopilot mode and carefully watch every step - this will enhance their skill, productivity and reduce errors they make in their work. Rarely I have seen such an advise to testers  - indeed a point to note.

Heuristics  James Bach in his session on Heuristics - went on in detail to explain how all testing, software development and Engineering is rooted in heuristics - fallible methods to solve problems. Those who follow context driven testing community are well aware of this term. James explained how heuristics need human judgement not mere following the rule -as heuristics can fail. James said in our daily life we use many heuristics without being aware. He urges, from his own training and experience, to be aware and name a heuristic when you use one.

Here is where I am reminded of mindfulness that Ashok suggested to use. By being mindful -we can recognize heuristics we use, when we recognize , we can name them, when we name them - we can share with fellow testers. That leads a community movement which manifests as Testing industrialization. Its exciting to see these two testing guru's ideas are connected in unimaginable ways.