My first Software Testing Hackathon (or Bugathon, or Testathon) was way back in 2009–10 and it was known as Zappers and conducted by TCL. My team won the first one and We were thrilled. The next one we lost, and we again won and this continued with many other Software Testing Hackathons. I won most of them and lost a few on the way. Winning gave the money and losing taught me the most. I also wrote a book called 50+ tips to win testing contests.
As someone who has participated and won many Software Testing Hackathons, I want to share five actionable tips to help you win your next time you participate in a Testing Hackathon.
Tip 1: Keep your Weapons ready
For testing a product, one needs good test ideas, good devices, and tools. I have seen many testers come to the hackathon with laptops that always need to be plugged in for a charge, mobile phones with low battery, no cables to transfer data and the highlight of all, only 1% come with their own internet dongles or WiFi hotspots. I mean why would you take that risk? Why would you want to rely on venue Wi-Fi which will anyways be shared by 100s of participants?
Here is my checklist for a hackathon:
- My laptop — I know which keys work and which don’t. There are no surprises.
- My mobile devices — I exactly know the device settings and the bugs on my phone. I know the speed at which things happen on my phone and I know the passwords for all the accounts on this phone.
- Chargers for both laptops and mobile phones
- Spare power banks (fully charged)
- Pen drives
- Internet dongles
- Test data — Accounts, images, files of varying sizes and formats
Tip 2: Practice Probable Bugs Exercise
Tell me a feature or element and I would give you a list of what can go wrong. I call it the probable bugs list. I consciously practice it when there is no need for it. What can go wrong with Pagination, what can go wrong with Search results, what can go wrong with file upload, I already have a list in my mind. No wonder the list of 400 common software bugs by Dr. Cem Kaner was an inspiration. You can access the PDF here. Go through the pdf and have a mind full of probable bugs for the next testing session/hackathon.
Tip 3: Practice filing bugs
I find it strange when testers take their own sweet time to file bugs in a hackathon. Especially when you are also judged for the duplicates. The one who files the bug early gets the credit. The focus is not on the details but just enough details and move on to the next bug. There are testers who write ten steps for a simple bug. They don’t attach screenshots or videos. Even if they attach, the video is of a few MBs in size and takes forever to get uploaded on the slow network. Amazingly, the tester is watching the upload progress and not focusing on filing the next bug. Some testers are not even aware of the tools other than the default ones available with the OS. Also, what if your favorite tool failed? One should have 2–3 tools for each category (screenshot, test data generation, note-taking, file converters and so on.
Tip 4: Focus on your Strengths
Hackathons are not for trying out new techniques or quality criteria unless you are fine losing the top prizes at stake. Each one of us is good at specific quality criteria and should dive deep in that during the hackathon. Also, know the tools that can give you an overview of the quality criteria you are not an expert at. W3C checklists, GTMetrix, Quixxi, WAVE are some of the tools for Compliance, Performance, Security, Accessibility respectively.
Tip 5: Know your speed and Never Give Up
If you have practiced enough times, you would know how much time you would take to know an application, how much time it takes to upload a screenshot and how many minutes would you take to complete a bug report. Without knowing your current speed, you would not know if 20 bugs are enough or 40 bugs is a good performance. Practice so much that you can file a bug within 30–45 seconds and you can find a new bug every 60 seconds of testing. This would ensure that you can easily file 30–40 bugs every hour and you can easily touch 60 bugs in two hours. It is a decent number considering that many participants are first-timers and might not even cross 30 bugs. Having such a steep target also forces you to think of diverse ideas and attack the same application in multiple ways.
Bonus: Do not waste time discussing bugs with your partner. Find it? Log it.
You may also want to read my free ebook — 50+ Tips to Win Testing Contests
Hope these tips were useful. See you in the next hackathon!
Join The Test Tribe Community here to stay updated with future Testing Hackathons amongst other events.
About the Author
A graduate of Problem Solving Leadership, BBST Courses by AST, Rapid Software Testing, Rapid Testing Intensive workshop, Lean Software Testing Workshop, Ajay doesn’t hesitate to spend on his learning. Starting his career as a software tester, he continues to be a hands-on software tester along with training new testers, meeting testers in person, presenting at conferences, conducting workshops, and sharing his thoughts via blog and tweets.