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.
Spread the word, ask your friends to claim theirs.
Testing is here to stay, testers are here to stay.
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.
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?
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.
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
We are running a sitewide discount on our courses and workshops. Feel free to use the code TDAY23 to avail big disounts on your learnings.
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. 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 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 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 would be 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 Leading to Stop Software Testing
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 is when exit criteria are met. However, the key point is here it not just meeting the 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 software 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.
Know When to Stop testing with These 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?
Why Testing Is A Never-Ending Process?
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 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 QA or software testers, 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, and competition gaining significant advantages to name a few. It is extremely important to monitor the progress in the testing process 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
2. Set up regular sync-ups with various stakeholders to unblock blocked
people discuss risks and mitigation plans.
In conclusion, determining when to stop testing is a complex and subjective matter, lacking a definitive answer. However, throughout this blog, we have provided you with valuable insights and considerations to help guide your decision-making process. By exploring factors such as meeting release deadlines, the severity of bugs, management decisions, and establishing effective exit criteria, we have equipped you with the necessary thinking points to make informed choices. While the decision may still require careful consideration and evaluation of specific project circumstances, we are confident that the information shared in this blog will empower you to determine appropriate exit criteria and identify the right time to conclude testing. Remember, success lies in finding the right balance between thorough testing and project constraints. So go forth, armed with newfound knowledge, and make impactful decisions to deliver high-quality software products.
Ideas are worthless until you get them out of your head and see what they can do.
Before joining The Test Tribe as a full-time employee, I had a series of discussions with Mahesh Chikane about his plans and ideas for TTT as a community. Among the long roadmap of ideas he had in his mind was to have a conference that focuses on hands-on learning and not just PPT-based talks. Essentially, he envisioned having a conference of workshops.
This conference format was never ever tried in the testing community/conference space before (though it was tested in other areas from where we took inspiration). So there were a lot of unknowns for which we had to find answers, how long the workshops can be, how many workshops can we include, how long the entire conference can be, how do we handle a situation where we need to do it for more than a weekend, etc.
However, just before the TestFlix event days, I got a call from Mahesh that we could launch this on TestFlix Opening. The answers to all the above questions were still not with us, for we never had a discussion that focused on them (We discussed all of these fleetingly as a side topic in some other talks, but never as a focussed discussion). So we debated for a while on whether we should launch it or not, but in the end, we decided to go ahead and give it a shot at Launching with just a 1-page landing page that did not have any detail of the topic/instructors till then. (Remember, we still did not have any answers to these questions)
At TestFlix Opening, Worqference was born as #TheNextNew, everyone liked the concept, and some passionate learners and believers purchased the super early bird ticket.
With some substantial initial motivation from the early believers, it was time for us to find answers to the unexplored paths which I shared above.
Over the next few weeks, we brainstormed deeply with our think tank (Ajay, Balaji, Geosley, Sandeep) on the potential instructors, the format, the documentation required, the duration, the rough schedule etc. Documentation was a critical step for Worqference since 100s would be taught together, and the instructors would have limited time to do the workshop, so the initial prep by attendees should be solid).
Headspin was the first sponsor to show belief in this format, and they came in as Premier sponsors for Worqference. We thank the entire Headspin time for their support and patronage.
It was time for execution for Worqference to begin in full swing. One of the most vital parts of Worqference was its Marketing. Since this was a new format with a stellar instructor lineup, its value had to be communicated smartly to the entire community.
We talked to numerous community members and took their input for Worqference regarding how to improve it, what we can add, etc. and made changes accordingly. Being a new format, we needed to experiment comprehensively on its marketing and communication so that as many people could join it. (While some experiments did really well, some did not do well).
The hustling continued close to the event day, and then it was time for the D-Day.
After a grand welcome from our excellent seasoned host, Lalit Bhamare, it was time to dive straight into the workshops.
The first workshop was by Anuj Magazine on Sketchnoting. Sketchnoting is a skill known to few. Anuj demonstrated a framework using which sketchnoting can be done quickly and does not require one to be an extraordinary artist. There could not have been a better start to Worqference, for this workshop was not just learning but a lot of fun as well for the attendees.
The day continues with two parallel workshops. One on Contract Testing using PactJS by Marie Drake and the other on Digital Accessibility by Rajini Padmanabhan and Rohan Sharma. While Marie’s workshop was full-on hands-on, Rajini and Rohan’s workshop triggered the importance of accessibility and how it can be tested in organizations.
Day 1 had a fitting end with two parallel workshops, one on Systematic Product Modelling by Ajay Balamurugdas and Balaji Ponnada, the other one on Game Automation using Appium by Jonathan Lipps. While Jonathan is a stalwart in Appium (being one of its original creators), Ajay and Balaji are immensely respected for their grip on testing craft in the community. The day ended on a high, only to get better the next day.
Day 2, Saturday, 5th March, began with two parallel workshops. The first one by Lalit Bhamare on Session Based Test Management and the other one by Sai Kishore and Srinivasan on Gesture Automation using Appium.
Day 2 continued with full glory when Jess Ingrasselino and Anna Royzman took centre stage with their concurrent workshops on the Ultimate Shift Left and Leadership. On the one hand, Jess walked through the importance of understanding unit tests; Anna triggered some strong emotions and questions during her workshop, which had no slide. Yes, a conference that has a workshop with no slides and yet rated 4.7+ by the attendees.
As Day1 ended on a high with almost celebrity speakers like Jonathan Lipps, finishing the remaining days on a high was paramount. Who other than Leandro Melendez could do better? Leandro engaged (and almost mesmerized the audience) with his fantastic storytelling yet practical approach to Performance testing in the modern world.
It was now time for the final day of Worqference. It had to be a fitting end to the months of hard work put in by the organizing team, volunteers, instructors and everybody who supported us.
Day 3 began with 2 young but energetic instructors, Gaurav Narwani and Kunal Ashar, who took parallel workshops on Getting Started with Security testing and Getting Started with Cypress. The instructors jumped into practical hands-on from the first minute, engaging the audience through interactive polls and delivering 2 stellar workshops.
The youthful energy continued when Rahul Parwal took the stage in one of the two following workshops. While Rahul delivered a workshop on Bug Advocacy, Corina Pip had a workshop on a topic every automation tester must attend, “Making your selenium tests reliable using waits”.
Speaking of energy, if you have ever heard Rob Sabourin, you will not disagree when I say his energy is contagious. Hence, to wrap up this one of its kind events, it was Rob’s turn to do a workshop on code listening. Again, Rob did full justice to what was expected from him and the audience, who was constantly learning from the last 3 days, got the energy capsule they wanted.
Like all good things, Worqference came to an end. However, the energy of the participants did not drop. The wrap session was full of messages and emojis and