Author: TribalAdmin

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?

Pesticide paradox principle of testing goes something like this…

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 paradox of automation. 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.

https://www.linkedin.com/in/nithin-ss

 

P.S.  If you also wish to write for The Test Tribe, You can know more Here- https://www.thetesttribe.com/speak-for-tribe/

Blog
01
Tester’s Day, 2023 – A Heartfelt Note to All The Proud Testers

A very Happy Tester’s Day to everyone. Sharing our best wishes to the whole community on this eventful day.

A 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: https://bit.ly/BeAProudTester

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

About Software Tester’s Day

Let’s know some interesting facts on this beautiful day where we celebrate the software tester’s from all over the globe.

When Is International Tester’s Day Celebrated?

The international software tester’s day is celebrated on the 9th of September every year.

The First Ever Global Software Tester’s Day

The first ever software tester’s day is said to be celebrated back in the year 1947. It is believed that this day marks the first ever bug found on a computer.

Who Coined the Term Bug?

Dr. Grace Hopper reported the actual case of a bug being found back on 9 Sep, 1947. This happened when a Harvard Team found an actual moth trapped in one of their machines causing a glitch on their computers. Interesting, isn’t it?

Hopper’s Diary and the Bug

The same moth that was found in one of the machines leading to the use of term ‘bugs’ in computers today, was pasted in Hopper’s diary with a tape. You’ll often find the pictures of this diary on posted social media on software tester’s day.

Meet the best testing minds on this tester’s day. Join our discord community and connect with the people who live and breathe testing. We wish you the best in your software testing journey. 🙂 – Team Test tribe 

Blog
01
6 Tips on Starting a New Job – What to do in the first few days of the job

A lot of people want to quit their current jobs (out of any reason best known to them) and move on to a new one. At the same time, those lot of people end up not changing their jobs because of unwillingness to leave their current comfort zone.

Indeed changing jobs is discomforting. Establishing a good repute at a new place is arduous and needs a proactive effort from the new joiner to create a good one. 

In this blog, we are giving you Tips on “Starting a New Job” and what you can do in the first few weeks as a new joiner in the company:

Induct yourself well

Most companies will have a formal induction process. Even if it sounds boring to you, It is highly recommended to attend the induction with full involvement and know that the company you are joining is its about. Sure we do a lot of research before joining, but you will directly get the information first hand in the induction process. Also, it is a great chance to interact with people from HR, Admin, Finance teams etc.

You should also make the best chance of the team introductions which your reporting manager will do in your first few days where he/she introduces you to every member of the team. Making notes as to know who is doing what is not a bad idea either and in fact, strongly suggested.

Formalize your onboarding

It is extremely important to understand what are the expectations from you in the first 4-6 weeks. While some companies may have a formal onboarding doc , some might not have. In that case, you can make your onboarding doc yourself by collecting all information has been already provided to you and discussing openly with your reporting manager as to what is his/her expectations from you.

This will help you in more than one way a) This will help you get quick wins once you achieve weekly targets in the initial weeks which will be a huge morale boost b) This will also set you right in the eyes of your manager and other senior people.

Make notes. More than you ever did

It is in general a great habit to make more notes but the importance of note making is all the important in the first few weeks of a new job. Again, notes making in the first few solves a wide range of purposes a) It shows your intent and seriousness in meetings or discussions b)The initial few weeks are loaded with information, it helps you to collect them and go back at them as and when you need.

Overall, it puts you in a better and more controlled place in the information carnage of the first few weeks. However, be cautious, it is better to understand what is happening before suggesting anything new.

Network

Networking, again, is not something which you should do regularly and not only at the time of a new job. However, doing it with an extra push in the first few weeks of a new job puts in you a better place in terms of understanding who is doing what and why is he doing a particular thing. Talking to people from your team and cross-functional teams opens your doors about the company, the project you are working on which helps you to fit the piece of your task as a puzzle piece in the overall puzzle.

Ping members of your team or other cross functional teams with whom you work to introduce yourself in detail and understand from them their work. More often than not you may be able to find commonalities between both of you. 

Here are some of the things you can ask:

  1. How can I help you in your work or possible collaborations?
  2. What would be your advice for me?
  3. How things work here?

You can start a conversation using this template (feel free to use your own as well)

Hey <Name>, Hope you are well. I am <>, I joined about <> weeks back. I wanted to connect with you to understand how can I help you and your teams?

Bonus tip: For Video calls, it is always better to turn the video on. People might not get a good impression talking to a black screen.

Volunteer

Volunteering is one of the most under rated ways of building an initial rapport in a new organization. You can volunteer for any HR Event as your team rep, you can volunteer to be a part of the hiring process, you can volunteer for any CSR activity to name a few events where you can volunteer.

Find a mentor or a buddy

While most companies these days have a buddy system, where they assign a buddy to every new joinee who can help him/her in the first few days, if you don’t get assigned one, ask you manager to assign one or you can ask someone with whom you have interacted to become your mentor or buddy. 

A mentor or buddy can be a great partner to navigate through the hesitation of initial few days.

Eventually, we get along in a company, but sooner you do it, the better it is for you to do well there. Be fearless and yet be respectful in your approach. We hope this blog as helped you and your network and you will be able to make its use when you make a career change next time.

To read more exciting and insightful blogs related to software testing, visit our page – https://thetesttribe.com/blog/

Uncategorized
00
The Test Tribe Software Testing Weekly Newsletter #2

Hi ,

We hope you are doing well and keeping safe. First things first, thank you for the fantastic response to the newsletter’s first edition. It only motivates us to do better. So, with the same thought in mind, we bring you the second edition of our software testing weekly newsletter.

Testsigma Community Edition, now live! Testsigma Community Edition (CE), an open-source test automation platform has officially been announced by Testsigma. The platform enables users to set up quickly and automate tests for web, mobile and APIs in just minutes. Check it out here.

Top Discussions from Discord Community
  • A comprehensive discussion on onboarding, training of new employees, the importance of rich documentation happened here.
  • IoT Testing was one of the most discussed topics in the last few days. The community brainstormed on the approach to IoT Testing etc., here. The discussion motivated us to create a new channel dedicated to IoT Testing.
  • Building a framework is one thing, and its successful deployment is another. Which one is more important? Read what the community had to say here.
Latest in software testing technology

 This new feature allows testers and developers to build synthetic test data on the fly for functional and performance tests and virtual services. Once created, the test data can be linked and reused with multiple tests and services.

 Testim extends Tricentis’ own AI-powered continuous testing platform and will help the company further simplify test automation, enabling organizations to create resilient end-to-end tests quickly and easily

Top Upcoming software testing conference 2022
  • Meetup on Load Testing using JMeter – Our 7th Virtual Meetup is on 12th February, where Sandeep Garg will host a Session on “JMeter, Please assist me in Testing for THAT load”. He will address why load testing a web application is necessary, when the load testing life cycle should begin, and more!
  • Worqference– 15 Atomic Workshops on topics like Security Testing, Cypress, Selenium, Appium, DevOps, Testing, etc., by hand-picked Instructors from across the globe in one conference! By the way, do you know? Worqference now has a free day track on 4th February, with five workshops for free. Don’t let go of this opportunity and register now.
  • Webinar on “Docker Testing” by Monika Sharma- Happening on 19th March, this webinar will cover some topics like Docker heavy application, different testing perspectives, Test Automation, Pipeline designing, and more!
  • Automation Bootcamp with Selenium and Java with Kunal Ashar– Dominated by Hands-on Exercises, 85+ of them spread across 45+ Hours. This 12 week+ Bootcamp is the most extensive Industry grade Selenium with Java training on the Internet! It is now entering its fourth Cohort.
The Recent Bests from TTT Blog
  • How to Build High-Performance Testing Teams?

Prashant Hegde shares his thoughts on building high-performance testing teams in this blog. It would be best if you didn’t miss this blog to create a testing team that performs.

Many people are now keen to make a career in software testing. Getting a job in software testing is one of the most often asked questions by Students, Freshmen, etc. Rahul Parwal shares his thoughts on getting a job in software testing as a fresher here.

Quote of the Week

“Don’t just fix the bugs; fix whatever permitted the bugs in the first place.”

Anonymous

Take a Break and Watch the binge-worthy
  • Soft Skills for Testers
    In this video, Daniel Knott talks about five soft skills that every software tester must-have, the importance of communication, why testers must adapt to every new project or product, and why the sixth sense for testers is essential. Watch here.
  • Better Bug Reports
    In this video, Paul Holland covers how to write better bug reports to reduce miscommunication and put the information needed into your bug reports, from writing a compelling title to describing workarounds for the bug being reported. Watch here.
  • Build An Appium 2.0 Plugin In Under 8 Minutes
    In this video, Jonathan Lipps will walk you through creating a simple Node.js-based Appium 2.0 plugin in less than 8 minutes! Watch here.
Go! Get Hired!
  1. Manual QA Tester
    fifthnote
    India
    2 – 5 years
     
  2. QA Automation Senior
    AppSierra Solutions
    Noida
    2 years+ of hands-on experience using Selenium with Java
     
  3. Software Development Engineer in Test
    RD&X Network
    Bangalore
    3-4 years of Java Programming language experience
     
  4. Senior Software Engineer
    Pharmeasy
    Bangalore, Delhi, Hyderabad
    2+ years of testing and automation experience
From the masterpieces

Some food for thought about Discarding useless appendages to the word ‘Quality’ from the book, Quality is Free by Philip B Crosby.

Speaking about giving the quality business some thought, I feel it is time to discard a lot of the useless appendages that have made quality management difficult to understand. The word “quality” is good enough to stand by itself. We should eliminate “control,” “assurance,” and other modifiers that too often accompany it. These identify relatively insignificant and minute differences in approach. The term “quality assurance” came into being during the first frantic missile years ago so a few astute individuals could move into higher salary brackets and at the same time be involved in more dignified work. They were soon peering over shoulders, rather than making quality happen. Certainly, I have no objection to a little nest feathering, but it is possible to make an excellent living actually doing the job of quality rather than just auditing to find out why it wasn’t done.

Top Community Announcement
  • Did you know that there exists an online library for testing? If no, leave everything and hop on to Library of Testing – Powered by The Test Tribe. A community-curated directory of Software Testing Learning resources to help the Testers across the globe choose the right ones for their learning needs. 
  • Writing is a medium to extract our thoughts and pen down our experiences. Therefore, it not only helps us but anyone who reads it. However, a writer writes once, but his legacy keeps ongoing in the form of content they create. So, if you want to make your legacy by writing around testing, this is the place you should visit.
Content that is Gold but never Old

Practical Deep Testing Stories by Pradeep Soundararajan. Pradeep sums up his decades of experience in these blogs, from being a tester to running a testing company that serves deep tech startups.

So, that’s it from this edition. We hope you enjoy reading it as much we did while creating this one. If you have any feedback suggestions, do let us know.

And do not forget to forward this to your testing teams.

Cheers!

Pravika, Rahul, Sandeep, Mahathee, Himani, Steffy, Mahesh, and Ashutosh

Blog
00
The Test Tribe Newsletter #1 – Latest Trends in Software Testing

Hope you are doing great and keeping safe. Firsts are always special, no? We are super happy today to write our first Newsletter today and share it with you so that you can be aware of the latest trends in the software testing world. Show some love if you like it.

We would also want to thank Testsigma who is supporting this inaugural issue of the TTT Newsletter. Testsigma just announced their community version. Open-source & packed with promising features! Testsigma promises to enable users to set up quickly and automate tests for web, mobile and APIs in just minutes.  Check out their Github repo

Let’s dive into this Newsletter issue!

Top Discussions from Discord Community

  • A comprehensive discussion on the frequency of test suite optimization and approach towards it was done here.
  • The community discussed the impact of feature flags in testing and automation here.
  • The possibility of increased requirements for testers upskilling on Security aspects if the cyber attacks go very high in future and companies start caring about this aspect from the very ‘left’, was discussed here.

Trending Topics

  • Testing Engineers are the most sought after Job
    Testing Engineers are the most sought-after job in India in the previous quarter. India’s leading daily, Times of India published this report here.
  • Apple’s Safari bug has been revealing people’s browsing history for months
    According to a new report, a software vulnerability in Apple’s Safari 15 browser might allow any website to track users’ internet activities and possibly expose their identities on macOS, iOS, and iPadOS 15. Read this article to know more about it. This news item is not written or cross-checked by TTT, we are just sharing the news.

Top Upcoming Testing Conferences/Events

  • Automating Test Design and Designing Test Automation Bootcamp with Robert Sabourin– During the 4-week Bootcamp, you will learn how automation can support test design and help you achieve critical functional and non-functional test objectives. This course focuses on real techniques applied to real projects with plenty of real examples and case studies
  • The Test Tribe 7th Virtual Meetup– Happening on the 12th of February, Sandeep Garg will host a Session on “JMeter, Please assist me in Testing for THAT load” and will try to answer some questions like why is load testing a web application necessary, when should the load testing life cycle begin, and more! 
  • Worqference– 15 Atomic Workshops on topics like AI/ML Recommendation Engine, Cypress, Selenium, Appium, DevOps, Testing, etc. by hand-picked Instructors from across the globe in one conference! From practical demonstration-based teaching and workbooks after each session to some crazy networking and fun, Worqference has it all

The Recent Bests from TTT Blog

  • We looked back at the year gone by. The highs, the lows, the good, the bad, everything. The community grew multi-fold and we witnessed the launch of our 2.0 Avatar. Read more about it here.
  • In this blog, we discuss multiple factors that should be thought of before deciding to stop testing. We talk about input quality-related factors, situations owing to management issues, and exit criteria in length

Quote of the Week

“First, solve the problem. Then, write the code.”

John Johnson

Take a Break and Watch the binge-worthy

  • Testing in a post epidemic world
    The epidemic has hit us all. Does it mean anything for the present way we are testing? What will change the post epidemic for the testing world if it does? Listen to what leading experts in the field have to say
  • API Testing from the Basics and Postman Workshop
    In this video, one of our community members, Pricilla talks about API Basics, API Testing in detail. In the second half, she does a live demo in Postman Workshop
  •  “Word Smatter” by Damian Synadinos
    Damian chose a slightly unconventional, interesting, and conversational method to give testers a high-level summary of the importance of Semantics and Semantic Discussions. The metaphors used by Damian are just awesome! Tune in here.

Jobs in software testing

  • QA Tester
    Technozer Solution
    Surat, Gujarat
    0-2 years of experience in QA testing

From the masterpieces

Here is a snippet from the book Lessons Learned in Software Testing: A Context-Driven Approach: Kaner, Cem, Bach, James, Pettichord, Bret

When a bug has been marked as resolved, a tester should review it. If the bug was marked as fixed, the tester should try to show that the fix was incomplete. If the bug report was rejected as nonreproducible or not understandable, the tester should fix the report. If the bug was deferred or rejected as a non-bug, the tester should decide whether to gather additional data in order to challenge the deferral or rejection. If the bug was rejected as a duplicate, the tester should decide whether she agrees. Some project teams bury bugs by marking them as duplicates. Normally, the tester who reported the bug will retest it, but if a non-tester reported it, the bug should be evaluated by the tester most familiar with that part of the program. When feasible, that tester should also consult with the original reporter. No bug should be marked as closed unless it has been reviewed and closed by a tester.

Top Community Announcement

  • Worqference Referral Program
    Enrol in the program to get discounts for the ones you refer to register for Worqference and rewards for yourself. Check more details here.
  • The Test Tribe’s Call For Volunteers, 2022
    We are looking for the next Tribe Champions who want to positively impact the Testing Community space, all driven by values. If you are keen, express your interest here.

Content that is Gold but never Old

Great Resources for Software Testing curated by Huib Schoots. These are resources that can serve as ready reckoner irrespective of your experience, domains, etc.

That’s it for this issue then. We would like to thank our contributors to this Issue: Mahathee, Steffy, Rahul, Sandeep, Pravika, and Himani

We hope you enjoyed today’s Issue. Feel free to forward this to your Testing team. Write to us for any feedback/suggestions.

To read more exciting and insightful blogs related to software testing, visit our page – https://thetesttribe.com/blog/

 

Blog
00
When to Stop Testing?

When to stop testing? This question gets asked more often than not. However, as simple and straightforward it sounds, the answer to this question spans multiple aspects and variables which should be considered when we really want to stop testing. We just wish the answer could be “When all defects are found!”. Like humans, the software is also mere mortal and never bug-free.

This blog aims to discuss multiple factors which should be pondered before we make a decision to stop testing.

The Release Deadline Has Been Met

We can stop testing when the release deadlines have been met. We live in a world full of constraints, so time like any other resource is constrained too. Every testing cycle will have a schedule, and we need to stop testing when we reach the end of the schedule.

The key point here is to plan the testing well so that all the requirements have been tested and coverage has been done before the scheduled end date. After all, you won’t like to ship a partly tested product just because the deadline had arrived.

Too Buggy To Go Deep

One of the interesting answers to the question, when to stop testing is when it is too buggy that you can’t go beyond the first few screens.There will be times when the software will have a lot of bugs on the surface which will not allow the testing team(s) to go deep into the software or perform more sophisticated tests. In such cases, even though schedule permits, we might have to stop (read pause) testing, only till the time blockers or superficial bugs are solved and it allows us to go deep into the product.

Management Decisions

While as testers we only have visibility of the product we test, but the company’s management has the visibility of all the products under its umbrella. The company’s management may take decisions to maximize the interests of the
company which could lead to the stopping of testing of the project you are assigned.

Some of the common reasons in such cases are – a) Budget or/and resources were allocated to some other high priority project b) The project was canceled (from the client’s side or the company’s side) c) The allocated budget is over and no more budget is being allocated.

Exit Criteria Has Been Met

By far one of the most important criteria to decide testing stop is when exit criteria are met. However, the key point is here it not just meeting the exit criteria, the key point here is designing them. Designing exit criteria for any product or
software testing cycle is easier said than done. It is imperative that we consider multiple factors while designing exit criteria, some of which are mentioned below:

1. Strong buy-in from the development team. In the end, your job is to discover defects and theirs is to fix.

2. If there are clients who will further test the product, that should also be considered as to what will be an acceptable input quality.

Here Are Some Examples of Exit Criteria:

1. When all the planned tests have been run (it could include multiple cycles of some or all tests as well)

2. When the number of open defects reaches a certain milestone (this could also be enhanced based on the allowed open defects across various priorities/severity)

3. When the planned regression tests have been done.

4. If your product involves stability tests like MTBF, what is the acceptable value of the MTBF Test.

Exit criteria once designed are not meant to be carved in stone. It should be reviewed constantly in light of the adherence and the post-release issues which come after we meet a set exit criterion.

How to Track Testing Progress to Meet Exit Criteria?

While designing and concluding exit criteria is indeed major work done. The next step is to regularly monitor the progress that the exit criteria are met. As testing teams, we should understand that if the product is not shipped on time (after meeting exit criteria), then we might have a severe business impact in terms of lost sales, competition gaining significant advantages to name a few. It is extremely important to monitor the testing progress viz-a-viz exit criteria regularly. Some of the suggested methods of doing it are as follows:

1. Set up a Dashboard that can powerfully summarize all the variables against
exit criteria.

2. Set up regular sync-ups with various stakeholders to unblock blocked
people, discuss risks and mitigation plans.

As mentioned earlier, while there is no straightforward answer to when to stop testing, we hope this blog gives you enough thinking points to decide your exit criteria and stop testing points.

To read more insightful blogs related to software testing, visit our page – https://thetesttribe.com/blog/

Blog
00
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 organizing 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. 

Register for 2022 Edition 

 

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 Cometa.rocks – 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 Unifarm.co. 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 Cometa.rocks summed up how the participants began this hackathon

Cignithon feedback
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 Cometa.rocks 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

Cignithon feedback

Listen to what Ralf (Founder, Cometa.rocks) 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

Screenshot 2021 09 08 at 1.50.49 PM

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

Cometa.Rocks

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)

Unifarm

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)

Myntra

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

Register for the 2022 Edition 

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

Blog
00
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.

Blog
00
logo

The Test Tribe is a leading global Software Testing Community (proudly Asia’s Largest) turned EdTech Startup. Started in 2018 with a mission to give Testing Craft the glory it deserves while we co-create Smarter, Prouder, and confident Testers. We take pride in creating unique global Events, Online Community spaces, and eLearning platforms where software testers globally collaborate, learn and grow. With around 200 Software Testing Events like Conferences, Hackathons, Meetups, Webinars, etc., and with other Community initiatives, we have reached a global footprint of over 70K+ Testers. We intend to be the top destination of choice for Testers across the globe for their upskilling and community needs.

Learn
Engage
© 2023 The Test Tribe. All rights reserved.