The more I think about events and people around me, the more I have started to believe in higher calling and celestial hints. I have been wanting to write about Jerry and as I started to pen my heart down finally, I learned that it’s Jerry’s birthday today. Could that be a coincidence?
 
Happy birthday Jerry! This time, accept it with tears in my eyes and lots of gratitude.
 
2018 has been a year of losses and realisations for me. I lost people that I once held close to my heart and spirit, I lost opportunities that could have helped me contribute better to the community. But the realisation that has come after these losses has been an eye opening experience.    
 
One of such persons that was very close to my heart from years, that I lost this year has been Jerry Weinberg. Yes, The Jerry Weinberg.
 
It’s been almost four months now and I am still finding it hard to believe that Jerry is no longer there with us in this world, in his physical form.  After Jerry’s demise, a lot of my friends and colleagues have written about his  impact on their lives and how he helped them transform their lives. Reading that all has made me feel even more emotional. The realisation of being close to someone for years, who has transformed many lives in many ways, makes me feel so very special and sad at the same time.
 
I really don’t know if anyone else has received so much from Jerry, as much as I feel I have received from him. But I consider myself truly fortunate for him coming in my life and transforming me bit by bit, month by month and year by year into a better person and software professional.
 
I still remember the day when I wrote Jerry asking for his permission to publish one of his article in Tea-time with Testers’ earlier edition. It was February of 2011 when I wrote him for the first time. I shared our first issue with Jerry so that he could make a decision about his contribution.
 
To my surprise, Jerry admired the work we had done with our first edition and happily agreed to contribute his work. ‘Testing without Testing’ was his first article that we published.
 
Jerry liked our project for multiple reasons. He admired our will to make meaningful contribution to software testing community, the efforts we were taking by collaborating with many testing experts in the world and the value that he saw we were creating with this project. Moreover, Jerry liked that we mentioned  our ‘team’ as our ‘family’ and when he said he would love to be part of it, my joy had no bounds.
 
And since then, Jerry Weinberg became part of Tea-time with Testers family. We felt like we got an angel to guide us in times to come. And Jerry proved every bit of that feeling to be true.
 
I have lost the count of how many times we communicated with other, over these seven years. But each time, I communicated with Jerry, my respect, admiration and love for him grew more and more. With each issue we published, Jerry gave us feedback and helped us become better and better. His feedback around my editorial that sited Kipling’s ‘If you can….’,  is still fresh in my mind. He told me that had that poem hung on his wall for quite some years of his life. Don’t know why but I felt more connected with Jerry after that.
 
Our collaboration brought me very close to Jerry and I never had to think twice asking for his opinion and support in different initiatives we took over years. State of Testing survey has been one of such project where we closely worked with Jerry. The webinar we did with him and Fiona Charles after that is still fresh in my memories. To check if everything is fine before the webinar, I made Jerry a phone call and that was for the first time, I got to hear his voice. Firm, but it had warmth of its own kind. Darn, just felt like I heard him again. And I have goosebumps on my hand as I am writing this further.
 
Interesting part of my exchanges with Jerry has been that, once in a while, along with professional work that we were doing together, he shared about himself, his choices, his likes, anecdotes, his take on things happening around and of course his advice on variety of topics we discussed. It never felt like I had not met Jerry in person. There was different pleasure in getting to know him on personal level, bit by bit… as if I was reading story he was writing about himself and there were so many interesting chapters waiting to be shared. I kept wanting for more and Jerry never disappointed me there.
 
We used to talk about dogs sometimes, German Shepherds especially. The dog breed I suppose Jerry liked the most and me too. He once gave me pleasant surprise by adding picture of me and Victor in his Pinterest collection around GSDs. It’s wonderful collection. Don’t forget to checkout if you are GSD fan like both of us.
 
I think I can keep writing about Jerry that I got know for days to come. Through our personal collaboration and amazing books Jerry has written, he stays with me every now and then. Sometimes when I get stuck on some concept from his book, I feel like writing him an email and there he will be, explaining me things in a way I will never forget. I wish I could do that forever. This realisation is hard. Feels like I am waking up from some dream, for it never happened that I emailed Jerry and he did not reply.
 
Meeting Jerry in person was on my list of ‘things to do at-least once in a life’.  We were planning to meet in person this year. Every time in past when Jerry wrote me that he was keeping unwell or he had doctor’s visit planned, my heart used to beat faster. And then he used to make me very happy again telling he was doing good and there was nothing to worry so much.
 
It was bit different this year. I had my flights booked to meet him June and Jerry suggested that I don’t make any reservations for he was unsure if he would be around by then. I did not know what say and even how to respond to that. I cancelled my flight tickets for I never disobeyed Jerry. Not sure why but with that particular exchange, Jerry left an everlasting impression on me. In Hinduism, we have this belief that great people can know of their time to leave the earth, well in advance. I think Jerry was one of such great persons.
 
His outlook and acceptance towards all phases of life made me feel awaken and enlightened. My that exchange with Jerry made a very positive spiritual impact on me.

I admit, I am yet to meet someone like Jerry who has been so brave and open about all possibilities of life, including the time to say good bye. I’m yet to meet someone so legendary yet so down to earth, someone who can explain mysteries of galaxy as simply and effortlessly as if it is nursery rhyme meant for kids, someone so generous and kind and someone who has transformed lives without even meeting people in person.
 
I wish I could meet you at least once in my life, Jerry. But not getting to meet you physically makes me firmly believe that you were an angel sent for many of us from heavens. You have touched me and transformed me in many ways and have made me realise my true potential. Moreover, your belief in my abilities and guidance you offered me over years, has made me feel so proud and special about myself. You taught me the power of compassion, you taught me how to stay unaffected by situations beyond our control, you taught me the importance of paying it forward. All through your life you have led us all by your example. I wish I could ask you what did you see in me that made you invest in me. But for whatever reasons you chose me, I will be grateful to you for that forever. And I will try my best to ‘pay it forward’.
 
Good bye and happy birthday once again, legend!  

​Disclaimer: Purpose of this blog is not to undermine the importance of automation skills for testers but rather to highlight the lack of awareness in our industry for tester's usefulness in teams beyond typical testing and automation tasks. 

​Recently, I was invited to conduct a workshop around "Whole Team Testing" at Test Leadership Congress in New York. Participating in this conference has been a great experience, especially because I truly believe in the need for conferences dedicated to test leadership and career path for testers in changing era. 

The discussions I had there with fellow testers, managers and directors of engineering/testing were interesting. Well, not only interesting but insightful and with lots of ideas, concerns, observations to ponder upon. Out of the things we discussed, what held my attention the most was the growing concern of evaluation of testers in Agile teams. The evaluation can be for hiring or for their overall performance in team. 

What is the problem exactly?

If you analyse the trend from State of Testing report, it is evident that with increasing Agile adoption, centralised testing units are mostly getting dissolved and testers are now reporting to Dev/Team leads. With this change of structure, hiring new testers and evaluating those in teams naturally becomes the responsibility of the Dev/Team leads. And this is where things start to get interesting. How? Let's take a look:
​

1. Dev leads are usually excellent programers with high passion and inclination towards typical programer mindset. And this is very natural. 
2. Neither all of the leads come with prior experience of hands-on testing nor all are well versed with testing mindset and philosophy which is key differentiator between  testers and programmers. The way programming excellence comes with deep understanding of programming concepts and ample hands-on experience of coding, it is quite natural that in order to understand testing better (so as to evaluate people for testing skills) one has to have equivalent expertise or at-least deep understanding of the subject. And this is something our industry is still lacking, unfortunately. 
3. But despite of this all, teams still need testers and they must be hired and evaluated. What happens in such situations? Testers get evaluated based on the scale and criteria, that hiring managers (programmers at heart) are most comfortable with.  Yes, read that as automation and programming skills. This is quite natural, mostly happens unconsciously and I won't blame it on them entirely.

But this situation is dragging us into bigger problem. We are giving too much importance to things that are just a part of big scheme of things that matter and contribute to software quality and teams' overall ability to ship quality software, faster and frequently. 

Of course automation skills and other technical skills are helpful, rather important I would say. But that has become a norm now and what we really need at this point of time are tools to see beyond this norm. If we want excellent testers in team who can really add value to software quality, it's high time that hiring managers come out of their obsession of hiring testers based on the norms that they can most comfortably evaluate. Please, it is not about what we are most comfortable with but what Agile team really needs from a tester to ship a quality software. 

Heavy emphasis on technical skills for testers is not my big concern, but lack of awareness around other things that testers must get evaluated against, concerns me the most.  Purpose of this article is to highlight some of those areas (beyond typical technical skills) that I think managers/leads may want to consider while hiring new tester or evaluating those in their teams. 

Why do we need testers at first place?

One may argue that in an era of AI and advanced automation where every check can be easily automated, why do we need human testers at all? That's interesting argument  and before I explain why we are talking about it,  I want you to have a look over the diagram below:

The diagram represents a system that we as a team operate into. I created it based on my experience as a tester so far and by interviewing some programmers I have closely worked with. 

Looking at bunch of things mentioned there, you can figure out what all can happen (rather typically happens) when tester in team is not available. If you read the diagram carefully, you will notice that impact on finding and reporting bugs is just one segment that gets highlighted when tester is missing in team. Impact on writing new tests or automating them is another segment. But is that all you need testers for in a team? Certainly not!

The purpose of having testers in team is way beyond finding bugs, writing tests or automated scripts for that matter.    If utilised to their full potential, testers in team can very well serve as a mode to protect your system from running into collapse or explosion mode (please read more about that in "How Software is Built" by Jerry Weinberg). How? It's simple. By providing system related feedback to the controller which is typically team lead or test manager in typical team set-up. The better you utilise tester for their abilities the better feedback you get from them which in turn can help you command better control over your system and protect it from collapse/explosion.  You need tester in team to provide you with information that you as a stakeholder can use for making better decisions.

And when I say feedback, it can be anything from information about bugs, risks highlighting, asking context revealing questions, questioning user stories or decisions made, finding out historical data, highlighting third-party dependancies, sharing news about decisions made by cross functional teams, collaborating with other disciplines to create valuable assets, their observation around team dynamics, their predictions about possible failures and so on. And if you are lucky, they can also tell you some great things about quality of your product.  

The point is, tester in your team can add far more value beyond finding bugs, if you allow them to contribute beyond their typical role. If not, you can always empower them to do so. Here are couple of things that in my experience testers can contribute to and against which you could evaluate them (for hiring or performance reviews etc):

1. Primary analyser of production logs and alerts 

Production deployments are typically done by programmers who then closely follow the logs to see if there are any obvious issues created by latest build. Consider handing over this responsibility to testers. It is likely to serve multiple purpose:

• Time spent on back and forth of sending build for testing and deployment can be greatly reduced. Once tester is done with their testing, they can directly promote the build for deployment. 
• Participating in deployment process can help tester understand underlying infrastructure and can offer better technical overview of how those dependancies can affect end to end testing and delivery of your product. This understanding can also help them better analyse the logs and use those for technical investigation of observations made. 
• Over the period of time when enough insights are acquired, using their sharp observation skills, familiarity with known issues and ability to quickly analyse the gaps, testers can help identify root cause of problems, functional and business impact  as they read the logs and draw inferences from those. 
• Using the failures and errors via production logs, testers can derive more tests for future and also identify risk areas that were hidden until given point of time. 
• Participating in production deployments and monitoring can certainly foster better collaboration and pairing between programmer and testers which has benefits of its own. 

2. Enhancers of your product's coverage for quality

It has very little value if tester in your team just sticks with usual acceptance criteria for the ticket and automates the stuff for you to top it. The real value a skilled tester can add is when they question the very product coverage you have in place and help your team see elements of product that matter from quality aspects.

A lot of elements matter when it comes to your product's quality. Functional acceptance criteria is just tiny part of it. A skilled tester would know about these elements and they would educate the team about same.  

Check out SFDIPOT from HTSM by James Bach or simply have a look on mindmap below (thanks to Albert Gareev)

3. Advocates for Testability 

Testability is one of the key area I would expect skilled tester in my team to help programmers and designers get it right.  A skilled tester would know what makes product testable, how to evaluate it for testability and also advocate the team as in where and how they can improve it. Nothing beats the pleasure of testing better testable product. 

Here is a heuristic for testability if that makes you curious. Out of various types of testability mentioned there, I would expect the tester to at-least know Intrinsic Testability and how to help their team improve it. 

4. Better allies for UX peeps 

Ever wondered what would happen if System Thinking meets Design Thinking? I firmly believe that challenges faced by testers and UX professionals are more or less same when it comes to ensuring better quality and better user experience. 

A regular and close exchange between these two disciplines has tremendous potential to create a better user experience with enhanced product quality which I would call as "Quality Experience". If UX designer comes with one best solution for some product problem, a skilled tester with their insights, product knowledge, awareness around cross-functional dependancies can point out variety of ways in which it may fail. This does not mean a tester has to criticise UX solutions as such but early collaboration and exchange between two can help avoid lots of unnecessary research and rework. 

On other hand, testers can borrow realistic information from UX's research which can help them design tests that matter and prevent themselves from straying into unwanted scope. Testers can borrow statistical data or interaction/persona based information from UX that can help them shape better scope for their tests. Well, this is indeed interesting topic and deserves deep dive. I will stop here on this one for now. 

A skilled tester would make this collaboration happen and would bring out the best from both the worlds. 

5. Friend in need for marketing and user care 

This is another area of collaboration where skilled testers can add great value to solve team's problems beyond finding bugs. I have listed some of the possibilities where testers can help user care and get benefited in return and I believe same applies to their collaboration with marketing teams:

6. Alert mechanism when system is on the verge of collapse

Well, this is bit tricky but I would mention it anyway. By nature of their work, skilled testers can use their sharp observation skills to observe and understand people, situations and events around them and can draw inferences that can help identify potential risks, before it is too late. Retrospective meeting is a great place for skilled tester to raise flags for potential issues surrounding team dynamics or people issues they observed, in constructive way of course which is where their communication skills can come handy. 

Testers are usually in touch with fellow testers in organisation from where they get information around what other teams are working on, their future plans, blocking issues etc and this information can be very well used to analyse the impact on their respective team's road-map , work in progress or work items that share dependancies with other teams. 

A tester who is skilled enough to foster network and relations across teams, can certainly help bypass blockages when team needs it most. 
​
So, those are some aspects in my opinion and experience, a skilled tester can contribute value to project team beyond their traditional tasks. 

If you are to a hire new tester or would like to fairly evaluate/mentor tester in your team, I would suggest give these ideas some consideration. It's high time that we look at tester as someone beyond bug finder. They can do wonders for your team and can help to accelerate shipping of quality product, if allowed to use their full potential.

​I shared what I think can be helpful. Feel free to chip in your ideas ....