I'm new to QA, and within the first few weeks of starting my position, the developer team held a hackathon day.

I love the idea of hackathons, but me and my team just carried on doing day-to-day tasks, none of which were crucial. I had the feeling that the consensus was that QA team didn't really have a place at the table, so to speak.

I base this on the fact none of our team really interact with the developers on a code level. There is no paired working time, or anything like that, which I've read is a good way to speed up the development of working code. Seeing as the QA team have no code experience, it could potentially have a negative effect, what with the explanations the developers would have to do, and the odds of a QA person spotting a complex bug in the code are slim.

Rambling aside, I'm wondering if anyone has any experience QA'ing in a hackathon day?

What was your role? Did it go well?

  • 1
    Hack some scripts to help you doing your QA work. Do you have nagios monitors? Do you have grafana to show activities? Do you have scripts analyzing login messages for interesting stuff? – Peter M. - stands for Monica Mar 1 '17 at 22:23
  • 1
    As a former dev, I would love for QA people to show up to hackathons. The faster you get your dev cycle, the better!! – corsiKa Mar 2 '17 at 3:20
  • @PeterMasiar I had no idea what any of those things are so you have given me a lot of googling to do – Jake Turner Mar 2 '17 at 22:34
  • 1
    Sorry I meant checkin messages: we compare bug number in checking against bugzilla database to see (1) typo in checkin (2) bugs which are worked out out of order or process – Peter M. - stands for Monica Mar 2 '17 at 22:48

If the hackathon was a single group project this is hard. You can certainly do manual testing and develop simple test plans but you may not find that much fun.

If the hackathon was everyone going off and doing their own thing (possible in pairs or small groups) this provides more opportunity for you. In this case you'll still need to take some initiative and decide do you want to do, for example:

  • Learning programming and scripting skills with small projects such as bash scripts, SeleniumIDE scripts, simple page object examples, etc.
  • Learn more academic skills about QA and testing - more studying than the typical 'doing' of a hackathon though
  • Pairing with developers and helping to write tests - if you have the technical skills to do so.
  • Computer science topics such as Linked Lists, Stacks, Design Patterns, etc.
  • Don't consider a hackathon to be only coding (even if it is currently), there's a great guide at https://hackathon.guide/ to all the other thing you can do like problem solving. Excert: The hacking track is for participants to dive into problems. Often groups of 2-5 individuals form around a project, such as building a new data visualization, writing a document, or collaboratively investigating a problem. Participants take out their laptops, connect to power and wifi, and get working.
| improve this answer | |
  • Thank you for your wonderful suggestions! There is almost 0 code knowledge amongst the team, and our company is just about to start implementing automated testing, so it could be a great opportunity for some of them to break into it. I'll be sure to gather suggestions and requests from the team after giving them the hackathon.guide. – Jake Turner Mar 2 '17 at 22:26

Yeah, definitely a good idea to go to hackathon day.

I have been to a couple of them. A hackathon is a really fast paced place to work at.

My personal opinion is:

  • It is not necessarily true that a QA does not how to code. A QA can be a dev too. Especially in recent years, the line between QA and dev has blurred a bit.

My role @ a hackathon was to:

  1. Sit with developers when they are hatching their ideas. I did not sit there as a pure QA, I pinched in my thoughts as well. From my experiences, I know how to structure codes in order to make them more maintainable. I also know how to make codes more testable.
  2. Sit with developers when they are coding. I was coding as well. Basically, we were doing pair programming.
  3. When a feature was developed, I was helping with improvised quick testing, of course, devs were testing with me.

Apart from technical details, I personally think:

  • Do not expect devs to trust you fully from the beginning, everyone earns trust over time.
  • There are lots of other chances for devs to get to know you as well apart from attending hackathons.
  • Approach your manager and volunteer to attend hackathons as a QA, they should not reject you.
| improve this answer | |
  • 1
    I love the idea of paired programming, both as a opportunity for the developer to bounce ideas around, and as a learning experience. I have a lot of learning to do before my "advice" is worth a damn, as I have read-only understanding of the language, with only a novice understanding of LINQ. – Jake Turner Mar 2 '17 at 22:31

I am SDET but worked as a pure Dev during Hackaton, coding part of the solution.

I guess you could develop a small testing tool, if you want your solution to be somehow related to testing.

| improve this answer | |
  • My team did a testing POC for our hackathon. – John Oglesby Mar 2 '17 at 21:01
  • Was it successful? Was the concept implemented? – Jake Turner Mar 2 '17 at 22:33

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.