QA Role - UPDATED!
We have had a fantastic response to our post about Quality Assurance (QA) roles here at Mm. Thank- you!
We have had to update the job spec to include location & availability requirements, so please have a read before you apply
Contract Quality Assurance (QA) role
6 Month UK based contract
Requirements :
- You must be available in 2 weeks to start a full time 6 month contract on site in our studio which is based in Guildford, United Kingdom.
- You must be over 18 to apply
- You must be permitted to work in the UK
- You must attach an up to date CV and cover letter which highlights why you are perfect for the job!
The successful candidate will:
- Carry out visual and participative checks on LittleBigPlanet for quality bugs
- Log all identified bugs through our system
Skills, Knowledge & Experience:
- Competent games player.
- Strong knowledge of computer games across multiple platforms.
- Educated to G.C.S.E grade āCā or higher in English.
- Basic knowledge of database, spreadsheet and word processor applications.
To apply, email CV’s to jobs@mediamolecule.com
Thanks!
New Job
Contract Tester (6 Month Contract)The successful candidate will:
- Carry out visual and participative checks on LittleBigPlanet for quality bugs
- Log all identified bugs through our system
Skills, Knowledge & Experience:
- Competent games player.
- Strong knowledge of computer games across multiple platforms.
- Educated to G.C.S.E grade āCā or higher in English.
- Basic knowledge of database, spreadsheet and word processor applications.
To apply, email CV’s to jobs@mediamolecule.com
Thanks!
mm’s workrate as expressed by svn revision number…
so, while waiting for dave to iron out a couple of final localisation issues on our TGS (tokyo game show) build, I decided to geek out. I wrote a small C program (I don’t know perl! sorry) that scans through our svn database (directly using the filesystem, ahem) and generates a graph (using gnuplot, yay!) of LittleBigPlanet’s revision number over time. For the non-codey types, that’s basically - every time somebody on the team, artist, designer or coder, works on our game, they beaver away on their computer until they’re happy to unleash their changes on the rest of the team. then they ‘commit’ a new ‘revision’. We’re up to about revision 9,500 now. But how fast have we been checking in? behold, the image of glory:
I could go on about this seemingly boring red line for hours. to me, it represents all the sleepless nights, lost weekends, and love that has gone into LBP, reduced to pure stats. There’s something gloriously useless about it, and yet, fascinating. If you look closely, you can see lumps for weekends where the graph flattens out for 2 days, mini crunches before big game shows where the graph spikes up a bit. And then there’s the broad scale changes - a slow start, when we were only a few people, generally working on big chunks of stuff locally and not checking in that much. then the long flat bit after greenlight - were we really that lazy, or did we go back to big private checkins? In fact I think it was mainly due to the fact we went into a long review/design phase at that stage, and spent a lot of time ‘refactoring’ - anyway the analysis could go on. And the temptation to expand the data I analyse is great - this graph doesn’t take into account how much changed with each revision - was it a single texture, or an entire code system? - who made the changes, or all sorts of other things. but I’ll stop here… surely there’s a trac plugin for such wastes of time ![]()
