Archive for the ‘software testing’ 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

Advertisements

Test Escape Reports

We just had a big launch at work, which of course leaves me thinking about test escape reports.

I have mixed feelings on test escape reports, and for a long time I didn’t want to use them here. My reason being that if you have a small test team, and you know everyone is really dedicated and working hard, then the occasional test escape is to be excepted and we shouldn’t harp on them.

However, I think over time I’ve seen the other side of this issue. Test Escape reports ensure stakeholders that you are on top of any issues both before launch and after. They hold the team accountable, not just for the issue but also for the resolution and prevention of it in the future.

 

The format we use is simple:

Issue:

Severity:

Reason missed:

Steps taken to cover functionality:

Test cases numbers for verification:

 

The point being not to look backward, or to blame someone for missing a bug- but to look forward into how we can test that in the future and how we can avoid over looking similar areas on other projects. The goal is to improve visibility- we admit our mistakes, take steps to correct them and let everyone take comfort in/participate in the improved coverage.

How do you handle missed bugs? Are test escapes’ a whole team problem or an individual tester’s problem? Is there a formal process surrounding them?

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.

Sauce Labs

We got set up with Sauce Labs last week and are starting to play around with it. It seems like it will be a great addition to our automated testing. We are in the process of redefining how we use Selenium here, so that it is used more effectively and strategically.

Really, our greatest challenge has been getting everything smoothly integrated through Hudson, which I think will make a huge difference. The whole team worked through it together and we learned a ton.

At Agile 2010 I heard Jason Huggins speak about using selenium to make demos of functionality for shareholders. I loved this idea. What a great plan  to give people an easy way to keep track of a project’s current status and to nail down the functionality for some high level tests. We are trying a similar idea now for a widely used site to help users get a good handle on the features. We are hoping it is our first finalized example of the new automation process with sauce labs integrated. I am really excited!

Time for QA to fully embrace Agile

My favorite idea from Agile 2010 was that “QA should be the headlights for a project” A quality guide, not a quality police.

We can sit at the end of the schedule, run tests and file bugs. Or, we can jump out in front, help define requirements, learn from the programmers as they work on the project, offer advice and keep the user experience and project quality on everyone’s mind from beginning to end. Which helps the project more? Actually, which is more fun? Because personally I’d much rather get involved and get people excited about turning out a good product in the end, than just force quality on them right before release.

So how do you change your company culture to embrace that? I am presenting at a lunch and learn next week, with the hopes of kicking off this next phase of the QA process. I am so inspired and excited for the change after a week of being surrounded with agile talks… but how will the company take it? I think I have gotten my department on board, but the hard part will be the other departments who have to put up with us a lot more now. No one likes change, and organizations are harder to change than people.

So how do you get everyone excited about it? How do you show everyone how important this will be? I haven’t finished my presentation yet, but I’m trying to think back to those really inspiring sessions at the Agile Conference and give it a go. Heres hoping!

Agile Conference 2010

I arrived in Orlando with my team last night. We are looking forward to a week at the Agile Conference 2010. Our company has been moving more and more into true agile all year, and we are learning as we go, so this conference will be a great chance for us to pick up new ideas.

Finding out a testers place on the team has been an ongoing and ever changing process. Which is why I was so excited when I learned that there is an amazing testing track with classes I can’t wait to take and speakers I am looking forward to hearing. I hope to learn a lot to bring back to the team at home and try out for ourselves!

The Tester’s Scientific Method

We all remember the scientific method from jr. high science labs.  But as a tester, we still use it every day. The steps may entail different things, but the underlying philosophy remains the same. Testing is an interesting blend between scientific and creative, between destructing and constructing. It requires a flexible yet ordered mind and, as with any scientific approach, it requires curiosity.

1. Ask a Question: The most valuable thing a QA can do is to ask the right questions. Is this feature supposed to work this way? Could this functionality be broken if I do this?  How will this affect existing functionality? What does this mean for the user experience?

2. Do research: Talk to the engineers, look at the documentation, discuss with your fellow testers. Stand up meetings are a great time to hear what developers are up to and to ask any questions you have run into on those features.

3. Construct Hypothesis: Determine how the feature should work and all the ways you need to verify that it passes when it is supposed to pass and fails when it is supposed to fail. Write your automated and manual test cases

4. Test: Run test cases

5. Analyze Results: Evaluate what is failing and why. It is not enough to know that a feature has an issue, you need to know what exactly reproduces it? If you spend a moment looking at it, perhaps you will find related issues or other ways it can be reproduced.

6. Report results:  Carefully fill out your bug report. Stick to a bug filing standard. Spell check. Make sure that anyone could understand your bug and the information you have gathered from it.

7. Be prepared to test again. Bug fixes always bring with them the risk of inserting more bugs. Don’t just verify a bug fix, test the bug fix. It should get the same attention that the original feature did. Be aware that you may have uncovered a cluster of bugs or a series of new bugs that have appeared since the fix, so look at it with fresh eyes.