It wasn’t until early August that I got an opportunity to work for Electronic Arts. Since then, I’ve learned so many different things, and met so many unique people. I can’t go over everything that I’ve experienced working at EA since there is a lot of confidential information floating around (that can get me fired or sued if I were to release this info), but I can talk in a more abstract fashion to give you all an idea of what’s going on there.
Basically, I live the life of an SQA Analyst in the making. I do possess that title, but titles are deceiving because it doesn’t necessarily reflect the “experience” of the person who holds it. For example, I can be an SQA Analyst with only a month or two of relevant experience, while another with the same title might have almost a years worth of experience. That is why I claim to be an analyst “in the making.”
Now, one may wonder what on earth an SQA Analyst does. A SQA analyst is a ‘Software Quality Assurance Analyst.’ There are many definitions for what an SQA analyst is, but it’s hard to standardize this definition since this group of analysts function in many different ways. I won’t get theoretical with the definition of an SQA analyst. Basically, what I do is assure that the processes initiated in order to build and release software are done correctly. I also function as a hybrid where I also take part of initiating tasks that an SQC analyst would do. A SQC analyst is a ‘Software Quality Control Analyst.’ A SQC analyst basically checks whether or not the actual functions of the software do what they’re supposed to do. Thus, initiating the actual testing is also a part of my life here. I verify the processes are carried out correctly, and validate the functions are working as they should.
You may wonder, “ok, what exactly are all these ‘processes’ that you work on?” That I cannot delve too deep in since the project I am working on is still undisclosed, but to talk about it in the most abstract fashion, I make sure that the software that is released is debugged as well as possible. This means assuming a role of being a bug tester and looking for bugs, as well as looking for ways to create bugs. I am not only a bug tester though, and that only takes up some of my time. A lot of my work requires interfacing with other people, ranging from developers or other QA groups overseas, to the engineers who help fix these problems. So by taking this position, it’s easy to engage with many other teams.
I also control the configuration of servers, and how it interfaces with the project we are currently working on. Currently I am being trained in developing API tests, as well as title roll-out.
API test development is basically the task of looking at a particular code-base, and creating test plans from it in order to further aid the software from generating bugs.
Code will not always be written in the best way possible. Not every programmer/engineer realizes that through the code they had written, that the code may lead to horrible bugs that can break the program. For example, maybe the code didn’t factor in edge case conditions (e.g. inputting age is obviously an integer type, but what if the end-user put a character instead of an integer?), these overlooked areas can yield to big problems. Programmers do their best to keep methods in check to keep bugs from materializing, but with all the time constraints, or any external factors they might have to deal with, it’s not usually the greatest priority for them, giving more reason to have SQA analysts behind their backs.
Thus, API test development deals with looking at the code, seeing the risk areas, and making it evident to the programmer that these risk areas are zones for bugs to break loose. Thus, since they are places where bugs may potential pop up, they need to be tested every-time code is compiled and built, and when changes to the code are made. People who have regression testing experience can relate to this.
Title roll-out basically consists of aiding in the process of releasing games in the most efficient and timely fashion. People do not propose game projects that are expected to materialize into real games overnight. It takes a lot of overhead to get paperwork finished, and to put their game through our testing processes to make sure they work. Thus, there are a lot of people involved in pushing out a single game. Interfacing with the store administrators in making sure the games are configured properly, interfacing with the game teams to make sure the builds of the games are submitted in a timely manner for release, etc. are the types of things done in title roll-out.
Thus, those are the two main things I do. The perks of doing these things is that one starts to learn stuff.
As of today I’ve gained knowledge in the following subjects:
- Working with the REST API in client-server communication
- Developing software with HTTP protocols for client/server services
- Scripting for tools using Python (in the process of learning)
- XML/XSLT/XPath use in client-server communication
- Unit testing using Maven and the TestNG framework
- More experience programming in Java
- Software configuration management using Perforce
- Better software testing methodologies
And just by being around, I’ve taken up learning a lot of relevant topics on my own:
- Scripting using the Unreal engine
- Maya animating
- Mathematics for 3D gaming/physics
So it’s only been a few months, yet I’ve learned so many things by being at EA. EA isn’t only a job. Within its campus they offer classes to learn new things ranging from how to talk to your manager during 1-1 mid-year reviews, to learning Python to script animation, to learning C++ for engineering work.
It really is a great place to work, because not only is it a place to enjoy video-games, but also a place of personal development, and that to me is an awesome job.



