QA time during Hackathons

(christian dabnor) #1

So, our Devs have a bimonthly Hackathon, where they pick projects and that intrigue them and form squads and stuff. As QAs, we’re left a little out of it, and there’s not much for us to do. I think the QA team could make good use of this time. One possible idea I had was to do test Katas. Does anyone know of any decent ones we could do? Another would be to use Test Sphere. Both of these things would help in so many ways. It would help us to bond as a team (as it is, we tend to be split amongst teams), act a mental workout, and, if any are flagging, rejuvenate enthusiasm for testing. Does anyone else have any thoughts or experiences of this sort of thing?

3 Likes
(Viv) #2

Hello! I’ve tried a test kata before which was fun and worked well. I like the idea of test sphere but not tried it. I also have thought about doing a test bug bash either in software at work (to get buy in and time back from the business) or on a completely random site/software off the web. Would love to hear more if you try something :slight_smile:

(Chris) #3
  1. They form squads with no testers in them?
  2. If you want to be useful review your automation™ code for things to remove by usefulness, better labels and descriptions, expiry dates. Kill them.
  3. Ask if anyone has a talk/workshop they’d like to give.
  4. Run a game of Zendo, Dice Game, Set, Concept or any other useful game. Zendo and Dice Game are good for focus/defocus in exploration. Set is a useful pattern recognition and heuristics game. Concept is a lesson in communication.
  5. Make teams (not the teams you’re usually in), pick an area of your product, throw a dart each at the HTSM and model and test the system in that way or for that criterion. Present your findings to the group.
  6. Really, they don’t need professional testers on their projects? Sure?
  7. Run freelance across the system. Present findings to the group, including models used, bugs found, missing coverage discovered, techniques invented, tools written/used.
  8. Escape room.
  9. Because if it were me I’d be pretty insulted. Maybe they just haven’t thought to ask - try offering your services?
  10. Information sharing. Discuss what you’re doing to the other teams, models you use. Offer insights into other areas.
3 Likes
(Brian) #4

Things I have done which have worked well:

  1. Join a group and advocate for testability. Even in a 1-2 day project, your developers should be thinking about testability. Work on it until testability is second nature to the team.
  2. Join a group and work on something completely new. My first Javascript program was in a hackathon, for example.
  3. Watch their processes. Learn their processes, Give feedback. In learning how they do things, you can do your things better (In theory).
  4. Try new test techniques. Pairs testing, Mob testing, test sessions, test planning, testing without planning/specification, making models, etc.
  5. Work on something new (part 2). Help with the team’s design, plan the demonstration (In that team, demonstrating the product to the team was the tester’s task)
1 Like
(Ady) #5

Hi Chris, I did a talk on creating our community of practice at our work with has a few practical ideas of challenges we did and a risk based technique to identify what you want to look at going forward. Good luck with it, it’s definitely worth the effort.

1 Like
Learning buddies in Communities of Practice?
(christian dabnor) #6

Thank you all for your advice. I have some meetings coming up to discuss things like this. Not sure when, yet, but I’ll keep this thread updated if people are interested.

2 Likes