​I am often asked why do I do what I do beyond my full time job. I could simply say it's my passion for software testing but I personally don't find that answer satisfying enough. It's hard to explain what exactly we get by doing certain things when we do it out of pure joy and satisfaction of simply doing it. But if I am to closely look at my journey with Association for Software Testing, I believe I have some answers to that. 

Back in 2011, when we launched Tea-time with Testers, I started getting in touch with passionate testers and experts from across the globe mainly to collaborate with them for articles or work together with them to practice testing. Interesting enough, there was one thing common between most of these passionate testers (who have made significant contribution to the field of software testing) which was their association with AST. Knowing this was convincing enough for me to checkout what AST was all about and what it has been doing. 

The member:

The fact that non-profit organisation for software testing like AST exists is itself a big relief. The purpose with which we started Tea-time with Testers and the mission and purpose of AST has some much in common. Knowing that back then was a great validation for me as a novice tester with passion for the craft of testing. The people connected with AST had already made big impression on me and there was no reason why I would not want to be part of it. Not only that but there are many benefits of being a member of AST which is why I did not have to think twice before signing up. 

BBST student and instructor:

And from there my journey with AST started. Being a member of this great organisation brought me much closer to the craft of testing, the advancements, the principles, practices and ideologies. Everything has been too fascinating and convincing to ignore even today. I participated in BBST course and I passed. Needless to mention the learning experience was worth it and it never hurt to revisit the course content once in a while. I have always learned something new from BBST each time I revisited. Apart from the course lessons, the most important part was learning from brilliant testers from across the globe who took the class with me. And the connections I made back then are still serving me to become great at testing or in efforts towards contributing to the craft. 

Later on I took BBST Instructor course and passed that too. Since then I have been teaching BBST classes with AST for once in a while. It makes me immensely proud when I see some bright minds, and star testers in the industry today who have shared their BBST journey with me. Some of them are my colleagues, some were fellow students, some of them have been co-instructors and some of them were students in the classes I taught. What more a passionate tester can ask for if he gets to experience this joy and happiness by giving back to the community in some way?

Volunteer:

AST is a gold-mine for number of projects aimed at taking craft of testing ahead and for advancing the understanding of the science and practice of software testing. If you are passionate about testing, you will never run out of programs and ways in which you can contribute to it via AST. SiGs (Special Interest Groups) that existed back then in AST caught my attention and I participated in some of them with whatever contribution I could make. 

​Then came the time to attend CAST, the conference by AST. I had only heard and seen it from far away how great this conference was and it had been my dream to be at CAST one day. Volunteering for CAST conference and helping the organisers with conference efforts helped me be there, in person. Yes, I got to attend the CAST-2014 in New York and that experience will stay with me forever. The atmosphere, the energy, the discussions, the talks, the format of conference itself... all of it was worth all the efforts I made. 

CAST conference has been the place where I got to meet many great testers in person, whom I had only known or interacted with via internet before. I have so many fond memories of meeting these people and getting a chance to confer with them, learn from them and get inspired from them. 

My association with AST only grew stronger over the years since there was no reason why would I stay away from such a happening group of great minds. And nobody can deny the role AST has played in advancing the software testing profession in more than many ways.  

Vice President of Education: 

To extend my contribution to AST and benefit the organisation with whatever little I felt capable of doing, I decided to run for the elections and got an opportunity to look after AST's Education program as VP, and I am currently serving my term. 

This has been challenging yet rewarding work and I am committed to give my best. 

​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.

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 :

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.  

Considering my experience and what I have been observing in the industry, there seems to be an increasing interest in the idea of Whole Team Quality. The idea itself is not new as far as I know but certainly, there seems to be more awareness and eagerness towards its implementation, lately. 

Why is it needed and how does it help? 

Well, if you are delivering a product as a team, it is natural that everyone who helps build the product is responsible for its quality, or is supposed to be. And for more on this I would urge you to read  another article from me on this topic. 

Where is the problem?

When I tried to figure out how different organisations and teams are going about Whole Team Quality, I realised that asking everyone in the team to test (or asking programmers to test) and automating as much as possible is what they consider Whole Team Quality to be.  

I see several problems with that approach:

1. The key problem in my opinion is confusing Testing with Quality
2. Putting most of the efforts to achieve/improve/assess quality focusing only on the product
3. Caring about quality way later in the process. 
4. Reactive strategy i.e. to address quality concerns and risks after they are found in a product (which is too late and costly to fix usually)
5. Over emphasise and reliance mostly on automated checks that do not discover hidden risks or find new information. These checks only assert the known information. 

Sure I do support the idea of Whole Team Testing to help achieve Whole Team Quality but  how do you go about it makes the big difference.

Over the last four years, I tried different ideas, did experiments in teams for succeeding with Whole Team Quality. I failed but I learned. I continued to try and eventually I would say I succeeded it in. Succeeded in achieving Whole Team Quality in a meaningful way. The way in which risks are found earlier (even before they manifest as a bug in the product) and the Quality is assessed/analysed/addressed/achieved on every level and by every individual in the team.

The solution that is working for us

Based on my experiments and learning, I would like to present the model and framework I have developed and am still experimenting with. It has given me and my team useful results so far and I would encourage you to try it too. 

 The model: QualiTri for three notions of Quality 

Having deep philosophical discussions with Michael Bolton when he peer-reviewed my paper on Whole Team Quality, helped me formulate/conceptualise QualiTri. And this model further guided me to create the framework for its implementation.  

Like I said before, focusing on the Product notion of the quality alone is not enough. To succeed with Whole Team Quality, it is equally important to understand Project and the People notion of quality. They are related and they do affect each other. That said, to deliver a quality product we got to be equally conscious about the project and the people notion of the quality. 

How to implement the 4E structure of QCSD can vary from context to context but below is how we implemented it in our team which has worked great for us so far. 

Going further in detail of the implementation of 4E structure for QCSD framework would require a series of blog posts. It starts with creating awareness, convincing your team for the need of it, considering their inputs, evaluating the project context and creating the workflows/action items together with your team, and then committing for the efforts needed. It's a process that takes time. Plus it is highly subjective from project teams to project teams and their contexts. And hence I would rather stop here for now.  

How do we know it worked?

The Lead Time graph for our team before and during an experimentation phase of QCSD in our team (based on the improvements we did in the processes, consciousness with which all people worked with and keeping quality of the product in mind) reflected the positive impact.

I believe it was the first sprint in a long time, where we as a team finished all the tickets and pulled more, the so-called testing bottle-neck was minimal and the bugs reported that would make into the backlog or warrant some critical rework post-production were negligible. 

Sure, this graph did not remain ideal all the time. Teams change, business contexts change too which affects the overall delivery and quality of the product we end up shipping. But if you know how to go about delivering a quality product by quality-conscious people using quality-empowering processes, I am almost certain you will do way more good than bad. And it's a win in my opinion. 

See if you find it worth the shot. If you would like to borrow my help for consulting/implementing this idea for your team or organisation, it would be my pleasure. Just let me know. ​