Archive for the ‘QA jobs’ Category

Job Opening in the QA department

We’re hiring for a new QA team member at Agora! I’ll post the job info here, in case anyone knows of a great candidate. Check out our website for more information about life at Agora.

Quality Assurance Analyst
================

Overview:
Agora Games (http://www.agoragames.com), a subsidiary of Major League Gaming (http://www.mlgpro.com), develops online video game technology and web communities for game developers and publishers. Our technology makes compelling information available to players both in-game and online, while providing publishers with a wealth of demographic information. Over 28 million unique players are tracked by our system and billions of bits of data are spread across a cutting edge virtual computing platform. Our portfolio includes work on titles including Guitar Hero, Call of Duty, and Transformers, and we cross all the major gaming platforms.

Description:
Agora is seeking a Software Quality Assurance Analyst to join our QA team. We test software for MLG’s websites and our proprietary programs, designed to enhance the community experience around some of the top video games. In this position you will be expected to work closely with developers in an Agile environment to deliver quality products. You will provide feedback about response under projected load, risk areas, and overall experience of the application.

 

Duties and responsibilities:

Automated and manual and load testing using Selenium, Siege, Jmeter

Write and execute test cases

Keep automated tests up to date and debugged

Provide feedback on features during sprints

Ambiguity Review of requirements and technical documentation

Report detailed and accurate bugs and follow them through to verification

Interpret requirements from various sources and apply basic testing philosophies and heuristics to test software at different stages of the development process.

Requirements:

* At least 1 year experience in the software QA field

* Experience testing with Selenium, or other automated testing tools.

* Basic experience with a scripting language

* Familiarity with unix

* Interest in working on-site at our office in Troy, NY.

The ideal candidate will have:
* Attention to detail

* Analytical mindset

* Experience testing web properties

* Love video games!

* A proactive mindset and be able to multitask and prioritize requirements.

* Experience with Agile development methodologies

* Must be self-motivated, posses excellent communication skills, and be a team-player.

Benefits:
* Competitive salary and benefits

* Work with an experienced, successful, intelligent team

* Be an integral part of a growing, fast-paced company where your work will make a true impact

All applicants should submit their resume and cover letter.

We want to hear from you! Agora values excellence, passion, integrity and creativity. Submit your application to jobs@agoragames.com

Having interns on the QA team

Internships are good for the interns, right? As an intern, you get a chance to learn, to be in a professional environment, sometimes- class credit and of course, some of your first professional references.  Interns get to be around the processes they are learning about first hand, they get to attend daily standups, read through requirements and work on project deadlines. It can be a great experience, but not just for the interns. The whole department can benefit from having some amazing interns around.

Having interns on the team has brought a different point of view. While they don’t have as much professional work experience they do know about the process and are used to learning new things quickly. I’ve been impressed with the quality of interns we have gotten. It is also great to have people with a little more programming knowledge who can help us make adjustments and revisions to tools.

Managing interns provides many of the same complications that managing a regular team of full time people does, but with some added quirks. The biggest quirk is that you have to realize that this job is not their focus. Sure, you spend 40 hours a week at it and it is your career. It is really important to you. But for them, at best this is part of their education, and at worst, it is an after school job. School comes first. Finals week, family vacations, homework- all of that is higher priority. Which is as it should be.

Also, they aren’t used to the office. It can be overwhelming. I personally think this is one of the best advantages an internships can provide, because they can become more comfortable with a professional setting early. Usually this isn’t a problem, but when assigning out projects or attending meetings, it is a good thing to remember.

Lets be honest, for some reason, not many people go to college to be a software QA. There aren’t really any programs and a lot of computer science programs don’t even include it as a required class. Want to get people excited about QA? Why not include it as part of the process while you are studying in college.

I like to think that I’m helping out future QAs by teaching future devs that the QA department does work hard. We experiment with new tools and new languages until we find the right mix for the project, we know how to get around the command line and can read and write some code, we pour over requirements documents and offer suggestions and ask questions. We act as user advocates, we clarify stories, keep long suites of tests debugged and running. We know there is limited time and so we test quickly, doing our best to squeeze out as much testing as we can in what little extra time there is in a project. I jokingly tell them (but not so jokingly) to remember all that when they are leading a Dev team some day.

QA Jobs: Hiring the right person

Who you bring on to your team makes a huge impact on your testing department. My team has been growing this year, and  I am currently in the process of hiring another software QA. The process has been more drawn out than it was last time, with a lot of dead end resumes and interviews that didn’t go as expected. It is hard to be a on a job search, but it is not easy to be on the other side of the table either. You are looking for the right mix of skills, enthusiasm, and personality to both bring something new to your department and to fit in with the group you already have. Last time I went through this process, I wrote about QA cover lettersresumes and interviews – but this time, I am  thinking more about how to find that perfect person.

In my most recent round of interviews, I encountered a wide range of applicants – from out of work developers looking for something to tide them over until they could find a “real position” to recent grads looking for experience and career changes. How do you find the right one? And what will it mean for your team if you chose wrong.?

A guy in my company was talking yesterday about the “two beer rule.” Don’t hire someone you wouldn’t want to hang out with after having two beers with them. This may be a great rule of thumb. Because, interviews aren’t just about finding the right skills, they are about finding the right match. You need someone who can do the job, but also someone who loves doing it. Someone who wants to learn more and try new things and push themselves. Someone who fits in with your team and hopefully someone who you enjoy working with every day. Are there interview questions for that? Or is it just a gut check?

Maker’s Schedule vs Manager’s Schedule

I just read Maker’s Schedule, Manager’s Schedule by Paul Graham. It got me thinking about how readily it applies to QA and to so many of the projects I have worked on- especially as I get more integrated with the development team. Here is an excerpt, but reading the whole article is well worth it.

There are two types of schedule, which I’ll call the manager’s schedule and the maker’s schedule. The manager’s schedule is for bosses. It’s embodied in the traditional appointment book, with each day cut into one hour intervals. You can block off several hours for a single task if you need to, but by default you change what you’re doing every hour…

But there’s another way of using time that’s common among people who make things, like programmers and writers. They generally prefer to use time in units of half a day at least. You can’t write or program well in units of an hour. That’s barely enough time to get started.” -Graham

As software testers, we are often makers in a manager’s world. But it is different for us than for engineers, because we need to fill both roles to some extent. We need to produce test cases, comb through documents and create creative and comprehensive test plans. But we also need to sit in on meetings, communicate with other departments, understand release schedules and be focusing not just on our days work- but on following up on a previous releases issues and planning for next releases test cycle. We have to balance needing a maker’s block of time to create and a manager’s hour long shifts to get to meetings and do planning.

What do you do, as testers, to mitigate the clash of schedules and are you happy with how it works in your company?

What I’ve learned about Agile Testing

I started on an agile team last August. In the past few months, I’ve be exposed to a wide range of agile-ness as we have learned to adapt it for different projects and struggled to make it work for us. I have found great worth in some of its practices, and unfinished mess in others. As a team, the company has had to switch practices and courses a few times. The cool thing is that we are able to. No one is so stuck on procedure as to not admit that it could use tweaking. And where procedure was too lax, people have asked for more.

Here is what I’ve learned as the QA department has grown up and around the development teams:

– Agile doesn’t mean “No Processes” it just means flexible processes

Documentation is more a struggle. Shortcuts made in the name of agileness and flexiblity have been huge road blocks in my testing effort. We are still sorting out the right place for them. Something that allows for creativity and adjustments, but still leaves us with a solid document to test against.

– Trying to keep meetings short by cutting out discussion is pointless and unhelpful. Structuring meetings to allow for quick agendas and then discussion time is priceless.

Transparency between departments and code reviews are QA’s best friend, even if it takes more time at first.

– Short iterations mean quick test cycles. This means you need to have as much ready before had as possible – test plans, test suites – both automated an manual, report templates etc can all help keep you on track.

– Managing an agile team means knowing when to step back. The team is responsible to each other, not to you.

– Be flexible. This should be obvious, and maybe it is to some. But in my experience, learning agile meant learning to contort your testing efforts to the time and space available. That doesnt mean you should let your team get pushed around, but it means that you have to be willing to do the agile dance along with everyone else.

– QA needs to make its needs known. Don’t let yourself get deadlines pushed back and back until you are the one left struggling to pick up all the slack. Just because deadlines can change mid cycle now, doesn’t mean that your team has to sacrifice thoroughness in the name of changing requirements and speed.

– Communication is even more important – with things changing and people having so much freedom with their work, if you have a bad communicator, your whole project is at risk.

I am sure this list will grow in the coming months. For those of you who are new to Agile testing- what have you learned? Was it what you expected? Have there been any roadblocks on your project?

High Heels in High Tech: Women Working in the Software Field

“Oh! You’re… a girl” said a remote member of a QA team I worked for out of college the first time I talked to them on the phone. “I didn’t expect that.”

It is something you get used to, working around computers- as do, I’m sure, women in other male-dominated fields.

“I walk in the door and everyone thinks I’m the secretary,” said one female programmer I know.  Another – a QA manager- kept threatening to bring in her degree and hang it on the wall to prove she belonged. I ‘ve shown up for interviews and had people say “actually, I’m waiting for an interviewee right now, but he isn’t here” and had to explain that I was, in fact, that interviewee.

If you have come from an office with more gender diversity, you may find yourself suddenly questioning the length of your skirt, feeling suddenly very aware of the sound of heels clicking on the office floor or wearing lots of turtlenecks. It is obvious you are in a different world here – the office is like a bachelors’ apartment (ok, honestly it is sometimes like a frat house). Some days you are one of the boys, and some days you get asked out three times by the same co-worker (who you refused each time). At first one of them tries explain to you how to work a mouse and a file menu, but eventually, they learn that you can match them in discussion about requirements and software behavior.

I’ve been lucky. In general, I’ve worked with really accepting and easy going guys- but regardless how great the guys are; being the only woman in your company is a unique experience. So this week I’m going to look at what it is like working as a woman in the tech field- whether you are the only woman or one of a few.

(Read the complete, published version of this article in TEST magazine here.)

QA Jobs: The Coverletter

Interviewing and resume review is in full swing now. This is the first time I’ve been on this side of the table. It is hard to review the applications and remember how much care and hope I put in to each application I send off when I am job hunting.  Rejection is hard to get, but it is hard to give, too. What I have been surprised by, though, is that it is fairly easy to tell who has put thought into their application and who hasn’t.

The first things I look at are (I assume) pretty standard, but in a field like quality assurance, a well edited resume demonstrates an important skill.

1. Proofread. Please. I mean really, this is a QA position. If you don’t take the time to catch issues in something as personally important as a resume and cover letter, how thorough will you be when it is late and you are tired and you’ve been testing for 3 days?

2. Research. If you don’t know if you are writing to a woman or a man, do not guess. Go search online. Is there a linked in profile, a company profile, any search results mentioning the person? You should probably be going through some of that anyway. If you really can’t figure it out, you can call the company and ask who to whom you should address the letter.

3. Know what position you are applying for. Yes, that’s right. Don’t try to pass off a generic cover letter. When you only have a few paragraphs, irrelevant experience, broad goals and interests, and a detached tone are not really impressive. Those are one thing though, but people who apply but forget to change the job title, copy and paste from the job posting with out adding any context to it, or seem to not know what the job entails are just a waste of everyone’s time.

4. Double check your attachments. Actually, triple check. I got resumes with the wrong cover letter attached, missing attachments, or including corrupted or hard to read files. It is also a good idea to think about what you name your attachments.

5. If you are interested, act interested. You took the time to respond to the job posting, but you should appear interested in the job. I love questions, but when the cover letter is more a list of questions about what the position can do for you, it makes me wonder what exactly you are excited about.