I recently stumbled upon an interesting article written by Alan Page where he has discussed some interesting ideas around the mindset, tester’s role, and how different software development teams approach testing. If you have not read his article yet, then I encourage you to read it first.
First things first
In principle, I agree with most of the points that Alan has made. I believe that regardless of one’s role, they can test effectively, provided that they are willing to invest in learning, practicing testing as well as thinking like a skilled tester. While making this happen is not impossible, I also believe there are reasons why it could be difficult or not as effective as it should be.
What’s the matter?
If I understood Alan correctly, he considers the idea of a testing mindset to be a myth. Alan proposes to consider thinking in terms of skills instead. In my opinion, skills can be easily acquired/developed as compared to acquiring/developing the mindset needed to do that job better. And for me (and testers who think like me) the mindset is an important matter when skilled testing is a matter of concern.
I have been testing for over 12 years now and I can not imagine meaningful testing being done without the right state of mind. I do not know whether the “state of mind” and the “mindset” are the same things but I believe that it would not change Alan’s opinion about testing mindset.
What is testing?
Testing means different things to different people. For me, it is about finding true knowledge, correct knowledge about the things we test. For me, testing is an empirical investigation of the product, people, and the project along with the relationship between them. And we do this investigation to obtain that true knowledge.
Testing as an investigation for true knowledge is a far different thing than testing as asserting things we believe we know to be true. And this is where I believe the mindset makes a big difference.
Knowledge work and the knowledge workers
I love what Alan has written about software development and testing being a knowledge-work. I would love to quote it here.
Software development and software testing are knowledge work. Both require multiple skillsets, constant learning, and problem-solving. While developing and testing software may require different problem-solving approaches or skill sets, they are both part of the same (growth) mindset, and the best people I know in software can switch between their development/builder and tester/investigator skill sets rapidly and fluidly. While I agree that it’s not easy – with deliberate and frequent practice shifting between these skill sets, most knowledge workers I’ve worked with can – and have become quite successful in developing this flow.
I can’t agree more with this whole argument. However, the catch lies in how one perceives the knowledge to be, how one obtains that knowledge, and how one processes it. Though we all are knowledge workers, all knowledge workers are not made equal nor they can draw similar inferences despite working on the same source of knowledge.My pursuit to better understand the idea of knowledge lead me to Nyāya-sūtras (which further lead me to the work done by Matthew Dasti and Stephen Phillips, as well as Satishchandra Chatterjee.) which are believed to be the foundation of the modern theory of logic and epistemology.
As the knowledge workers try to obtain the knowledge, the means with which they obtain it makes a big difference. And the state of mind with which these efforts are made can lead one to obtain the correct knowledge or the false one.
According to Nyāya-sūtras, ordinary knowledge is considered to be true if our five senses can directly and clearly apprehend a reality. However, the knowledge work required to do skilled testing is intellectual in nature for most of the part. Which is where the state of mind plays a critical role. The mind is considered an internal sense and it can either lead one to correct or incorrect knowledge depending on how one includes, excludes, or integrates information.
Means of attaining valid knowledge according to Nyāya-sūtras are:
- Perception
- Inference
- Comparison and analogy
- Testimony and reliable sources
Skilled testing requires one to be skilled in the above-mentioned means and to be skilled in that, the state of one’s mind plays a very critical role.
Why? Because, pre-judgmental or prejudicial state of mind, can be a source of doubt or false knowledge. Based on the nature of knowledge work one does on a primary basis, these pre-judgements and prejudices are difficult to avoid. It is hard for me to imagine skilled testing without the involvement of a mind that is trained, experienced, and capable of separating false knowledge from the true one. And therefore, eliminating the mindset and its role in performing skilled testing is like extracting essential elements from whole-milk but still calling it milk because it looks similar.
Consciousness is the key
Considering the arguments I made above, does it mean programmers can/should not test at all? I do not think so. I am big time supporter of Whole Team Quality, and I think programmers can test if they want to, but rather than expecting them to fight against their cognitive dissonance (if they are expected to do more than writing asserts in the name of testing, that is) in order to test, I would expect them to write the program and work with the team to deliver software, with a quality-conscious mindset instead. And learning about testing can help facilitate that.
I do not mean that programmers are not quality-conscious when they write their code. But the notion and conation of quality in mind with which they work is not similar to the notion of quality testers work with. By being quality-consciousness with testing education as a tool, I am suggesting that they could have more aspects of product in their mind which usually mindful testers do e.g. broader product coverage, testability aspects and so on.
I have written more about Quality-conscious Software Delivery and how it has helped my team (and some others that I know) but that is beyond the scope of this blog. (However, I am doing a three-day workshop on it in case you are interested. More information here.)
The Cargo Cult
I do not know how credible this source is but when I tried to understand Microsoft Quality, this caught my attention and I believe it party still holds true :
MicrosoftCorporation aims for a different type of quality, GoodEnough software. Unfortunately, GoodEnough is defined as “the point where the market will marginally accept it”, because BugFreeDoesntSell/BugFreeCostsMore. Being the market leader allows MicrosoftCorporation to lower the quality the market will accept. Although MicrosoftCorporation may not have improved quality of software doing this, they may have improved the quality of their business practice.
The point is, what works best for Microsoft does not have to work better for others. My concern is with the Cargo cult we end up in. I have seen teams ending up nowhere by blindly trying to follow what they do at Microsoft or Facebook or Google without critically assessing their own context. And most of the time it happens at the cost of testing and quality, unfortunately.What is best for your context is best for your context, period.
I have met and interacted with Alan in person and I have great admiration for his work (even though I do not agree with everything of it). I only fear that his article mentioned above may encourage the Cargo cult that I deeply resent.
As a professional tester who firmly believes in the power of a mind for skilled testing, I felt compelled to pen down a considerate response.
Thank you for stopping by.
