As I announced a month ago, our testers joined in on the challenge 30 Days of Testing Challenge by Rosie Sherry from the Ministry of Testing which involved a different testing activity for each day of July. Here I’ll share mine and my colleague’s experiences over the past month. I can assure you the conclusions are highly positive!
The office heavily participated in the challenge, some even formed groups and opened a Slack channel just for sharing our progress with one another. Additionally, we printed several copies of the challenge and spread them throughout the office. We decided to get a little competitive, to see who could do each of challenges first, although in reality no one thought about winning, but it was good in that it helped us to improve in several areas of our testing. It is safe to say we all learned something new every day. Everyone completed the tasks at their own pace, maybe not on a strictly daily basis like the challenge called for, but we would get up to speed every few days if we didn’t complete certain things. We tweeted pictures of our progress, facilitating more interactions between ourselves and testers outside of the company.
Here is how my checklist looked by day 31. At the top, you can see who was on my “team.”
In the rest of this post, I’d like to revisit some of the tasks that stood out to me the most.
Day 1: Buy a testing book and read it by day 30
I didn’t buy a book because I already have many in the office waiting to be read. When I went to San Francisco for the Velocity Conference in June, I brought home several copies of very interesting books by O’Reilly, so I picked one of those to dive into, “Anomaly Detection for Monitoring.” Today, I finished reading it just in time to properly end the challenge (this is one of the things that I find wonderful about challenges like this, if it weren’t for the challenge, I probably would have taken longer to finish it). While it was interesting to read, it was not as interesting as I expected 🙁 … but, at least now I know a little more about systems failure predictions.
— Federico Toledo (@fltoledo) July 1, 2016
Day 3: Listen to a testing podcast
I thought this would be an interesting new way to digest material, but I didn’t take much away from the two podcasts I listened to. The first one did not convince me much and the other had nothing new to say for me. Maybe I will have to keep searching for a podcast I like!
Day 4: Share a testing blog post with a non-tester
For this, I found a post that is not very technical that is easier to understand for someone who is not in the world of testing. I wrote the post a few weeks ago, and it is more focused on testing education and the many ways to form testers.
Day 7: Find an accessibility bug
That day, I explored many useful tools that our accessibility expert, Lisandra Armas, had shared with us. Anyway, I think the funniest bug we found that day was from a tweet someone had shared about a pretty serious accessibility issue:
Day 8: Download a mobile app, find 5 bugs, and send the feedback to the creator
I took the opportunity to test an application that an alumnus from Project Nahual (a non-profit organization that helps develop testers in Argentina and Uruguay) is testing, used for listening to shortcasts. I reported some of the errors I found and I quickly received an answer from him. 🙂
Day 10: Find an event to attend
I not only went to a testing event, but I helped to organize a new meet up, inviting Project Nahual alumni to come so that they could continue to develop other skills such as public speaking. Thus took place the first meet up of alumni from Nahual. It was a success!
Day 11: Take a picture of your team
I really like these photos that Giulianna tweeted from Abstracta’s early days when there were only 6 of us. Now, we are over 60, still mostly testers!
Day 17: Find and share a quote that inspires you
I tweeted a quote from our “Ultimate List of 100 Software Testing Quotes” post, which thanks to this challenge, saw a lot of views!
If you’re relentlessly focused on lowering cost you’ll quickly become oblivious to opportunities to increase value (Bolton) #30daysoftesting
— Federico Toledo (@fltoledo) July 18, 2016
Day 19: Find and use a new tool
While I have several tools pending to try, I decided on one in particular from a blog post we were preparing at the time in Spanish in which we interviewed Lisandra Armas. From her, I learned about the existence of Greenshot, and I loved how it allows you to capture images in a much more convenient way with several added functionalities. Needless to say, I’m still using it today!
Day 20: Find a good place to perform some security tests
There is a project called webgoat, maintained by OWASP and it’s ideal for this task because it has intentional security problems, made for educational purposes. A student had shared this in my class a while ago at the Catholic University of Uruguay where I am a software testing professor.
Day 21: Do pair testing with someone
— Abstracta (@AbstractaUS) July 21, 2016
Here we have Giulianna and Lorena doing pair testing specifically for the challenge, although this is something that we do daily. Not pictured, we had Gabriela and Miguel test a new version of RelyTest, a tool for managing exploratory testing and Leticia and Malvina paired up also.
Day 22: Share your favorite testing tool
I had to share Monkop, my favorite mobile testing tool made by some of our team members here at Abstracta.
— Federico Toledo (@fltoledo) July 22, 2016
Day 23: Help someone test better
In particular, Project Nahual collaborators and I met that day to modify our course curriculum (starting in August), which we believe will help many people to test better!
— Federico Toledo (@fltoledo) July 23, 2016
Day 29: Find an out by one error
This was the only task that I could not manage to do… (honestly, I didn’t try so hard) but I was happy just because I learned what it meant. This is what the “all-knowing” wikipedia has to say about it:
“An off-by-one error (OBOE), also commonly known as an OBOB (off-by-one bug) or “that extra inch you didn’t really want”, is a logic error involving the discrete equivalent of a boundary condition. It often occurs in computer programming when an iterative loop iterates one time too many or too few. This problem could arise when a programmer makes mistakes such as using “is less than or equal to” where “is less than” should have been used in a comparison or fails to take into account that a sequence starts at zero rather than one (as with array indices in many languages).“
There’s a great discussion about it here, on StackExchange.
Day 31: BONUS Share your 30 Day Challenge experience on Youtube, Instagram, Twitter, or a blog post
I think you can see that that’s what this post is for! Overall, everyone really enjoyed this experience. We will most likely continue to use some sort of gamification in the office to motivate us to try new things and learn every day.
Did you participate in the 30 Days of Testing Challenge? If you wrote a post about it, let me know in the comments! I’d love to hear about YOUR experience.
Thank you Rosie and the Ministry of Testing for this fun initiative!