This interview with Santhosh Tuppad is part of our series of “Testing Smarter with…” interviews. Our goal with these interviews is to highlight insights and experiences as told by many of the software testing field’s leading thinkers.

Santhosh Tuppad fell in love with computers when he was 12 and since then his love for computers has increased exponentially. He founded his first startup in 2010 and was part of growing the company to nearly 80 people.

In short, he is a passionate software tester, security researcher, entrepreneur and badass in following his heart come what may!

Santhosh Tuppad

This post includes highlights from our full interview with Santhosh Tuppad. The full interview is long and packed with great thoughts.

Personal Background

Hexawise: What drew you into a career in software testing?

Santhosh: I have loved computers since I was 12. My father enrolled me into a computer course and I got to experience Disk Operating System for the first time where I used computer using command-line terminal and also played Prince Of Persia game. And I was addicted to gaming during this phase.

After my gaming stint, I was introduced to the internet and picked up an addiction for IRC (Internet Relay Chat). Here, I met various hackers and used to communicate with them on various channels which were heavily moderated and were invite only. I had to demonstrate my interest in hacking to these folks to invite me to their channel. My first hack was to hack the dial-up network credentials and use them at my home when the internet shop used to close at night. We used to have Internet Packs at those times in India and I had to pay money to buy those: and I did not have money during my teenage years.

Without much ado, let’s skip to software testing part. After my graduation, I did not know what should I be doing (one thing I knew for sure was, anything that I do has to be with computers as I was passionate). I understood that, I cannot settle for anything which doesn’t synchronize with my heart. I was on the journey of finding which becomes part of me. And finally, I enrolled for the software testing course. And during the course days, I could connect my hacking skills (security testing) to software testing. This part of my life is what I call finding bliss.

And the story continued and I started growing in the industry as a tester, international speaker, participant in conferences across the globe, entrepreneur in software testing, keynote speaker, blogger, author and what not.

Hexawise: If you could write a letter and send it back in time to yourself when you were first getting into software testing, what advice would you include in it?


Oh my dear soul,

I see that you have found yourself in a country where everyone is pressurized to become something else than they want to be. You identified something crucial and beautiful about yourself, that is you follow your heart with patience and kindness and don’t settle for something that doesn’t make you come alive. Like I know, passion is a variable and it may get boring at times; but being bored is just a temporary phase and an emotion which doesn’t mean your passion is dead. So, be rational and decide for yourself while you are kind to others. Accept yourself and forgive everyone.

You are stepping into what you love and I know you are confident about your journey and you believe in it. That’s beautiful.

It may be easy to fall into routine and get into monotony of things in your career. Nevertheless, you know how to sail through things and get out of them to start fresh or continue in a different path. You can swiftly shift based on your visceral.

Grow by following your visceral feelings and have no regrets. Be good at connecting the dots and growing out of them. The beauty of software testing has not been known by the world so well as of today, so work on your skills and demonstrate them to the world and educate professionals and students about the greatness of software testing. It’s not about you or me or anyone, it’s about next generation testers who could help their next generation and their generation to enjoy the fruit of invention which includes software. Let software make the life beautiful and not buggy.

I know that you know about your journey, but I am just saying.

With love, Your other self

Wedding picture of Gina Enache and Santhosh Tuppad in the temple at Bengaluru, India

Hexawise: What kinds of activities do you enjoy when you’re not at work?

Santhosh: I love meditation forms; talking deeply with a friend sitting on my balcony of my apartment; watching documentaries of various types; and conversations about psychology, life and many other topics with my wife Gina Enache.

I feel that educating customers is the key and it takes more leaders to spread the greatness of exploratory testing style to the world through demonstration.

Views on Software Testing

Hexawise: What do you wish more developers, business analysts, and project managers understood about software testing?

Santhosh: I wish that developers, business analysts and project managers understood that it is not low-skilled job which anyone can do. And also wish more of them learned to collaborate across the teams in order achieve the common goal.

At the same time, I also feel that testers should upskill and demonstrate the value they provide in order to gain credibility from those on other teams. I also wish to see them spending time together instead of just seeing their role as limited. Last, but not least; manage conflicts and work as a team.

Hexawise: What challenges and advantages are there to managing an exploratory based, thinking software tester organization (as you designed Test Insane to be) compared to the still common "checking" style software testing organization.​



  • Not many customers understand how exploratory testing can be valuable. And it’s hard to educate them as well because most of them do not want to hear.
  • Hiring is a bigger problem. In my experience, I have trained new testers or made some testers to unlearn their testing way and I have been successful, but it’s hard to scale in my view in the current world.
  • Pricing is something that customers choose over the skills. It’s sad, but true. Most customers appear to be happy with “checking” style organization because their pricing is good for customers. Value based testing still needs to be understood by customers. However, I have been trying my best to talk about good testing (exploratory skilled testing/technical testing) to business owners at conferences I participate in or speak at.
  • Most of the testers have half-baked knowledge about exploratory testing and yet they call themselves exploratory testing experts. This makes it hard for context-driven leaders to see a scaleable model for exploratory testing. Thanks to Ministry of Testing community which is really spreading a great message to the testing world. I appreciate Rosie Sherry, Richard Bradshaw and every CDT member who are working on scaling it up and spreading the right message to the world.

I feel that educating customers is the key and it takes more leaders to spread the greatness of exploratory testing style to the world through demonstration.


  • Starting TestInsane (Exploratory Testing and Check Automation Services Company) has also enabled me to bring in a change and demonstrate to the world the worth of good testing and value-based testing that can be done through the exploratory testing style.
  • Experienced testers who joined TestInsane unlearned the checking style and learned exploratory style testing and they are leaders who spread their knowledge and also are happy with their profession.
  • Customers are happy when they see test coverage and have acknowledged that it helps them to make better informed decisions about shipping or not.
  • Recurring business from customers who saw the value
  • The sense of freedom with responsibilities that my team members have. And this is because they enjoy exploratory testing and they perform amazingly. Freedom has always been great, but it comes with challenges. And one of the challenge is constantly learning and adapting based on the context.

I recommend that organizations hire security specialists because you don’t want to just rely on checklist based testers unless they have mastered hacking and have practiced enough to create a mindset of hacker.

Hexawise: Do you believe security testing for software requires testers that specialize in security testing? Certainly some security testing can be incorporated by most software testers, but does the complexity and constantly evolving nature of software security mean that only specialists can provide sufficient security testing?

Santhosh: This is very context specific question. And I am glad that you mention “Certainly some security testing can be incorporated by most software testers” which is true. Most of the software testers can be “Survival Mode” security testers who follow the checklist or guidelines (The Script Kiddie I mean).

However, what the organization needs for better coverage and deeper security testing is a tester who can be an explorer and find security vulnerabilities like a black-hat hacker. I recommend organizations hire security specialists because you don’t want to just rely on checklist based testers unless they have mastered hacking and have practiced enough to create a mindset of hacker.

I believe strongly that we need better security testers who are not just certified by EC-Council (nowadays, anyone can get this certification), but are known for skills and can show it via demonstration. Even in today’s world, we need security specialists if we are serious about software security. Period.

My articles on various topics of security testing provide additional reading on security testing of software.

Industry Observations / Industry Trends

Hexawise: India is a worldwide center for software testing. What risks do you see to that business going forward? What can testers (or testing companies) in India do to protect their market and gain customers going forward?

Santhosh: In my opinion, I don’t see the risk at all in India for these reasons:

  • Overseas companies who outsource testing are happy with bad testing
  • Customers think automation solves testing problems just because they are blind to good testing and they think - "good testing is automation" - which is incorrect. Like I say, automation is a myth. Automation is just a Ferrari (faster), it doesn't solves testing problems by itself.
  • India has more manpower in terms of engineers. Now, this can be a boon or bane for individuals who were pressurised by society or parents to study engineering. However, India has more engineers and that means more manpower.
  • There is nothing that testers need to do until the customers understand the value of good testing which is value-based instead of running the N number of test cases and showcasing some decorated spreadsheets which speak about good/bad testing.
  • Companies are moving towards automation and artificial intelligence thinking it will solve their problems of testing. A big no. I believe that ideas are driven by the beautiful brain. And people believing the myth of AI and automation is not a risk as long as customers are loving them. In short, customers pay for this and people love to make money without educating the customer.
  • There can be a risk if and only if there is any other country which will gain the traction compared to India and maybe show what is good testing in a bigger proportion. And only then there may be a risk for Indian based companies.

Here are the risks for a tester anywhere around the globe if they fall into any categories mentioned below (not just India):

  • Falling into the phase of monotony and routine where there is no new learning.
  • Believing that, “If I stick to this company for long time, then I will have job security” (We do not know when things change in this rapidly changing and evolving industry).
  • Not getting to the depth of a problem and also not practicing thinking skills like lateral thinking, critical thinking, cognitive thinking etcetera.
  • Not spending money and time on credible conferences and workshops
  • Not adapting to the new learning and also being rigid by saying I cannot adapt.
  • Lack of passion. There is only survival with lack of passion. If a tester wants their work to be great and satisfying, passion is must. Or else they can only survive and not enjoy what they do. The solution to lack of passion problem could be, creating a passion for the profession by learning OR identifying a passion even if it’s any other profession (This is a context-based advice).

Hexawise: Have you seen a particularly effective process where the software testing team was integrated into the feedback from a deployed software application (getting feedback from users on problems, exploring issues the software noted as possible bugs...)? What was so effective about that instance?

Santhosh: The answer to this is available in this interview in the “Staying Current / Learning” section of the full interview.

The effective thing about that was, both developers and testers got access to the bugs that really matter. And once the fixes started rolling based on the feedback analyzer tool where feedback from users were being used in order to test better, there was improvement in terms of page views, time spent on page and also orders were checked out smoothly and quickly. The company started getting more orders (eCommerce platform) while they had great positive feedback and the when measured monthly feedback statistics, the negative feedback eventually reduced which spoke about “the effectiveness” of using the feedback from users and accommodating in the testing practice for better.

Working closely with programmers/developers is one of the beauties of an effective team. And Agile to me just means human values and these values have to be incorporated in the team. I believe there has to be great training in the companies/teams about conflict management, communication, motivation, solving problems etcetera in order to power up the teams to perform better and deliver better products to the world thereby helping the business move forward.

Staying Current / Learning

Hexawise: What do you look for when hiring software testers? What suggestions do you have for those looking to advance in their in software testing career?

Santhosh: In my experience, I have hired testers based on their attitude only. And some times, I have hired them only for their skills. I have had my own lessons and I have some checklist or guidelines that I follow in order to good testers with mixed ingredients of attitude. Well, the attitude is a tricky part because unlike WYSIWYG (what you see is what you get) editors, humans are not really WYSIWYG. It’s the perception during the interview that one carries about attitude. And attitude during the interview maybe based on best interest of the candidate to get hired. Most of the times it’s manipulation of the attitude which will fade away in months or days or years. I repeat, hiring is really a tricky situation and one can learn only through experiences and eventually grow with good hiring methods.

What do I look for based on my learning experiences in hiring?

  • Technical testing skills - My highest priority is for this. For example: If I am hiring for web application testing, I interview them concepts like web browser rendering engine, developer tools usage, tampering POST requests via Network tab, about HTTP headers and why are they important, depth knowledge about cookies, session management, their unique ideas to test web application and providing them with my own custom buggy web application that I have developed in order to analyse their skills hands-on and finally understand if a candidate can be a better fit for my team. (Note: This example is for a fresh candidate or someone who is 1 to 2 year experienced in web application testing). I would like to say that, I knew more about web browsers, sessions, cookies, tampering, hacking (thanks to my love for hacking when I was 16 and it’s been more than a decade being a security tester. Now, you know how passion is important if you want to do something great and well.
  • Attitude - This has been tricky for me and I am still learning how to hire based on attitude. Based on my experiments, I love to have discussions with the candidate and have transparency and also in the journey, speak like friends because those are the times the candidate opens up and feels comfortable.
  • Knowing the short-term plan of a candidate - Now, this is a checklist to see if I can have a good hire. Nevertheless, I need to see how a candidate performs in real environment once hired. In my experience, both these environments differ very well based on the context. It’s just like a web application or a software performance after being deployed to production/live environment.

Hexawise: What software testing-related books would you recommend should be on a tester’s bookshelf? What blogs would you recommend should be included in a software tester's RSS feed reader?

Santhosh: The first book I shall recommend is “Lessons learned in software testing” by James Bach, Bret Pettichord and Cem Kaner.

Here is the list of books that I love in testing,

  • Testing Computer Software by Cem Kaner
  • The Black Swan - By Nasim Taleb
  • General Systems Thinking by Jerry Weinberg
  • - Online Book by Robert Sabourin
  • Showing Up - Book by Olaf Lewitz and Christine Neidhardt
  • The Psychology of Software Testing - By John Stevenson
  • The Web Application Hacker's Handbook: Finding and Exploiting Security Flaws - By Dafydd Stuttard and Marcus Pinto (for security testing aspirants)
  • The design of everyday things - By Don Norman
  • And many more books. (follow me on twitter if you need any specific book suggestion as I cannot flood this post with so many books)

Blogs that I follow and recommend for a tester:

Hexawise: Have you incorporated a new testing idea into your testing practices in the last year? Will you continue using it? Why? / Why not?


The problem statement: When I was working at Tesco on a testing engagement, I happened to see that Tesco website had a feedback form with rating system, checkbox options and radio buttons which is used to collect feedback from its users. As part of my testing activity, I love to speak to cross-functional teams in an organization and extract the information that can help me test better.

So, looking at the feedback forms I wanted to know how is this feedback processed by the test team in order to improvise their testing by learning from users feedback. I approached the Test Manager and asked him, “Hey! Are we looking into the feedback from users so that we can improve our testing practices?” to which his response was, “Santhosh, that’s a very good question I hear for the first time and sadly we do not use it because there are thousands of feedback responses and we are confused on what to focus on. Only our customer support looks into it to address the issues and we don’t really use the feedback system to learn and better our testing”.

The Solution: In a week’s time, I along with my friend developed a feedback analysis system (a web based application) which could consume the feedback in a *.txt format and then reveal the feedback in organized and intelligent way. Basically, the application we developed sorted the information in a readable format and categorized the feedback.

The surprising factor was, developers also started to use the tool as they cared about the quality of their code. This was an amazing success of how cross-functional teams can work together and develop something to achieve a desired common goal.

Since then, I personally work on developing such tools along with my programmer friends in order to do better testing. This phase I call as, “Success by collaboration and being creative”.

See the full interview for screenshots of the tool they developed and more information.


Gina Enache (my wife) and I in Germany

Santhosh Tuppad fell in love with computers when he was 12 and since then his love for computers has increased exponentially. After his graduation (Santhosh puts it this way, “Somehow, I graduated” J), he worked as software tester in one of the organization in India and he quit because he was bored with the work he was doing. After that, he started his first startup in 2010 and was part of growing the company to nearly 80 people. Alas! He got bored again in his first startup and also he was not happy. He made a choice to quit and started his second startup. He is going to start his next startup soon. He says, “Getting bored is a sign of something new to be started and it excites me”.

In short, he is a passionate software tester, security researcher (Started as unethical hacker and transformed to ethical hacker for good), entrepreneur and badass in following his heart / visceral come what may!

Social Media Contacts: Twitter: @santhoshst

LinkedIn: Santhosh Tuppad

Facebook: santhosh.tuppad

Skype: santhosh.s.tuppad

Related: Testing Smarter with James Bach - Testing Smarter with Ajay Balamurugadas - Testing Smarter with Alan Page

By: John Hunter on Sep 25, 2017

Categories: Career, Exploratory Testing, Interview, Testing Smarter with...

Justin posted this to the Hexawise Twitter feed


It sparked some interesting and sometimes humorous discussion.


The parallels to software testing are easy to see. In order to learn useful information we need to understand what the purpose of the visit to the cave is (or what we are seeking to learn in software testing). Normally the most insight can be gained by adjusting what you seek to learn based on what you find. As George Box said

Always remember the process of discovery is iterative. The results of each stage of investigation generating new questions to answered during the next.

Some "software testing" amounts to software checking or confirming that a specific known result is as we expect. This is important for confirming that the software continues to work as expected as we make changes to the code (due to the complexity of software unintended consequences of changes could lead to problems if we didn't check). This can, as described in the tweet, take a form such as 0:00 Step 1- Turn on flashlight with pre-determined steps all the way to 4:59 Step N- Exit But checking is only a portion of what needs to be done. Exploratory testing relies on the brain, experience and insight of a software tester to learn about the state of the software; exploratory testing seeks to go beyond what pre-defined checking can illuminate. In order to explore you need to understand the aim of the mission (what is important to learn) and you need to be flexible as you learn to adjust based on your understanding of the mission and the details you learn as you take your journey through the cave or through the software. Exploratory software testing will begin with ideas of what areas you wish to gain an understanding of, but it will provide quite a bit of flexibility for the path that learning takes. The explorer will adjust based on what they learn and may well find themselves following paths they had not thought of prior to starting their exploration.


Related: Maximizing Software Tester Value by Letting Them Spend More Time Thinking - Rapid Software Testing Overview - Software Testers Are Test Pilots - What is Exploratory Testing? by James Bach

By: John Hunter on Apr 8, 2014

Categories: Exploratory Testing, Scripted Software Testing, Software Testing, Testing Checklists



Elisabeth Hendrickson's new book, Explore It!, will begin shipping from Amazon in a week. If you're interested in software testing, I highly recommend it without reservation. It's outstanding. It is currently available for sale on Prag Prog and for pre-order on Amazon. The paper version will be published on January 22nd. Since Amazon apparently doesn't allow people to review books until they officially go on sale, I can't yet post my review on Amazon, but here, one week early, is my glowing review:

Explore It! is one of the very best software testing books ever written. It is packed with great ideas and Elisabeth Hendrickson's writing style makes it very enjoyable to read. Elisabeth Hendrickson has a well-deserved global reputation in the software testing community as someone who has the enviable ability to clearly communicate highly-practical, well-thought-out ideas. Tens of thousands of software testers who have already read her "Test Heuristics Cheat Sheet" no doubt already appreciate her uncanny ability to clearly convey an impressive number of actionable ideas with a minimal use of ink and paper. A pdf download of the cheat sheet is available here. If you're impressed by how much useful stuff Hendrickson can pack into one double-sided sheet of paper, you should see what she can do with 160 pages.

Testers at all levels of experience will benefit from this book. Like the best TED talks, Explore It! contains advanced ideas, yet those ideas are presented in way that is both interesting and accessible to a broad audience. Beginning testers will benefit from learning about the fundamentals of Exploratory Testing (an important and incredibly useful approach to software testing that is increasingly getting the respect it deserves). Experienced testers will benefit from practical insights, frameworks for thinking about challenges that bedevil all of us, and Hendrickson's unmatched ability to clearly explain important aspects of testing (including her superb explanations of test design principles).

Chapter 4 "Find Interesting Variations" in itself is worth far more than the price of the book. It is my favorite chapter in any software testing book I have ever read. A large part of the reason I have so much appreciation for this chapter is that I have personally been teaching software testers how to create interesting variations in their testing efforts for the last six years and know from experience that it can be a challenging topic to explain. I was excited to see how thoroughly Hendrickson covered this important topic because relatively few software testing books address it. I was humbled by how effortlessly Hendrickson seemed to make this complex topic easy to understand.

Buy it. You won't regret it. I'm buying multiple copies to give to developers and testers at my company as well as multiple copies to give to our clients.

  • Justin Hunter

By: Justin Hunter on Jan 15, 2013

Categories: Book Review, Exploratory Testing, Software Testing, Testing Checklists, Testing Strategies, Training

A combinatorial explosion is when the configuration settings and user actions and data entered etc. makes it impossible to test everything. The number of tests required to individually test every single possibility is many thousands of times greater than could realistically be tested.

When faced with taking over an existing software applications without a good test suite (or any test plan) often is daunting. And the problems of creating an unfathomable number of tests face you due to combinatorial explosion. Hexawise is a software as a service that aids in dealing with this dilemma for software testers. Software test plans are created that provide far better coverage than is seen in practice with a tiny fraction of the test required for complete combinatorial coverage (that is testing every possible combination [pairwise or 3, 4, 5... way] individually).

The Google Maps test plan provides a good example of combinatorial explosion faced by the testers (in this case, those who tested Google Maps). Take a look at the Google Maps test plan by login to your Hexawise account (creating a demo account is free and simple). The Google Maps test plan is one of 9 samples currently provided in Hexawise.

For creating your own test plan, while you are exploring the software application and testing it out to find "where the weak points are," you will probably find it useful to vary things as much as possible, repeat your actions as little as possible. Those points are true whether you're doing relatively informal lightly documented exploratory testing or more heavily documented test scripts. It addition, since a large percentage of defects can be triggered by the interaction of just two test inputs, it would be nice, if you had time, to test every single possible combination involving two test inputs; that's the rationale behind allpairs, pairwise and orthogonal array-based test case prioritization methods.

To recreate a similar - very early draft - plan for yourself, I'd suggest going through the following steps to put together a relatively small number of highly informative end-to-end-ish tests:

Ask what can change as users go through the system? Think about configuration settings, user actions, data formats, data ranges, etc. even throw in more "creative" ideas like user personas. Let your creativity and common sense guide you. Enter those in as parameters.

Ask how those parameters can change? (for the parameter "Browser" enter IE7, IE8, FF, etc.) Put those in as values under each parameter (entering constraints as required)

Ask does that variation matter? When possible (when it doesn't matter as much) use equivalence classes and be biased towards fewer values - at least for your early draft tests.

Ask what special paths thorough the system do you want to be sure to include? (Most common happy path, paths to trigger certain business rules, etc.)

Click the Create Tests button in Hexawise and you'll instantly get a very nice draft starter set of highly varied tests. If they look like they're relatively interesting and don't miss hugely important things, start informally executing them and you'll be sure to learn some more things as you do about the system's weak points that would result in you going back to those draft tests and iterating them to make them stronger and cover more.

To get a bit more on using this approach see our case studies. Hexawise TV provides narrated videos online showing how to make your life easier as a software tester.


Related: Hexawise Tip: Using Value Expansions and Value Pairs to Handle Dependent Values - 3 Strategies to Maximize Effectiveness of Your Tests - Pairwise and Combinatorial Software Testing in Agile Projects

By: John Hunter and Justin Hunter on Jan 2, 2013

Categories: Combinatorial Software Testing, Exploratory Testing, Multi-variate Testing, Pairwise Software Testing, Software Testing, Testing Strategies