(In this SmartBits, Zulfikar Deen outlines “Business mindset“. The video is at the end of this blog)

As a partner/solution provider, the first and foremost one is the need to have a partnership mind with the IT team of organization. It is about understanding the difficulties that have been articulated, spending a few of days with them in meetings and understanding the process and difficulties and empathise with the team.The solution needs to be planned right from the technology, to rolling out, to support along with the organization. Hence taking a partnership approach is of utmost priority.

Secondly the solution needs to be cognizant of the whole life cycle of system, be it a patch upgrade, support or training. Everything has to be taken into consideration for the solution to be successfully used by the user, the whole chasm needs to be cast. As a solution provider one must try to keep building these layers or parts of the system and have a view of whole thing into the solution, as it gets much easier then to roll it out.

Thirdly, never attempt to do a half-baked solution of production roll out, it is going to be very very challenging. For instance if there are twelve thousand users one cannot control the perception of users. Once the user gets the perception that the system is not good,  it is very difficult to recover from there.

If we have to deliver a minimum viable product of three features, we need to do it thoroughly well, make sure it is integrated well and works well before we put it into the system.  One should never have the view of handing over the system tousers, get feedback and then figure out what to do with them. A very different counter view of the DevOps process has been considered  in this case.

Finally, always build in a bake-in adoption matrix,  people don’t do that normally. If a system is rolled out, the management, CIO,  or even we as a solution provider should be able to look at the adoption matrix as a business matrix, where in actual adoption, usage, everything has to be already baked. These are the views beyond technology, database or architecture and need to be part of one’s thought process and view when building a solution.

When we are actually working with the solution providers who are not large but small, there is always a thought about the risk of startup going down. Then what happens? How do we protect our business is always on our mind and we should never underestimate that thought process. The best way forward as much as possible is to build on open standards, open platforms. When we use open source , it gives a sense of comfort. If something goes wrong we will be able to find skills to manage this beyond. Otherwise we are already challenged with  team that is not able to scale up with the rapidly moving technology. We can’t take one more solution and figure out what happens with the system. So it’s easier sell for a solution provider who build on open standards and take it to the market
Open standards could be domain specific for example with healthcare  it could be HL7. It could be technology specific. It could be domain, technology or either one of them build on open standards, making it easier for us to make the right decision.

T Ashok @ash_thiru  on Twitter

Summary
As software test practitioners we revel in finding bugs,  and as managers and engineers we are focused on fixing these. Steven Johnson in his book “Where good ideas come from-The seven patterns of innovation” devotes a chapter on errors as a source of innovation. This article summarises key ideas from this outlining how erroneous hunch changes history, how contamination is useful, how being wrong forces you to explore, how paradigm shifts with anomalies and how error transform into insight. 

Brilliant software testing is interesting, kinda like Star Trek, going into the unknown. It requires discipline, creativity, logic, exploration skills, note taking, observation, association, hypothesising, proving and  juggling multiple hats frequently. It is not a mundane act of finding bugs and getting them fixed. It is just about scripting and running it to death. It is about exploring the unknown, driving along buggy paths, discovering new ideas, suggesting improvements, enhancing experience, embedding testability and having the joy of creating beautiful software by looking at the interesting messiness.

When I read the book “Where good ideas come from – The Seven Patterns of Innovation” by Seven Johnson, I was delighted to know that one of the patterns was “ERRORS”. An entire chapter on this was a treat to read. As a test practitioner I have always meandered along the paths of anomalies, understood implementation and intentions deeply, and have come up with interesting suggestions to improve and enhance experience. Errors have been my best partner in perfecting what I do and coming up with interesting ideas. 

In this article I have summarised key facets from this chapter “ERRORS” outlining how erroneous hunch changes history, how contamination is useful, how being wrong forces you to explore, how paradigm shifts begins with anomalies in the data, how paradigm shifts with anomalies and how error transform into insight. 

An erroneous hunch changed history
The strange correlation between the spark gap transmitter and the gas flame burner turned out to have nothing to do with the electromagnetic spectrum. The flame was responding to the ordinary sound waves emitted by spark gap transmitter. But because De Forest had begun his erroneous notion that the gas flame was detecting electric signals, all his iterations of Audion involved some low pressure gas inside the device that severely limited its reliability. It took a decade for researchers at GE to realise that triode performed best in vacuum, hence the name vacuum tube. The vacuum tube, the precursor to the stunning electronics that would sweep the world n in the next few decades was born from an error. De Forest watching the gas flame shift from red to white when he triggered a surge of voltage through a spark gap forming a hunch that gas could be employed as a wireless detector could be more sensitive that anything than anything Marconi or Tesla had created to date. An erroneous hunch changed history.

Contamination is useful
Alexander Fleming discovered the medicinal virtues of penicillin when the mould accidentally infiltrated a culture of Staphylococcus left by an open window in his lab. Antibiotic was born. A bunch of iodised silver plates left in a cabinet packed with chemicals by Louis Daguerre formed a perfect image when the fumes spilled from a jar of mercury. Photography was born. Greatbatch grabbed the wrong resistor from the box while building a oscillator and found it was pulsing a familiar rhythm. Pacemaker was born. Contamination is useful.

Being right keeps you in place. Being wrong forces you to explore.
The errors of great mind exceed in number those of the less vigorous one. Error often creates a path that leads you out of comfortable assumptions. DeForest was wrong about his utility of gas as a detector, but he kept probing at the end of edges of the error, until he hit upon something that was genuinely useful. Being right keeps you in place. Being wrong forces you to explore.

Paradigm shifts with anomalies. 
Paradigm shifts begin with anomalies in the data, when scientists find that their predictions keep turning out wrong says Thomas Kuhn in the ‘The structure of scientific revolutions’. Joseph Priestly thought a plant would die when kept in a jar depriving it of oxygen, it turned out to be wrong, discovering plants expel oxygen as part of photosynthesis. Being wrong on its own doesn’t unlock new doors in the adjacent possible, but it does force us to look for them. Paradigm shifts with anomalies.

Transforming error into insight
Anro Penzias and Robert Wilson thought noise in the cosmic radiation was due to faulty equipment until a chance conversation with a nuclear physicist planted the idea that this may not be the result of faulty equipment, but rather the still lingering of reverberation of big bang. It changed the opinion that the telescope was the problem. Coming at the problem from a different perspective with few preconceived ideas about what the correct result could be can enable one to conceptualise scenarios where the mistake might be actually useful. Transforming error into insight.

Noise free environments end up being more sterile 
A few decades ago Prof Charles Meneth began investigating the relationship between noise, dissent and creativity in group environments. When his subjects were exposed to inaccurate descriptions in the slides, they became more creative. Deliberating introducing noise forced the subjects to explore more in the adjacent possible enabling good ideas to emerge. Noise free environments end up being more sterile and predictable in their output. The best innovation labs are always a little contaminated.

Error is what made humans possible in the first place.  
Without noise, evolution would stagnate, an endless series of perfect copies, incapable of change. But because DNA is susceptible to change – where mutations in the code itself or transcription mistakes during replication – natural selection has a constant source of new possibilities to test. Most of the time, these errors lead to disastrous outcomes, or have no effect whatsoever. But every now and then, a mutation opens up a new wing of adjacent possible. From an evolutionary perspective, it’s not enough to say “to err is human”. Error is what made humans possible in the first place.  

Mistakes are not the goal, they are an inevitable step in the path of innovation.
When the going gets tough, life tends to gravitate towards more innovative reproductive strategies, sometimes by introducing more noise into the signal of genetic code, and sometimes by allowing genes to circulate more quickly through the population. Innovative experiments thrive on useful mistakes, and suffers when demands of quality control overwhelm them. Mistakes are not the goal, they are an inevitable step on the path of true innovation. 

Truth is uniform and narrow, error is endlessly diversified.
“Perhaps the history of the errors of mankind, all things considered, is more valuable and interesting than of their discoveries. Truth is uniform and narrow; it constantly exists, and does not seem to require so much an active energy, as a passive aptitude of soul in order to encounter it. But error is endlessly diversified.”

Benjamin Franklin

(In this SmartBits, Anuj Magazine outlines “ On Career Growth “.  The video is at the end of this blog)

Career growth can be divided into two
buckets. One is  the nonlinearity aspect
of the career, and the other uni-dimensionality. One of the things found common
in most reasonably sized organisation is that each and every organization has
career paths and the way the career paths tend to get designed are that there
is an entry role that one gets into post college and then there is a role at
the top.

The role which is essentially at the
top of these ladders are of a VP or a Department Head.  Looking at these career paths, the highest
designation in the organization is that of a CEO, if we associate these two
logically, we will tend to think why organizations do not give a path till the
CEO role in the organisation. This led to the question on the linear approach
of following the career paths,  that are
designed in the organisation.

Mark Templeton CEO of Citrix for
around 20 years and quite respected in his field said that career paths up to
the top in the organisation rarely tend to be linear, they always zigzag. One
needs to figure out where the next dot is, to move forward. This questions the
rationale behind the linear careers. There is nothing wrong having a
predictable career path. It does help to solve a problem in the organisation.
For instance HR wants predictable processes, even employees want them too, and
there is nothing wrong with that, as not everyone wants to be a CEO. But there
are other merits to following a nonlinear path.

The second part is on the uni
dimensionality, let us take example of startups, .When the startup is new and
the product market fit is not achieved, people play different roles being in
one designation such as marketing, coding, testing or they may be hustling
around and doing sales. In early stage organizations, one can afford to be a
specialist in the interest of moving the organisation forward, but when it
comes to scale, the uni- dimensionality, the specialisation matter,  of having a deep knowledge of one subject or
maybe a related set of technology help scales the organisation and go to the
next level.

Should I be a generalist or a
specialist? If you want to be a specialist, choose a field that is going to be
relevant in the time to come.The people who chose artificial intelligence and
machine learning fifteen years back are reaping the rewards of that. In IPL we
see around 200 odd cricketers from India in that competition, which is hardly
around two to three percent of the cricket playing population or even less and
these are like hyper specialised individuals who specialise in their areas.For
choosing a specialised field it is better to have the conviction to be in the
top ten or twenty percent so that one can reap the rewards in the time to come.

Generalists are people who are more adaptable, who can learn a new skill in a shorter time and deliver value and it is more akin to the gig economy. Pick up the rules for some time and then move on to something else. There is nothing wrong in both of them. Both have its merits and demerits. Hyper specialisation is going to be the thing in the future.

The QA profession has been under pressure from external forces, as decision makers in organization want to see more value. It comes to more of an economics decision, that we always called as cost of quality, we never use the term profit of quality. We need people who can represent QA in a boardroom where value can be showcased, and that is lacking at the moment.

T Ashok @ash_thiru on Twitter

Summary
Smartness is a brilliant combination of knowledge and skill. Skill is acquired by intense practice. Intense practice happens when you have good habits. In this article I look at SEVEN habits that are key to SmartQA.

Habit #1
Visualise well, see the big picture of the system.
Who uses, where, when, using what interface. See the big picture of how it is structured/architected, visualise the flow of control and data and the technologies used(aka tech stack). Appreciate the environments it should run on the dependencies of external systems and changes/modifications done.

Habit #2
Question well. Question to know. Question to know what you do not know. 
Ask about users and their expectations ask about the how it is constructed, ask about conditions a behaviour should satisfy.
Ask, ask… The limit to questioning is unbounded. Note you may not get all the answers, the key is to question.

Habit #3
Prove with facts. 
Show proof of adequacy of tests, hypothesise potential issues and prove that they may be detected.
Understand changes done and prove why an entity(ies) need to be regressed, after all you do not want to more that needed.

Habit #4
Iterate continuously. 
SmartQA is about experimenting, exploration.
It is about iterating with minor changes to understand better, to observe better.
Chew well to digest.

Habit #5
Unlearn. 
Revise what you know.
 Understanding is not about knowing more, it is also discarding what you know. 
Chew to digest and spit out the rest.

Habit #6
Empathise.
Put yourself in others’ shoes and feel them.
Get inside them to understand what they expect, what they will dislike, their constraints, what value they expect of the system. SmartQA is not testing the system technically, it is about delivering value.

Habit #7
Simplify the problem solving.
End users use systems to solve their problems. Great software solve them well.
Good testing is about ensuring systems do just enough i.e. simply.

(In this SmartBits, Tathagat Varma outlines “What is Agile?“.  The video is at the end of this blog)

Software is a problem-solving process, where we are trying to take a shot at how we should be solving the problem. What is the best way of solving the problem? Looking at the philosophical element, a software is a way in which we are encoding a problem, solving from a given point of view. A designer would think of a  particular way to solve the problem and encoding that in a medium. Software is only a medium. It could have been any other medium for example , in which a problem could be solved.

What is the right way for us to solve the problem? Should we have a world view which is based on ‘we-the-designer’ or should we have a world view based on you as a  ‘we-the-consumer’. If you are the customer who is the real consumer of that? This needs to be understood.

Philosophically the first most important thing is to understand we are not building software for ourselves or for people like us. We are building software for a given audience and we need to be mindful and respectful of how they solve the problem. The philosophical element is really about, whom are we building for and are we mindful of the fact that this is how people solve the problem.

The mindset is the way, where we take the next step forward, where we say that now that we have understood the world view from how people look at it, how do we really solve the problem. Should we wait for a fully baked way of doing it. The basic idea is we cannot solve the problem in a single pass.

Every complex problem is best solved in a very iterative manner in a very collaborative way in which do not treat our consumers as just passive consumers i.e whatever we dish out to them, they will accept it. Even without the software they are solving the problem day in and day out which means they have some wisdom about how a good solution should work out. If I partner with them and treat them as a co-creator rather than a passive consumer then I can actually create a better solution. Mindset is all about stating that they are not passive consumers, they are co-creators, they are our team, so we start teaming up with them.

The Agile mindset very simply is something that we keep borrowing from the work from a Stanford professor Carol Dweck. She wrote this book on mindset where she talked about fixed mindset vs growth mindset, where the whole idea is that some people have a fixed mindset- this is the only way this should be done and have a very strong point of view. They are not willing to budge from that opinion. Then, there are people who think maybe there is a better way of doing it, maybe there are other ways in which we can grow, we may not succeed in that but in the process of doing it, will stumble upon the truth and that will help us eventually get to the right solution.

Having that kind of a mindset where we are open to experimentation, open to learning, willing to take some meaningful risk, not scared of failure, willing to keep iterating over is the need of the hour. We need to have a culture that really supports these kinds of mindsets. This is the third aspect here.
In organisations where making mistakes is a considered sin, where an individual gets reprimanded for failing,  Agile thinking will not work. Agile demands tolerance for intelligent failures. We need to have an appetite where we can say this person made a mistake. let us have a small party, let us learn from that person.  If it is a great mistake we make a big deal out of that.

That Agile mindset will not fit into a very conventional kind of a culture where people say do not make any mistake, do everything right the first time, everything has to be Six Sigma. A very nice quote by a management professor Gary Hamel, where he said thank God for the biological screw-ups, if not for that we would still be slime, because in a Six Sigma world, evolution would not have happened, if animals did not genetically recombine with each other in novel ways.  

If we are really looking at very creative ways of doing things and are looking for finding some novel solutions to that, one has to have a tolerance for bringing the Agile mindset into the workplace. Agile mindset is like the seed that requires an Agile culture as a fertile ground, otherwise it will not sprout.
Tools, methods and processes are the fourth and the fifth-order extensions, because in order for us to do the job properly we need the tools. Unfortunately people get it totally wrong, they ignore the holistic part of why we are doing it, the whole philosophical element, the mindset and culture, they straight away jump onto tools and methods bandwagon, because that’s the easiest thing to sell. The tools, methods and processes are the fourth and fifth order functions of the core thing but the whole idea is if we don’t start on some of these basics, we will never get to the point. If we start only with the tools, it might give a short-term win but then it’s not sustainable and definitely not be scalable in the long run.

(In this SmartBits, Girish Elchuri outlines “Build in quality“.  The video is at the end of this blog)

One of the important things we have to remember is that we can not add quality. Adding quality is not similar to painting a wall. It has to be built in and for that, we should have all the processes in place, starting from architecture, design and development and so on.

An example in this context would be the way a German car company makes cars. They build the car, do extensive testing, fix it and then only release it to the customers so that they get an excellent product. Looking at another company in Japan that makes high end luxury cars, when this company finds a problem in one of the cars before it is shipped off, they stop the assembly line. Then, they find out where the defect has been introduced, fix the process and throw away all the cars that are manufactured with that defective process, and start manufacturing again. The result is that Japanese car with the same quality and luxury of German car is build at one-third the cost. It is a classic living example we have.

Building quality through absolute processes is more beneficial, important and efficient than trying to add quality or stating that quality can always be added later. When a pizza gets burnt then can the quality assurance team make it proper? Certainly not, because it is a one-way process. It is important to realize that we can’t add quality. 

We have to only build quality into a product as part of our architecture, design and development. It has to be the attitude of the organization. It has to come from top- down. Organizations, people and processes should have the attitude of building quality in and not adding it later.