Life at Electronic Arts

•December 3, 2008 • Leave a Comment

n518248622_1684495_3673

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.

Chiming in

•December 3, 2008 • Leave a Comment

It’s been a long time since I’ve posted, and it’s due to the fact I’ve moved out of my old place and also got a new job at Electronic Arts.

I was a contractor for them the last time I posted, but now I’m an actual employee that is provisional until around late April (until I have the possibility of being converted into a regular full-time).

I’ll post a bit about what I’ve been up to, and hopefully I can do this in a more consistent manner.

Regarding tea, my consumption has gone down because there have been more important things to spend money on, especially during my moving period.

I will be creating new posts to describe what’s been going on since my last posting, so stay tuned!

Things I’ve been reading about…

•August 19, 2008 • Leave a Comment

I haven’t been posting much because I’ve been spending the past few days learning about things to help me at work (and possibly help me in moving up positions in the future).

As an analyst/tester, for the time being, I am checking for consistencies between our EA data processing servers and EA’s download manager (I cannot get in-depth with this due to confidential content).  However I will start working more in-depth in the following weeks regarding my involvement with the server-side data.

In a static-world, this is easy, but in a world where you work for a big time gaming company, games are modified often, very often.

This means values change all the time and sometimes information just doesn’t get represented the way you wanted it. Some things you cannot even change on the fly, meaning that if you modified information in a particular server, you will not get the changes globally for at least 24 hours.

What does this mean? This means you better make sure the information is being fed better be good the first time around, and that consistency has to be maintained. That’s an area I work in, and it’s fun because I can use my logical skills learned in college in real-life applications, not just theory.

When things break, you have to find ways to solve the problems. They hired just the right guy for the job because, what do I do? I solve problems!

So enough of the long introduction, the stuff I’ve been learning/reviewing on are:

  • Java using Head First Java by Sierra and Bates, Copyright 2003 O’Rielly Media.
  • HTML/XML
  • Representational State Transfer (REST)

Java

Many software development companies create programs using the Java language, so it’s good to know Java. The problem is, I’ve only read about Java and haven’t really programmed in it. I’ve been a C++ programmer for most of my life so it wasn’t really hard migrating into this “new” language. Now that I’m practicing by creating some mini-projects by myself, I am able to understand the language very well in a short period of time. I do well when it comes to self-learning so learning this was a pleasure.

Much of it is very similar to C++. I’ve recently read about inheritance, polymorphism, constructors, and now reading on numbers and statics (chapter 10 in the book above for anyone who wants to reference the topics I’m talking about). The next section is on exception handling, which is something every programmer should know.

It’s not that bad of a language. There are some things I like about C++ that are better and won’t mention, but it’s ok, I can still code in this language.

HTML/XML

These styles weren’t all that difficult to learn. HTML was read on mainly so I can read about the structures and different content markings they had (such as <p>, <b>, etc. ). It’s good to have some-what a background in HTML before reading about XML because XML can be used with HTML.

HTML wasn’t hard to learn at all, and the main goal for me was mainly to learn about XML.

XML is a type of data protocol that requires a specific content structure: root (parent), and root’s contents (children and sub-children). It doesn’t discriminate with how the tags are labeled as long as you have that content-structure in your file. Because of this, it exhibits a tree structure and you can get information initiated in that flow.

This allows easy tracking of data being transfered or stored, which is the purpose of XML (along with content structure).

XML can be applied to all sorts of data since it does not discriminate between data-types, it just knows how to store it, how to transfer it, and how to structure it. This is why XML is really helpful and should be standardized.

However, the main reason why I’ve been learning about this, is because that is what a lot of companies use nowadays, including EA in data transportation and storage, which makes sense (if you’ve read the introduction) if you have a position like mine.

The more you know, the more you can apply, the more important you get if you apply what you know efficiently and effectively as possible. In a large company you have to stick out to get promoted, I like to think ahead.

REST

By now you should get an idea that I am trying to learn a lot of the ways clients and servers communicate. It’s not just a bunch of gaming, even though I do handle games (and play them when I can). REST is a protocol that is stateless. This means information are identified as references (such as URLs), and by navigating via references, state between client-server can be eliminated. A lot of things on the web (including the web itself – to an extent) is RESTful, which means it uses the pure REST formatting. What do you think you’re doing when you’re surfing the web?

REST is a good protocol to read on, and if you want more information about it, I suggest reading the Fielding dissertation on Representational State Transfer. Just google it.

Future

I plan on learning about AJAX and PHP in the nearby future. I will try to get some Javascripting knowledge in as well. Since these help in databases and analysis, knowing them will allow me to analyze and test at a much lower-level, which is good.

The great thing about already knowing how to program with an industry-grade language like C++ allows one to learn scripting languages, protocols, and even other languages quite easily. It’s just about learning about the syntax and the complexities (for example, LISP vs. C). The rest is knowing how to translate algorithms of doing something into code. The better you are in thinking and using logical skills (which I’m grateful I’ve learned in the math program at Berkeley), the more likely you will know how to apply these skills into making effective and efficient codes. I mean there are great books out there in that as well, but it’s good to have your own set of tools you can use.

Tea information put on hold.

•August 10, 2008 • Leave a Comment

Because of my job, I will have to review some material that I may actually post about (it helps me since I will be re-iterating what I had learned).

Due to this situation, I will have to put my tea writings in hiatus.

It won’t be for too long though. Once the job settles down and I get an idea of what I have to do, which may be in a week or two (or three), then I can focus more on tea.

However, this does not mean I will stop drinking tea. I will have plenty to talk about once my job settles down.

Thanks!

Bryan Pakingan

I got…hired!

•August 9, 2008 • 1 Comment

In an earlier post, I claimed I was pending for a final phone screen for EA Games. I’d function as a Software Quality Assurance Analyst if I got this position, and this position would definitely jump-start my career.

The day I had the interview I got up 3 hours ahead of time in order to prepare. I drank hot Japanese green tea to clear my sinuses, organized my thoughts on paper (things I may need to have to answer, and what THEY might ask), and recited situations out loud to check the pitches and tone of my voice.

All of these factors needed to be perfect. In a phone interview, they cannot see your gestures so everything relies on effectively projecting your thoughts through your voice. This requires being able to elaborate at the right times.

So anyways, I had to practice all that and had my interview. I was asked basic questions about myself, what I do, how I can contribute to the company, etc. These answers were already written down in front of me so I just had to go over the main ideas and elaborate about it. Anyone expecting an interview should already know how to answer these types of questions.

I was in a phone screen with two interviewers and the other one asked about more technical topics. He asked about what kind of software programming languages I’ve coded in, what type of projects I’ve worked on, and asked me how to solve problems he came up with. Pretty much a thinking-out-loud part.

After that, I was told by my manager to call him and he asked me exactly what I wanted to hear, “What do you think? Do you accept?”

I think the answer is obvious by checking out the title of this post. :)

Take note I applied last Tuesday (08/05/2008). Quick turnaround!