Author: TribalAdmin

Cignithon’21 – A QA hackathon like never before

It was time for the second edition of Cignithon – The Second edition of QA Hackathon organized by Cigniti & TTT and like everything else, this too was moved to a virtual setting. The first edition which happened in person saw high energy levels from everyone, participants, organisers, sponsors everyone.

All of us were albeit uncertain about how a virtual hackathon would go, but we were all taken for surprises. What happened, how it happened, all of this will be talked about in this blog post.

So just hold your horses and get ready to read an experience unlike never before.

What was in store?

  1. 400+ Registrations
  2. Three Products
    1. Retail
    2. Blockchain
    3. Technology
  3. 36 hours of testing
  4. INR 200000/- up for grabs
  5. One super-energetic host
  6. One amazing sponsor
  7. One reliable organising team

and,  Tons of Belongingness and Camaraderie.

And what happened?

  1. 2000+ bugs
  2. 21 Winners
  3. One message per every 4 seconds in the chat box in the opening event.
  4. Thousands of WoW moments

Also,  Testers’ celebrating each other’s success. 

Let’s walk the journey together

The resounding success of Cignithon, 1st Edition, made sure that the initial reception to the second edition was good. As soon as we made the event live and started to spread the word about it, registrations started and went on consistently.

While we estimated, about 200 registrations would be good, we ended up doing 350 before we stopped taking any more. Such was the craze of the event that we started getting calls to open it for some more time, relenting to the pressure we opened for 20 more minutes and within those 20 minutes, we saw 50 more registrations. That’s 5 registrations every 2 minutes. Doesn’t that speak volumes about the popularity of the event!!

The event day of QA Hackathon

How often do you see 300+ professionals turning up for an online event on a Saturday morning at 9:30 AM? Especially when the latest Money Heist season was just released and Friday nights are meant for Binging.

That was the turnout for Cignithon-21. It beat all estimates in Registrations, it beat all estimations in turnouts.

It was showtime now for our high on energy host, Paras (@TheCommunityGuy). He started with an innovative game to guess the sounds he would play. While a normal event will have sounds of Musical Instruments etc, this one has sounds of Ringtones, Water Flushing, Pan Frying, etc.

This fun event shot up the energy levels of everyone and it was time for the next speaker. Subhendu, VP-Marketing at Cigniti was the next speaker. Subhendu rightly said, “Cignithon is not just a hackathon, but a celebration for passion for testing”

After Subhendu, it was Mahesh Chikane’s turn. Mahesh is the founder of Test Tribe and a passionate tester himself. Having made several dents in the testing universe, the hackathon was one of the jewels in the crown. He explained the rules of the hackathon, 3 products, no time limit per product, how to submit bugs etc. He concluded by saying, “To my knowledge, this might be the biggest QA Hackathon the world has ever seen”.

Now was the time for which all the participants were waiting. It was time to reveals the products which these 300+ super enthusiastic QA Professionals were gearing up to test

The first app which was under test was – a 100% open source, using no-code,  automation testing tool for visual and functional regression testing on Prem or on cloud. The founder Ralf (//Insert LinkedIn) gave a heads up about the product and some dos and don’ts.

The second app which was to go under the lens of these amazing bunch of testers was Since this product’s domain was not so common, CEO, Mohit Madaan was patient to explain the product and other details very well.

They say, save the best for the last. While we don’t compare the products, the success and popularity of this product speaks for itself. The third and final product under test was Myntra. An app that needs no introduction, welcomed only WoWs from the participants.

With this, the HACK Began!!

This message from Ralf from summed up how the participants began this hackathon

initial reaction of qa hackathon
This is not hours after it began, this is just minutes after it began.

The very first hour saw about 200+ bugs being submitted even when was down for most of the time due to the sheer load it had to bear.

Every hour, we saw 100+ bugs being submitted by teams across apps eventually taking this to 2000+ bugs.

After 36 hours, spread over 2 days, with the TTT team supporting 24*7, buzzing Cignithon related discord channels, the testing got over at 5:10 PM (IST) (This time as well, we had to relent to the enthusiasm of our participants and extend this by 10 more minutes).

It was time for the product owners to do the toughest task. Read 100s of bugs and come out with the top 3. It looks easy, we are certain, it surely wasn’t as easy.

This message from Ralf (again) is a testimony of the effort and energy of the participants. This is more valuable than any prize for the testers

qa hackathon's feedback from founder

Listen to what Ralf (Founder, has to say about his experience at Cignithon

The winners were decided. It was time for Paras to be back again and do his magic in the closing ceremony.

Oh! Did we mention that before the closing ceremony, testers joined speed networking on Airmeet (the platform we used to stream this event). About 15% of the testers joined speed networking and 60% of them found the right matches for the networking.

Paras began by asking for feedback from participants. One of the participants, Manjunath, rightly summed this up, “I have been a part of a lot of developer hackathons, but this was the first QA Hackathon, I participated in. I felt, I belonged here

This was followed by a Thank you address from Raghuram Krovvidy – President and Head (Global Delivery) at Cigniti. Some excerpts from his address are in this tweetstorm

.And now the moment, everyone is waiting for. It was time to announce the Winners.


Winners: Team Believers (Rahul Parwal, Gaurav Khurana, Pooja Shah, Sahithya Reddy Kadapakonda)

1st Runners up: Team Tantei (Shobhana Satyanathan, Vishnupriya A Poduval, Rukmani Palaniappan, Shanmugam Sathappan)

2nd Runners up: Team Bug Hunters (Sai Dinesh, Krishna Kamakshi Brahma, Manikant P, Tejaswini K)


Winners: Team Avengers (Saket Agrawal, Navia Garg)

1st Runners up: Team Gangs of Wasseypur (PROS) (Sagar SK, Siri Murthy, K Balavardhan, Keerthana M Bharadwaj)

2nd Runners up: Team Out of the Box (Sheetal Tamta Kohli)


Winners: Team SuperQE (Manjunath BS, Vasista TVN, Randhir Bhagat)

1st Runners up: Team Fatal Four (Milind Kulkarni, Prashant Hegde, Gururaj Hiremath, Chaya Bhat)

2nd Runners up: Team Strikers (Pranav KS, Megha Pathak)

Selfie Contest

First: Rahul Parwal

Second: Mary Grace Mallari

Social Contest

First: Mahathee Dandibhotla

Second: Ram Kiran B

Saket Agrawal from the Team Avengers (Winners of Unifarm) shared his thoughts here.

With this, the event ended on a high. But it’s just this event that ended. The test tribe along with Cigniti will be back with more such events and we promise, the wait will not be this long this time. In the meantime, read this blog on cracking your next hackathon

Oh! By the way, did you register for TestFlix-2021 – The Annual Global Software Testing Binge

Tester’s day, 2021 – A heartfelt note to all the proud testers

Dear Testers,

Happy Tester’s day! 

First of all, a quick question, previous to the posts since morning, how many of us knew such a day even existed? But for some reason, it exists and we thought it’s a good time to reflect on ourselves, the Testers, and the amazing work we do.

Most, if not all of us, are accidental testers. testing was not our first choice profession, thanks to the little exposure we get in engineering colleges. The focus is always software development. Even when we picked up our first job as a Tester, within, we still wanted us to become developers, every sight of the code used to bring a glow in our eyes. We think let’s get a job first and then we will change functions. We look around when someone asks us, “You did not get a job in development?”.

Probably many of us looked down on our own self. 

But wasn’t it just a matter of time and till we figure out how beautiful our craft is?

After those initial days, we start to enjoy our craft. We meet fellow testers who guide us, mentor us, who tell us what testing is. We fall in love with analysis and detailing. We start to understand the value of our work. We start to value our work. We start to value ourselves.

Of course, we had to evolve, we are evolving and we will have to evolve in the future as well, every profession in this world has to evolve and we are no different. Today with communities around, sharing the vibe, reaching out to fellow testers, learning from them has become easy and accessible. We are living in a world filled with bonhomie and camaraderie.

Are we ready for the challenges the future will put in front of us? Well, Yes and No, but let’s keep challenges for some other day. Let today be about celebrating our craft, and ourselves.

This World Tester’s Day, celebrate your journey. Celebrate your journey of falling in love with testing. Celebrate your journey of probably looking down at yourself to valuing yourself immensely. This Tester’s Day, be proud of what you do. 

We at The Test Tribe, are proud of our community, we are proud of each one of you. As a token of respect for our Tribe and Testers around the world, we have designed this special badge on Testers’ Day. Claim your badge, show your PROUD side to the world.

Click this link to claim your badge:

Spread the word, ask your friends to claim theirs.

Testing is here to stay, testers are here to stay. 


Happy Testing!

The Test Tribe Team

Why everyone in Team does not align well in Problem Solving

Each of us has worked in a team to accomplish a particular team objective or solving a common problem, though it is in a leadership capacity or as an individual contributor. A very common thought to have during these times can be that, a particular team member:

  • Do not have the skills to work together in solving the problem for team or organization
  • Do not fit the nature of the team and organization
  • Do not fit the culture, mindset, and attitude of the team and organization
  • Do not understand the problem
  • Do not cooperate in working together as a team to solve the problem
  • Is on a different path while the others in the team are On another path

Ever wondered why this happens during the problem solving as a team?


Open up, Communicate, Unlearn and Learn

It is human nature to arrive at the above thoughts or perceptions, sooner or later. But before that, have you made enough attempts to talk with an open mind with that person?

Or, while you spoke with that colleague, did you see:

  • Do you both know what problem is to be solved?
  • Do you both mutually agree to the problem statement?
  • Do you both know what is expected from you both and the whole team?
  • Do you both see the goals and milestones set for each other in solving the problem?

If your answer to the above questions is a “Yes”, but still you see the other person is not assisting, not working as a team:

  • Does that person differ in ideologies, principles, and thought levels from the others in the team?
  • Does that person have the same pace and skills in solving the problem together like you or others in the team?

If “Yes” is your answer to the above questions,  then:

  • Have you communicated with clarity being a supportive and empathetic team member?
  • How was your communication with that team member?
  • Did you ask that person, did she/he understand and agree with your view? What did you hear?

If you have not done this, you as well have added more pain to the problem than solving the problem for you both, the team, and the organization.


Ideologies, Skills, Work Style and Principles are [NOT] Problems

If asked what is a problem, then simply put it is the difference between the expected and the actual.  The difference tells what’s the cost to the context of the problem identified and accepted.

The skills, ideologies, principles, and work style are not problems until it blocks or does not serve the problem being solved as a team or as an individual.  In my experience, I see, all these will evolve with time.  The individual will learn what is important and figure out if their ideologies and principles are more important, or the problem which we want to solve as a team is more important.

A skilled person will stay flexible enough with their ideologies, skills, work style, and principles to the context of work, and be one with the team. If she/he needs the skill to be developed, she/he will do it and work along with the team. I do this regularly.

Not all in the team are the same in terms of skills, ideologies, working style, problem-solving capabilities, and principles.  Yet all come together to work.  Most of the time this does not appear to us when we become conclusive or judgemental and categorize someone as unfit to team or organization.

People who want to work, they will adapt and evolve in a supportive and encouraging environment.

Having said that, how much luxury one has for creating such culture and the environment in a corporate world, that’s the question which changes the dimension of this problem. Culture change is not easy, but it is needed when change is a necessity. Culture changes when it is from top to bottom in the organization and when leadership leads by example, it brings the change for sure.

The Problem Solving Phase

In my experience of working with teams, I learn, when people come to work, they come together as a team to solve the problem.  A team working to solve the problems can have multiple teams within it.  Each team contributes its part to what constitutes the solution for a problem.

When I observed that another person is not understanding what I expect out of her/him in solving the problem together, I saw the difference in the phase in which we were in solving the problem. I was in the phase which is either ahead or behind to the phase in which the other person was.

Such a difference can lead to misunderstanding and confusion towards the end expectations.  

More often than not, we miss on the importance of solving this problem of ‘different people being in-different problem-solving phases‘ for the sake of timely delivery, at times, at the cost of team confidence and quality.

We almost consistently miss identifying this in our day-to-day work and life.  As a result, it creates more damage than healing.

For example, The VP or CxO is in another phase of seeing and solving the same problem (here the possibility of building the gap is more and this adds to the nourishment of the problem which we are solving as a team.)

Apart from this gap, the other factors like infrastructure, support, business, people, competition, time, etc., will open up new challenges and bring in another set of problems in addition to the one we are solving.

Me working at a desk on a problem may not see these fresh sets of problems which the VP or CxO see and as a result, now I might not respond well enough to VP’s/CxO’s thoughts about the problem and solution.

Why does this turn out to be a problem?

  • When there is a difference in what the manager, VP, and CxO think about the problem, and what I think, the perspectives are different and the gap is created.
  • When I’m not present in the problem-solving phase they are in, I will continue solving the problem in my phase
  • I will continue to think that I am doing my best and working with the team, while others in the team do not think so

Being in a different phase of problem-solving may create huge expectations vs reality debt. Add to this the delivery pressure and things can get very tricky.

By moving to the problem-solving phase in which others are, I can see what they are trying to do.

When I do this, I learn they are right and what they are doing is needed.  Likewise, when they move to my problem-solving phase and look at what I see for the problem, I will sound right and what I’m doing would look needed.

Both of us are right and doing what is needed in the phase where we are. But others who are not in the same problem-solving phase do not see me solving the problem.  The perception then builds that I’m not working as a team and I’m a different voice in a team.  Further, it creates barriers in interaction and communication, creates the space for difference in opinion, and for the unhealthy relationship at work as a team.  All leading to misunderstanding and atoxic atmosphere.

One has to go along and pull the others in a team to the same phase and sight of the problem so that new problems are not created.

People who have crossed this state and recognized it consciously in their work, communicate better to their teams when they get a hint of it.  By doing it, a leader will help her/his teams to see the problem’s dimension and work towards it as a team. Possible that not all people (and leaders) have experienced this situation consciously yet.. This article might serve as a heuristic in that case to catch the hint of this problem and its patterns being created.

So to summarise: 

  1. Understand in which phase of problem-solving you are
  2. Know what you see in the sight of the problem at your phase
  3. Understand in which phase the other person is
  4. Know what other person see in the sight of a problem at her/his phase
  5. Create an environment where you openly talk about this to your team
  6. Communicate the gap and see that it is mutually agreed
  7. Educate the team about the different phases in the problem learning and solving
  8. Have a model of problem-solving for your context which identifies these phases and sight of a problem seeing
  9. Share this model with your team
  10.  Know that each phase of problem-solving is important and may have its own distinct throughput
  11. This thought process should be injected into the culture. Culture has to be from top to root.


About the Author:problem solving phase ravisuriya Eshwara

Ravisuriya sees himself as a student of Software Testing and is a practicing Software Test Engineer from Bengaluru.  He is with a mindset “put me anywhere in the context of Software Development, I will test by learning the system and add value to the team”.  He looks at how to solve the problems related to Software Testing and Automation in the context of a project and helps himself and his team by solving it.

He tweets here @testingGarage and blogs at Testing Garage.

Pesticide Paradox in Test Automation

How Pesticide Paradox can impact Test Automation??

One of the attendee at a recent meetup I hosted(on behalf of MOT KL) asked this interesting question.

Even though I answered it, the time constraint didn’t let me elaborate enough. So let me start with an apology for that and this article is in return to that question, based on my understanding of the concept. I believe this article will help you to understand the concept & moreover gives some ideas on “How to keep our Tests relevant“.

Disclaimer: This article focuses more on Pesticide Paradox in Test Automation whereby accepting the fact that there are more paradoxes around Software testing.


For Starters, let’s understand/revisit what is a Pesticide Paradox?

Every method you use to prevent or find bugs leaves a residue of subtler bugs against which those methods are ineffectual – Boris Beizer on Pesticide Paradox

Corollary to this he also stated that: ‘Test suites wear out’ in the book “Software Testing Techniques

These definitions make us think and I do believe that some tests lose their power to find particular bugs over time. Some tests which were effective, efficient and revealing before, will get wear out because of the modifications made to the product by developers. And in an eco-system which has a better feedback loop, these test suites may wear out faster. Different conditions /situations demand changes in the way we approach them. If we use the same techniques over and over, the tests will no longer have a meaningful impact.

Pesticide Paradox is a metaphor! It’s true & false at the same time. The role of metaphor is to make us think – Michael Bolton

When does Pesticide Paradox in Software Testing happen?

  • When the same tests & test data is repeated
  • When the same test data is reused
  • When more iterations of the same test are executed and there is nothing new to be revealed by that particular test
  • When product code becomes resistant to the test code
  • When new defects are failed to be caught by existing tests and thereby released to production

Highly repeatable testing can actually minimize the chance of discovering all the important problems, for the same reason that stepping in someone else’s footprints minimizes the chance of being blown up by a land mine – James Bach

Pesticide paradox naturally has an effect on Test Automation as well. Let’s understand it better.

Pesticide Paradox in Test Automation

When we automate the checks, it is ideal to understand the application first. Digest what is being tested by the scripts, why is it failing or why is it not failing. If failing what should we do to fix it? We tend to have a cognitive bias called, IKEA effect which makes us more attached to the tests we create. As we add more automated checks, we start relying on those tests more. We keep running them frequently for regression cycle but sparingly conduct a review on the tests which is being executed. And we tend to believe that our tests/checks are good enough to identify all the issues… which is kind of wrong, right??

Let me explain with an example. Imagine there is a regression test suite with 100 test cases which is executed for all releases. In one of the releases, there were few enhancements and we were asked to test it. Since we have “Regression Test Suite” what we do is to execute it, to ensure the change is not impacting the existing areas.

If all the tests are passed, does it mean

  • there are no underlying bugs?
  • there are no new defects introduced by the enhancements?
  • we can confidently release the product?
  • there is no other area left off by regression test suite?

If you ask me, this can have two interpretations:

  1. Yes, provided we ensured proactively that the tests(logic/data/assertions) are modified accordingly to accommodate new enhancements.
  2. No, when we blindly trust our tests without analyzing the enhancement and its impact on the regression test suite.

In my opinion, the automated checks which we create are very narrow compared to the other broader aspects. Automation will always check for the things we intended. It helps to do our work in a smarter way but it’s not smart enough to improvise on itself.

The effectiveness of our Regression Suite as well decreases over a period of time as after several iterations, as developers become more careful to those hotspot areas and fix those bugs as early as possible. As a result, the count of bugs identified (in that area with the available tests) gets reduced. This may give us a (false?) feeling that release being shipped is of good quality.

Automation is a double-edged sword if not maintained properly.

Throughout my career, I have met people who believe automated checks once scripted are done forever! And they don’t require any modifications or maintenance. Really?

This is one of the misconceptions which we have for automation which has been given a “Silver Bullet” status by a considerable part of the Software industry.

Tests do not write, modify or maintain themselves. To make them serve their purpose, maintenance is inevitable. Test automation is a software development activity, which has the same problems & challenges as any other development activity. The more tests we intend to automate, the more would be the cost and time for creating and maintaining those.

Well, what can possibly bring us here?

  • It is practically impossible to test all the application scenarios which go back to the Catch-22 of software testing “Testing is potentially endless“.
  • The functionality of application changes over time.
  • We tend to cover what is known, what is changed and what is new, leaving the unknowns behind.
  • Getting comfortable, as we didn’t sense any danger from some part of the application.

How can we prevent or overcome Pesticide Paradox in Test Automation?

  • By writing a new test script to evaluate different parts
  • By changing/modifying test script and test data from time to time
  • By updating the techniques & methods used, with a sense of continuous improvement to make tests more effective
  • By constantly aligning yourself with the product changes
  • By constantly analyzing the bugs identified

Is this enough?

We talked about the IKEA effect before right. Let me tell you why I mentioned that. I was a person who likes to see the tests created by me gives a pass status during my initial days because I was more attached to those, and I believed my baby can never go wrong (which itself was wrong ? ).

Now if I see a test which keeps on passing over a few consecutive execution cycles, there will be an intuition in my mind rather than being happy.

Am I doing the right thing? Is there anything I missed? Or Is there anything to be modified?

I think this intuition helped me a lot to keep my tests relevant. But, indeed there are more ideas.

How to Keep our Automated Tests relevant?

  • Don’t assume that we have full coverage with our automated tests, there is always more.
  • Don’t be too formal, sometimes more bugs can be identified by informal ways
  • Peer reviews & sessions to understand more about the features and to get diversified opinions from a fresh perspective.
  • Believe that, Automated Tests can also have bugs.
  • Deleting the irrelevant tests and keep the code clean.
  • Think Outside the Box and add new scripts by changing the usual scripted flows & data
  • Add fuzzing and randomization to tests
  • Create tests which are more focussed on possible user interactions instead of following traditional test case based automation only
  • Think from several levels and different angles to get different perspectives
  • Test our Tests, quite often
  • Review & Verify test suits and scenarios regularly
  • Last but not the least: Step Back, Think Like a Tester, Frame the Test, then Develop the Test

Learn how to Defocus. Defocusing is the solution to the pesticide paradox. It means to continuously change your tests, your techniques, and even your test strategy – James Bach

To overcome the Pesticide Paradox in Test Automation firstly we should overcome the bias & misconceptions and start considering automation as software development. As the application evolves, we must be continuously willing to design new test cases & modify the existing ones. And maybe over time, we can adopt a model-based testing technique that allows us to reuse the test code to automatically test new scenarios and code changes.

All these can help to control the impact and avoid pesticide paradox in test automation, but there can be more things of course and this list alone may not help in all contexts. So feel free to think as per your context, and add more based on top of these ideas.

Revisit, Review, Revise & Reframe.

Ideate, Innovate & Iterate.



About the Author:Pesticide Paradox in Test Automation Nithin SS

Nithin is a passionate and enthusiastic QA professional with 6+ years of experience in the field of IT with a focus on Quality Assurance (Automation & Manual) of web & mobile-based applications. Currently attached with Fave, as Senior QA Automation Engineer driving their test automation journey. He is mainly involved in building robust test automation solutions from the ground up. Also, involved in Test & Release strategies to improve software delivery.

He enjoys sharing his learning and experiences through creative writing and loved to be known as a storyteller. An active member of various Software Testing communities and founder of Synapse-QA, a community-driven co-writing space for testers.


P.S.  If you also wish to write for The Test Tribe, You can know more Here-